【医院信息系统典型故障案例解析】数据库性能优化后的悲喜交加

案例关键词：Oracle；数据库；性能优化；Bug

更快的速度、更高的的性能不仅对临床用户，对运维人员也是一件喜事。即便如此，有时也会在数据库中触发一些让人意想不到的“坑”。下面简单介绍一个因为性能优化后触发的Oracle数据库的Bug导致业务故障的案例。

【案例还原】

某医院资深维护人员小L最近算是“悲喜交加”，喜的是，某个重要系统刚换了服务器、存储等硬件设备，整个系统性能有了极大提升；悲的是，该系统自从更换过设备后，每天一到业务高峰期，业务科室就报障无法操作或是要等待一段时间才能操作。小L甚是不解，在一次报障中，小L仔细检查完主机操作系统及存储后确认两方面均无问题，之后便开始深入检查了数据库。

通过语句[select * fromv$session_wait where event not like ‘%message%’]发现event 等待事件中有许多enqueue等待事件，通过该视图，继续深入查询sid为1310的enqueue等待事件。

通过语句[select sid,prev_hash_value from v$session where sid = 1310]查询得到该sid的事件等待的上一条语句的hash_value为“2687139145”；

继续查询v$sqltext，通过语句[select * from v$sqltext where hash_value = '2687139145' order by piece]得到sid为1310的等待事件，等待的是上一条语句[delete SF_HZBR00 whereHZQSRQ<to_char(sysdate,'YYYYMMDD')]。

通过对所有enqueue等待事件的查询得知，数据库中的enqueue事件都是在等待上述delete语句的执行。

问题现象已经很清晰了，因为delete的操作，导致表SF_HZBR00的排他锁而导致其它业务等待。小L查到问题所在，并通过脚本把数据库中所有的hold和wait杀掉后（具体语句如下），业务恢复正常。

但是到了第二天，问题又重复出现，查询后仍旧是表SF_HZBR00的delete操作在作祟。

那为什么在高峰时间会频繁执行delete操作？谁在执行？为什么要执行？

带着这些问题，小L咨询了业务同事小W，小W一眼就看出，该delete语句是数据库中某个job的问题，该job每天定期跑一个存储过程SP_HT_LSSJQL，该存储过程就每天都在跑这条delete语句，主要是每天定期清理候诊病人队列数据。

那问题又来了，既然是job，每天定期执行，为什么之前没有问题，升级系统后就出问题了？

查询数据库日志后发现，之前没有出问题是因为原来机器性能所限，该job根本没有执行成功过，表SF_HZBR00积攒了好几年的候诊病人队列无用数据。而自从换了设备后，系统性能大为改观，job可以正常跑，但是因为数据量过大，所以导致在业务高峰时期表数据仍未清理完毕，而之前的处理手段是直接kill进程（job超时，数据库会将其停掉），所以删除表数据的工作被回滚，导致表数据未清理成功过。

原以为性能提高后问题会减少，没想到性能提高后触发了数据库一个长期存在的“隐忧”。原来“坑”一直都在，只是之前没有踩中而已。

后来，小L把存储过程SP_HT_LSSJQL中的该条delete语句注释掉，问题得以解决且未再出现。后续，小L通过手工方式逐步把表SF_HZBR00的数据进行清理，并撤销对SP_HT_LSSJQL的delete语句的注释，从根本上解决了问题。

【案例总结】

1、要定期关注数据库日志，关注数据库定期执行job的执行情况，尤其是对一些表或数据的处理是否执行成功，如果未成功，虽然短时间可能不会影响业务系统，但是长期可能会导致性能瓶颈。

2、数据库锁及锁等待，为尽快恢复业务系统，应急处理可以统一kill掉，但是从根本上来说，为防止锁及锁等待的出现，应深入分析锁产生的机制与原因，优化相关SQL语句，从根源上解决问题。

3、DBA和熟悉业务的工程师应该共同处理数据库逻辑问题，这样可起到事半功倍的效果。