自動轉報系統資料庫程序異常的現象及處置過程的案例分析論文

　　摘要：本文詳細描述了自動轉報系統資料庫程序異常的現象及處置過程，總結了類似故障的處理方法及預防措施。

　　關鍵詞：自動轉報系統；資料庫操作處理程序DMHS＿MON；壓報；

　　2010年，北京區管中心從中國民航總局航管科技公司引進了DMHS—H大型電報和資訊交換處理系統，該系統採用儲存轉發的方式完成電報資訊的交換，作為首都機場自動轉報樞紐的下級節點，透過民航ATM專網與首都機場轉報系統、民航總局轉報系統相連，承載著北京區域管制中心所有的電報收發業務，為北京區管的管制員提供安全可靠的飛行電報資訊。系統伺服器及交換機均採用雙機熱備方式，為每臺伺服器配備獨立的oracle關係型資料庫，達到雙機雙庫執行模式。

　　一、相關內容解釋

　　DMHS_MON：資料庫操作處理，主要負責報文收發出入庫功能操作

　　DMHS_IP、%date%：存放於/dmhs/log目錄下的日誌檔案

　　OUT_QUEUE_%date%：輸出佇列報文表，其中DEAL_FLAG欄位， Y為正常傳送、T為中間態、M為未發、D為刪除

　　二、故障現象

　　值班員發現，北京時間2017年12月21日早八點，即國際時零點左右， DMHS—H轉報系統的前臺管理終端會出現告警：“dmhs_mon從[00：00：00]程序136秒工作可能不正常，請檢查盤陣！”

　　三、問題分析

　　登入自動轉報系統後臺管理終端，檢視DMHS_IP日誌，發現自19日起至21日共三天，每日國際時00：02：16，均出現“Chk_Mon_Wait_Long dmhs_mon從[00：00：00]起[136秒]工作可能不正常，請檢查盤陣！”告警。

　　根據自動轉報系統的工作原理，當系統產生大量壓報且數量超過記憶體的上限，新的壓報會覆蓋最開始的壓報，而資料庫中的壓報資料一直是被標記為‘M’的。當記憶體中的壓報被繞轉或被刪除之後，以前被覆蓋的壓報就會一直存在於資料庫中，且標記始終為‘M’未傳送，這些報文就會在每天國際時00：00：00進行移庫操作，將資料庫中的昨日未發報文移動到當天的傳送報文表中。可以確定，此次故障告警時間與資料庫移庫操作時間吻合，登入到資料庫，統計當天未傳送的報文，得到結果為74034條，由此可以斷定， 12月18日自動轉報系統某通道產生了大量標記為‘M’的被覆蓋的未傳送報文，這些報文每天在國際時00：00：00進行移庫操作，連續進行了三天，每次移庫花費136秒，使得DMHS_MON程序響應變慢，從而前臺出現相應的告警。

　　四、故障處置

　　根據以上分析，修改輸出佇列報文表中積壓報文的狀態，由未傳送改為正常傳送，同時要注意避免將12月21日新產生的未發報文同時被修改。

　　五、總結

　　5、1及時檢視通道壓報情況

　　值班員應做到每兩小時檢視一次系統的壓報數量，如果壓報過多應及時處理，可進行壓報繞轉、報文drop等操作，及時檢查線路以及終端問題。

　　5、1、1壓報繞轉操作

　　點選主選單“報務管理”的'“相關控制”單擊“壓報繞轉”，在“源佇列”輸入有壓報的佇列，在“目標佇列”填入源佇列的備用佇列，然後選擇繞轉電報等級，最後點選“確定”。

　　5、1、2 DROP報文操作

　　點選主選單“報務管理”的“相關控制”單擊“DROP/UNDROP電文”，在“佇列名稱”內填入要DROP的佇列，等級及日期，然後選擇“瀏覽報文”最後可以DROP全部，也可以選擇性的DROP所選報文。

　　5、1、3UNDROP報文操作

　　點選主選單“報務管理”的“相關控制”單擊“DROP/UNDROP電文”，在“佇列名稱”內填入要UNDROP的佇列，等級及日期，然後選擇“瀏覽報文”，然後點選“全部UNDROP”恢復DROP掉的電文。

　　當某一佇列轉報速度慢，有很多積壓電報，就可以先DROP掉一些無關緊要的電報，讓後面新來的電報先走。DROP不是真正的刪除電文而等轉報機機正常後，再把DROP的電報UNDROP恢復。