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