案例關鍵詞：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和熟悉業務的工程師應該共同處理數據庫邏輯問題，這樣可起到事半功倍的效果。