拯救關鍵業務上線：DBA的驚魂24小時

一個電話，打破深夜的寧靜

9月20日晚上10點

剛完成外地一個重點專案為期2周的現場支援，從機場回家的路上，一陣急促的鈴聲驚醒了計程車上昏昏欲睡的我，多年的工作經驗告訴我這麼晚來電一定是出事了，接起電話，是KS。

KS正在跟一個國內關鍵客戶資料庫國產化替代專案，該專案核心業務系統由Oracle替換為金倉資料庫KingbaseES，專案前期應用適配和測試穩步推進，根據計劃，整個系統將於9月21日晚上10點啟動上線，並於22日早上8點前全部完成。以確保22日客戶上班時間可以正常使用，並能順利支撐業務高峰期。

KS是配合應用開發專案團隊正在為專案上線做最後的測試和驗證的技術支援人員，他急切地表示，在專案團隊在進行一次壓力模擬測試時，當資料庫併發連線超700，系統中某一個業務流程的操作出現明顯示卡頓，再對該業務流程某項操作併發再增加時，甚至出現了資料庫停止服務。

上線在即，突然發現此類問題，顯然這是重大風險，該專案是客戶計劃重點打造的國產化標杆專案，本次待上線業務系統是客戶所有部門員工每天必用的系統，客戶上上下下對該專案都十分關注，專案按時上線是必須要完成的任務。

經過快速巡檢和系統檢視，並結合過往那個經驗，KS初步判斷這不是簡單的系統問題，因此找到了我。

初見端倪，卻幾盡崩潰

9月20日晚上11點

掛了電話，我立馬趕到專案所在地，客戶、整合商和金倉三方的的專案負責人均在現場，專案上線在即，現場的狀況讓KS溝通起來稍顯語無倫次，儘管如此，我還是清楚地感受到了整合商和客戶的擔憂。

問題的焦灼程度及現場巨大的壓力告訴我，我的判斷和處理結果直接影響專案的順利交付和客戶資訊系統國產化的信心。

我快速進入工作狀態，開始檢視資料庫的各項引數和相關日誌檔案、指標，同時仔細分析了下測試時的主要場景特點。首先抓住以下問題表現作為根因分析的抓手：

測試中，業務查詢非常慢。監控資料庫，從作業系統層觀察到系統大量IO，CPU IO 等待達到40%，IO 大小超過500MB/s 。

聚焦該現象初步確認引發IO的程序：根據iotop確認產生大IO的程序都是kingbase程序，問題指向資料庫，懷疑是部分SQL存在效能問題，導致資料庫IO過大。但是如何準確定位資料庫等待事件成了一個難題，首先按照以往經驗我想到透過查詢sys_stat_activity字典確定，但是sys_stat_activity只能查詢當前時間點的資料，後來我又採用一些其他方法試圖採集一些資訊，但是這些資訊分散、維度有限，不足以支撐問題的快速定位，一時間我陷入迷茫。

時間馬上到了第二天，一邊是我不知道該如何獲取更多幫助定位問題的資料資訊，另一邊是客戶差不多每過半小時過來詢問一次解決進展，後來乾脆坐在我們身後看著我們解決問題。無形的壓力接踵而至，不斷加速的心跳彷彿是在呼喊：誰來拯救我！！！

柳暗花明，關鍵問題迎刃而解

9月21日凌晨1點

數不清是第多少次安撫完客戶，我強迫自己保持鎮定，心想不能這麼僵持下去，得快點找到突破口。於是我重整精神，迅速在大腦中回放、梳理、挖掘，尋找突破方法。突然我想到前一陣產品內部培訓提到的產品新能力，可以透過工具KSH和KWR分別對資料庫的會話歷史和各種負載資訊進行收集，並能快速生成報告，趕緊和相關同事瞭解了下現場的版本情況和使用方法，並確認現場版本已經具備相關能力。於是嘗試先使用KSH工具進行分析，皇天不負有心人，終於在黎明到來前，迎來了“柳岸花明”：。

1。透過KSH週期性採集資料庫的等待事件資訊，展現當前及過去一段時間的系統等待事件情況。

2。檢視KSH 報告，我發現了 “BufFileWrite” 等待事件比例極高，該等待事件表示程序正在等待將BUFFER內容寫出到檔案。“BufFileWrite” 等待事件，通常意味著程序在進行寫臨時檔案操作。走到這裡已經很明顯了，可以確定是由於特定的SQL導致了系統的IO問題。接下來就是要找到這個“罪魁禍首”，即確認問題SQL並對其進行最佳化。

3。確認問題SQL：再次分析KSH報告，找到等待“BufFileWrite”事件的SQL，確認問題SQL如下：

4。分析最佳化SQL：可以看到SQL採取hash join，而hash操作引發的磁碟寫，是引發大量磁碟IO的原因。

去掉hint後，執行計劃如下：

可以看到，去掉hint之後，SQL採用索引掃描了，不但IO減少了很多，速度也更快了。

5。跟應用開發人員溝通後，確認是前期適配時，由於測試環境資料量較少，透過加hint （/*+set（enable_nestloop OFF）*/），可以獲得更快的效能。而現在模擬生產環境測試時，測試資料量成倍增加，hint 不再適用。

6。修改SQL：協調應用開發人員修改SQL，再次驗證。

9月21日凌晨4點

確認經過修改，資料庫不再有IO 問題，壓測下，之前出現的卡死現象也未在出現。

“排雷”行動，確保無憂上線

完善的配套工具將我從問題的泥潭中解救，讓問題定位和解決的速度得到了飛速提升，客戶終於露出了笑臉。為了確保後續上線的順利，我和現場的同事不敢放鬆，擔心還會有潛在的風險，因此決定再進行一遍“排雷”行動。因為有工具的加持，讓我們有信心能在幾小時內完成之前可能幾天都完成不了的事情。

9月21日凌晨5點

說幹就幹，應用開發商繼續進行對業務進行壓測，我們在業務執行過程中，採用各類巡檢手段，配合使用KWR對資料庫狀態開始進行全面檢測，以排查可能還未被發現的“雷區”，果然，在持續的測試和監控過程中，早上大約7點多，我發現系統CPU使用率此時非常高，但IO正常，顯然這不太正常。這下心又提到了嗓子眼，我趕緊展開新一輪的排查：

1。先確認最耗CPU的程序：使用top命令，檢視最消耗CPU資源的程序，確認這些程序都是kingbase程序。

2。確認資料庫等待事件：檢視資料庫的 KWR報告，確認資料庫的時間都花在CPU上，沒有明顯的等待事件。從這些現象可以推斷程序狀態是正常的，特定SQL效能不佳，消耗大量CPU資源。

3。準確定位SQL： KWR工具也提供了TOPSQL功能，可以根據CPU、IO、執行時間對SQL進行排序。對於當前問題，透過檢視“Top SQL By Elaspsed Time”章節，可以快速確定出最消耗CPU的SQL。。

4。SQL 效率分析：完整的SQL有4次呼叫了以上的子查詢，而且子查詢用到了視窗函式，視窗函式是最消耗CPU資源的。這部分對於效能的消耗如下：

5。可以看到，這部分簡單的查詢需要 768ms，4次呼叫總共需要3秒。因此可以考慮透過提取公共表示式（CTE），整條SQL可以減少時間2秒左右。

透過提取SQL的公共表示式，將以上的子查詢提取到CTE。

9月21日上午10點

修改完SQL後，再次執行KWR，確認以上SQL效能問題得以解決。

接下來，一切都比較順利，但我們仍然不敢放鬆警惕，時刻關注資料庫的執行狀態，好在有KWR和KSH能幫助我們快速進行相關資料的收集，幫助我們做到心中有數，同時透過收集的資料，使用資料庫自帶的診斷工具——KDDM，對報告進行階段性分析，進一步診斷效能問題，為開發商又提供了一些最佳化建議，比如下面的索引建議：

1。KDDM針對如下SQL給出了索引建議。

2。分析執行計劃：從初始的執行計劃看，執行效率非常低。