摘要：本文详细描述了自动转报系统数据库进程异常的现象及处置过程， 总结了类似故障的处理方法及预防措施。
关键词：自动转报系统； 数据库操作处理进程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恢复。
5、2设置压报告警
对于重要的信道设置压报告警， 点击“系统配置”的“流量告警设置”， 在新建/修改页面中， 填入需要配置告警的信道、告警的时间段、最大和最小报量以及报文统计周期 （以分钟为单位） 。
这样在告警时间段， 当压信道报超出设定最大或小于设定最小报量之后， 转报系统会主动发出告警提示， 以便提醒值班员及时进行处理， 从而避免出现大量压报。
参考文献
[1]徐斌， 郑斌、自动转报系统GPS故障案例分析[J]、当代青年， 2015年第07期、
[2]李朝红、DMHS—M转报机几则故障分析[J]、空中交通， 2015年第05期、
本文来源：https://www.010zaixian.com/shiyongwen/1543893.htm