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

自动转报系统数据库进程异常的现象及处置过程的案例分析论文 摘要：本文详细描述了自动转报系统数据库进程异常的现象及处置过程，总结了类似故障的处理方法及预防措施。 关键词：自动转报系统；数据库操作处理进程DMHSMON；压报； xx年，北京区管中心从中国民航总局航管科技公司引进了DMHSH大型电报和信息交换处理系统，该系统采用存储转发的方式完成电报信息的交换，作为首都机场自动转报枢纽的下级节点，通过民航ATM专网与首都机场转报系统、民航总局转报系统相连，承载着北京区域管制中心所有的电报收发业务，为北京区管的管制员提供安全可靠的飞行电报信息。系统服务器及交换机均采用双机热备方式，为每台服务器配备独立的oracle关系型数据库，达到双机双库运行模式。 一、相关内容解释 DMHS_MON：数据库操作处理，主要负责报文收发出入库功能操作 DMHS_IP、%date%：存放于/dmhs/log目录下的日志文件 OUT_QUEUE_%date%：输出队列报文表，其中DEAL_FLAG字段，Y为正常发送、T为中间态、M为未发、D为删除 二、故障现象 值班员发现，北京时间xx年12月21日早八点，即国际时零点左右，DMHSH转报系统的前台管理终端会出现告警：“dmhs_mon从00：00：00进程136秒工作可能不正常，请检查盘阵！” 三、问题分析 登录自动转报系统后台管理终端，查看DMHS_IP日志，发现自19日起至21日共三天，每日国际时00：02：16，均出现“Chk_Mon_Wait_Longdmhs_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、2DROP报文操作 点击主菜单“报务管理”的“相关控制”单击“DROP/UNDROP电文”，在“队列名称”内填入要DROP的队列，等级及日期，然后选择“浏览报文”最后可以DROP全部，也可以选择性的DROP所选报文。 5、1、3UNDROP报文操作 点击主菜单“报务管理”的“相关控制”单击“DROP/UNDROP电文”，在“队列名称”内填入要UNDROP的队列，等级及日期，然后选择“浏览报文”，然后点击“全部UNDROP”恢复DROP掉的电文。 当某一队列转报速度慢，有很多积压电报，就可以先DROP掉一些无关紧要的电报，让后面新来的电报先走。DROP不是真正的删除电文而等转报机机正常后，再把DROP的电报UNDROP恢复。 5、2设置压报告警 对于重要的信道设置压报告警，点击“系统配置”的“流量告警设置”，在新建/修改页面中，填入需要配置告警的信道、告警的时间段、最大和最小报量以及报文统计周期（以分钟为单位）。 这样在告警时间段，当压信道报超出设定最大或小于设定最小报量之后，转报系统会主动发出告警提示，以便提醒值班员及时进行处