自动转报系统数据库进程异常的现象及处置过程的案例分析论文

时间：2021-08-31

　　摘要：本文详细描述了自动转报系统数据库进程异常的现象及处置过程，总结了类似故障的处理方法及预防措施。

　　关键词：自动转报系统；数据库操作处理进程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恢复。