一個電話，打破深夜的寧靜
9月20日晚上10點
剛完成外地一個重點項目為期2周的現場支持，從機場回家的路上，一陣急促的鈴聲驚醒了出租車上昏昏欲睡的我，多年的工作經驗告訴我這么晚來電一定是出事了，接起電話，是KS。
KS正在跟一個國內關鍵客戶數據庫國產化替代項目，該項目核心業(yè)務系統(tǒng)由Oracle替換為金倉數據庫KingbaseES，項目前期應用適配和測試穩(wěn)步推進，根據計劃，整個系統(tǒng)將于9月21日晚上10點啟動上線，并于22日早上8點前全部完成。以確保22日客戶上班時間可以正常使用，并能順利支撐業(yè)務高峰期。
KS是配合應用開發(fā)項目團隊正在為項目上線做最后的測試和驗證的技術支持人員，他急切地表示，在項目團隊在進行一次壓力模擬測試時，當數據庫并發(fā)連接超700，系統(tǒng)中某一個業(yè)務流程的操作出現明顯卡頓，再對該業(yè)務流程某項操作并發(fā)再增加時，甚至出現了數據庫停止服務。
上線在即，突然發(fā)現此類問題，顯然這是重大風險，該項目是客戶計劃重點打造的國產化標桿項目，本次待上線業(yè)務系統(tǒng)是客戶所有部門員工每天必用的系統(tǒng)，客戶上上下下對該項目都十分關注，項目按時上線是必須要完成的任務。
經過快速巡檢和系統(tǒng)查看，并結合過往那個經驗，KS初步判斷這不是簡單的系統(tǒng)問題，因此找到了我。
初見端倪，卻幾盡崩潰
9月20日晚上11點
掛了電話，我立馬趕到項目所在地，客戶、集成商和金倉三方的的項目負責人均在現場，項目上線在即，現場的狀況讓KS溝通起來稍顯語無倫次，盡管如此，我還是清楚地感受到了集成商和客戶的擔憂。
問題的焦灼程度及現場巨大的壓力告訴我，我的判斷和處理結果直接影響項目的順利交付和客戶信息系統(tǒng)國產化的信心。
我快速進入工作狀態(tài)，開始查看數據庫的各項參數和相關日志文件、指標，同時仔細分析了下測試時的主要場景特點。首先抓住以下問題表現作為根因分析的抓手：
測試中，業(yè)務查詢非常慢。監(jiān)控數據庫，從操作系統(tǒng)層觀察到系統(tǒng)大量IO，CPU IO 等待達到40%，IO 大小超過500MB/s 。
聚焦該現象初步確認引發(fā)IO的進程：根據iotop確認產生大IO的進程都是kingbase進程，問題指向數據庫，懷疑是部分SQL存在性能問題，導致數據庫IO過大。但是如何準確定位數據庫等待事件成了一個難題，首先按照以往經驗我想到通過查詢sys_stat_activity字典確定，但是sys_stat_activity只能查詢當前時間點的數據，后來我又采用一些其他方法試圖采集一些信息，但是這些信息分散、維度有限，不足以支撐問題的快速定位，一時間我陷入迷茫。
時間馬上到了第二天，一邊是我不知道該如何獲取更多幫助定位問題的數據信息，另一邊是客戶差不多每過半小時過來詢問一次解決進展，后來干脆坐在我們身后看著我們解決問題。無形的壓力接踵而至，不斷加速的心跳仿佛是在呼喊：誰來拯救我!!!
柳暗花明，關鍵問題迎刃而解
9月21日凌晨1點
數不清是第多少次安撫完客戶，我強迫自己保持鎮(zhèn)定，心想不能這么僵持下去，得快點找到突破口。于是我重整精神，迅速在大腦中回放、梳理、挖掘，尋找突破方法。突然我想到前一陣產品內部培訓提到的產品新能力，可以通過工具KSH和KWR分別對數據庫的會話歷史和各種負載信息進行收集，并能快速生成報告，趕緊和相關同事了解了下現場的版本情況和使用方法，并確認現場版本已經具備相關能力。于是嘗試先使用KSH工具進行分析，皇天不負有心人，終于在黎明到來前，迎來了“柳岸花明”：。
1.通過KSH周期性采集數據庫的等待事件信息，展現當前及過去一段時間的系統(tǒng)等待事件情況。
2.查看KSH 報告，我發(fā)現了 “BufFileWrite” 等待事件比例極高，該等待事件表示進程正在等待將BUFFER內容寫出到文件。“BufFileWrite” 等待事件，通常意味著進程在進行寫臨時文件操作。走到這里已經很明顯了，可以確定是由于特定的SQL導致了系統(tǒng)的IO問題。接下來就是要找到這個“罪魁禍首”，即確認問題SQL并對其進行優(yōu)化。
3.確認問題SQL：再次分析KSH報告，找到等待“BufFileWrite”事件的SQL，確認問題SQL如下：
4.分析優(yōu)化SQL：可以看到SQL采取hash join，而hash操作引發(fā)的磁盤寫，是引發(fā)大量磁盤IO的原因。
去掉hint后，執(zhí)行計劃如下：
可以看到，去掉hint之后，SQL采用索引掃描了，不但IO減少了很多，速度也更快了。
5.跟應用開發(fā)人員溝通后，確認是前期適配時，由于測試環(huán)境數據量較少，通過加hint (/*+set(enable_nestloop OFF)*/)，可以獲得更快的性能。而現在模擬生產環(huán)境測試時，測試數據量成倍增加，hint 不再適用。
6.修改SQL：協調應用開發(fā)人員修改SQL，再次驗證。
9月21日凌晨4點
確認經過修改，數據庫不再有IO 問題，壓測下，之前出現的卡死現象也未在出現。
“排雷”行動，確保無憂上線
完善的配套工具將我從問題的泥潭中解救，讓問題定位和解決的速度得到了飛速提升，客戶終于露出了笑臉。為了確保后續(xù)上線的順利，我和現場的同事不敢放松，擔心還會有潛在的風險，因此決定再進行一遍“排雷”行動。因為有工具的加持，讓我們有信心能在幾小時內完成之前可能幾天都完成不了的事情。
9月21日凌晨5點
說干就干，應用開發(fā)商繼續(xù)進行對業(yè)務進行壓測，我們在業(yè)務運行過程中，采用各類巡檢手段，配合使用KWR對數據庫狀態(tài)開始進行全面檢測，以排查可能還未被發(fā)現的“雷區(qū)”，果然，在持續(xù)的測試和監(jiān)控過程中，早上大約7點多，我發(fā)現系統(tǒng)CPU使用率此時非常高，但IO正常，顯然這不太正常。這下心又提到了嗓子眼，我趕緊展開新一輪的排查：
1.先確認最耗CPU的進程：使用top命令，查看最消耗CPU資源的進程，確認這些進程都是kingbase進程。
2.確認數據庫等待事件：查看數據庫的 KWR報告，確認數據庫的時間都花在CPU上，沒有明顯的等待事件。從這些現象可以推斷進程狀態(tài)是正常的，特定SQL性能不佳，消耗大量CPU資源。
3.準確定位SQL： KWR工具也提供了TOPSQL功能，可以根據CPU、IO、執(zhí)行時間對SQL進行排序。對于當前問題，通過查看“Top SQL By Elaspsed Time”章節(jié)，可以快速確定出最消耗CPU的SQL。。
4.SQL 效率分析：完整的SQL有4次調用了以上的子查詢，而且子查詢用到了窗口函數，窗口函數是最消耗CPU資源的。這部分對于性能的消耗如下：
5.可以看到，這部分簡單的查詢需要 768ms，4次調用總共需要3秒。因此可以考慮通過提取公共表達式(CTE)，整條SQL可以減少時間2秒左右。
通過提取SQL的公共表達式，將以上的子查詢提取到CTE。
9月21日上午10點
修改完SQL后，再次運行KWR，確認以上SQL性能問題得以解決。
接下來，一切都比較順利，但我們仍然不敢放松警惕，時刻關注數據庫的運行狀態(tài)，好在有KWR和KSH能幫助我們快速進行相關數據的收集，幫助我們做到心中有數，同時通過收集的數據，使用數據庫自帶的診斷工具——KDDM，對報告進行階段性分析，進一步診斷性能問題，為開發(fā)商又提供了一些優(yōu)化建議，比如下面的索引建議：
1.KDDM針對如下SQL給出了索引建議。
2.分析執(zhí)行計劃：從初始的執(zhí)行計劃看，執(zhí)行效率非常低。
3.KDDM 優(yōu)化建議：建議創(chuàng)建o.f_creattime 索引
4.根據KDDM的建議，創(chuàng)建索引后的執(zhí)行計劃如下：
5.可以看到，根據KDDM建議，創(chuàng)建索引后，SQL的執(zhí)行效率提升了500倍。
經過24小時的奮戰(zhàn)，客戶的業(yè)務系統(tǒng)順利上線，并通過使用高峰期，隨著客戶宣布項目上線成功，項目組的房間里響起了熱烈的掌聲，掌聲既是對全體項目成員的感謝，也是對金倉產品和金倉人的肯定。
而我最要感謝的是我們研發(fā)團隊為我們DBA提供的數據收集和診斷工具，幫我們從繁雜的數據中提煉出價值信息，讓我們能夠更高效輕松地面對現場優(yōu)化問題。
走出客戶大樓，吸一口北京秋天清冽的空氣，這24小時不是終點，數據庫國產化之路還會遇到很多棘手問題，但是作為人大金倉的一員，我有信心，我們將通過不斷打造產品能力，為用戶創(chuàng)造更多的價值。
（免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。 ）
