您现在的位置: 首页 > 新闻中心 > 相关资讯

新闻中心

大部分信息科还不知道,一般医院HIS系统发生故障原因

在大医院看病,可能都会有这样的体验:就诊大厅人来人往,挂号收费大排场龙,看个病各个流程走下来,要花费很长的时间。可要是这个时候,医院的就诊系统突然出现故障,那可不仅仅是增加就诊排队时间那么简单了,有可能还会耽误病人治疗,进而影响医患关系。


对于一家大型三甲医院来说,His系统运行的稳定性就显得更为重要了,不容有一丝的闪失。但往往一些小的数据库故障就会影响到系统运行的稳定性,导致医院就诊流程无法顺畅进行。此时,需要快速找出数据库故障原因并处理,恢复系统稳定。

前段时间,某医院His核心系统就频繁出现应用短暂卡住的现象,造成挂号收费窗口、护士站等“瘫痪”,人满为患、怨声载道。

医院信息部门无法查出问题所在,第一时间联系了美创科技的工程师。美创的工程师立马登录客户生产库查找原因,发现存在大量等待事件,伴随短暂的数据库锁等待。碰到这种情况,很多人想当然地以为是应用程序的问题,误认为是更新程序的“后遗症”,想方设法抓语句提交给开发人员。其实这是一种误判。

根据美创工程师丰富的运维经验判断,这不像是一般的数据库锁等待,通过查看数据库alert日志,发现这套rac的alert的日志当中偶尔会出现实例重新配置的信息,并且两个节点在同一时间点都会发生。

此类问题在日常运维经验中并不常见,无法根据问题症状立刻给出及时和正确的解决思路。

工程师不抛弃不放弃,通过上述两点症状“按图索骥”,查找mos相关信息,判断是数据bug造成的问题,最后验证确实如此。找到了问题的根源,工程师在最短的时间内为客户提供了解决思路,有效地解决了问题,保证了大型医院his系统的正常稳定运行。

下面是满满的干货,详解“解题思路”

初步一看这个问题应该是rac crash了。继续排查alert日志,核实是否有实例crash后马上拉起来的日志,两个节点并没有发现实例重启的现象,但是两个节点在同一时间的alert日志当中都有相同的报错:

由上图可以看到,两个节点都报Global Resource Directory frozen错误,且在一分钟后很快又Reconfiguration complete重新配置

根据这个特征,去查询mos,找到DRM hang causes frequent RAC Instances Reconfiguration (Doc ID 1528362.1)

里面有四个症状特征:

症状特征一

- RAC Instances freezes during DRM for 100 secs or more.

RAC实例freezes 100秒或者更多(符合)

症状特征二

- DB Alert log shows that all RAC instances undergo reconfiguration at the same time, but there are no instance crashes

在相同时间数据库所有实例alert日志都显示重新配置,并且没有实例crashe

由下图所得,(符合)

症状特征三

- Lmon trace shows that DRM quiesce step hangs:

*** 2012-07-14 14:14:51.187

CGS recovery timeout = 85 sec

Begin DRM(231) (swin 1)

* drm quiesce

*** 2012-07-14 14:17:03.752

* Request pseudo reconfig due to drm quiesce hang

2012-07-14 14:17:03.752735 : kjfspseudorcfg: requested with reason 5(DRM Quiesce step stall)

*** 2012-07-14 14:17:03.766

kjxgmrcfg: Reconfiguration started, type 6

CGS/IMR TIMEOUTS:

CSS recovery timeout = 31 sec (Total CSS waittime = 65)

IMR Reconfig timeout = 75 sec

CGS rcfg timeout = 85 sec

kjxgmcs: Setting state to 70 0.

Lmon trace显示DRM hang(符合)

- Lmon trace shows that DRM quiesce step hangs:

*** 2016-09-12 08:28:39.125

CGS recovery timeout = 85 sec

Begin DRM(40) (swin 0)

* drm quiesce

*** 2016-09-12 08:28:39.676

* drm sync 1

* drm freeze

* DRM(40) window 1, drm freeze complete.

* drm cleanup

* drm sync 2

* drm replay

* drm sync 3

* drm fix writes

症状特征四

- AWR Top waits are "gcs resource directory to be unfrozen" & " gc remaster "

在awr报告中的top 5等待会有gcs resource directory to be unfrozen和gc remaster等待事件。

结论

依次比对了上述四大症状特征,可以判断此故障是由于Bug 12879027 引起的

DRM has a number of steps. During the DRM quiesce step all ongoing block transfers for remastering are completed.

In this case, during the DRM quiesce step a hang occured due to an internal function hitting a timeout.

This is a bug condition that happens when the buffer cache is very large.

This hang then triggers a pseudoreconfiguration to prevent the instance from being killed by another instance.

This is the reason for the instance undergoing a reconfiguration without restarting.

解决方案

既然我们已经找到了这个问题的症结所在,下面我们可以给出相应的解决方案。

方案1:关掉DRM

方案2:打上最新的psu

通常情况下,上述两种方案可以解决以上数据库问题。但由于环境的复杂性以及现场的多变性等客观条件,不能保证该解决方案的绝对成功,这里只提供类似问题的解决思路。真正解决问题时,请再考虑到一些客观因素,经过人为的思考,相信类似问题都能得到妥善解决。