一個(gè)電話，打破深夜的寧靜

9月20日晚上10點(diǎn)

剛完成外地一個(gè)重點(diǎn)項(xiàng)目為期2周的現(xiàn)場支持，從機(jī)場回家的路上，一陣急促的鈴聲驚醒了出租車上昏昏欲睡的我，多年的工作經(jīng)驗(yàn)告訴我這么晚來電一定是出事了，接起電話，是KS。

KS正在跟一個(gè)國內(nèi)關(guān)鍵客戶數(shù)據(jù)庫國產(chǎn)化替代項(xiàng)目，該項(xiàng)目核心業(yè)務(wù)系統(tǒng)由Oracle替換為金倉數(shù)據(jù)庫KingbaseES，項(xiàng)目前期應(yīng)用適配和測試穩(wěn)步推進(jìn)，根據(jù)計(jì)劃，整個(gè)系統(tǒng)將于9月21日晚上10點(diǎn)啟動上線，并于22日早上8點(diǎn)前全部完成。以確保22日客戶上班時(shí)間可以正常使用，并能順利支撐業(yè)務(wù)高峰期。

KS是配合應(yīng)用開發(fā)項(xiàng)目團(tuán)隊(duì)正在為項(xiàng)目上線做最后的測試和驗(yàn)證的技術(shù)支持人員，他急切地表示，在項(xiàng)目團(tuán)隊(duì)在進(jìn)行一次壓力模擬測試時(shí)，當(dāng)數(shù)據(jù)庫并發(fā)連接超700，系統(tǒng)中某一個(gè)業(yè)務(wù)流程的操作出現(xiàn)明顯卡頓，再對該業(yè)務(wù)流程某項(xiàng)操作并發(fā)再增加時(shí)，甚至出現(xiàn)了數(shù)據(jù)庫停止服務(wù)。

上線在即，突然發(fā)現(xiàn)此類問題，顯然這是重大風(fēng)險(xiǎn)，該項(xiàng)目是客戶計(jì)劃重點(diǎn)打造的國產(chǎn)化標(biāo)桿項(xiàng)目，本次待上線業(yè)務(wù)系統(tǒng)是客戶所有部門員工每天必用的系統(tǒng)，客戶上上下下對該項(xiàng)目都十分關(guān)注，項(xiàng)目按時(shí)上線是必須要完成的任務(wù)。

經(jīng)過快速巡檢和系統(tǒng)查看，并結(jié)合過往那個(gè)經(jīng)驗(yàn)，KS初步判斷這不是簡單的系統(tǒng)問題，因此找到了我。

初見端倪，卻幾盡崩潰

9月20日晚上11點(diǎn)

掛了電話，我立馬趕到項(xiàng)目所在地，客戶、集成商和金倉三方的的項(xiàng)目負(fù)責(zé)人均在現(xiàn)場，項(xiàng)目上線在即，現(xiàn)場的狀況讓KS溝通起來稍顯語無倫次，盡管如此，我還是清楚地感受到了集成商和客戶的擔(dān)憂。

問題的焦灼程度及現(xiàn)場巨大的壓力告訴我，我的判斷和處理結(jié)果直接影響項(xiàng)目的順利交付和客戶信息系統(tǒng)國產(chǎn)化的信心。

我快速進(jìn)入工作狀態(tài)，開始查看數(shù)據(jù)庫的各項(xiàng)參數(shù)和相關(guān)日志文件、指標(biāo)，同時(shí)仔細(xì)分析了下測試時(shí)的主要場景特點(diǎn)。首先抓住以下問題表現(xiàn)作為根因分析的抓手：

測試中，業(yè)務(wù)查詢非常慢。監(jiān)控?cái)?shù)據(jù)庫，從操作系統(tǒng)層觀察到系統(tǒng)大量IO，CPU IO 等待達(dá)到40%，IO 大小超過500MB/s 。

聚焦該現(xiàn)象初步確認(rèn)引發(fā)IO的進(jìn)程：根據(jù)iotop確認(rèn)產(chǎn)生大IO的進(jìn)程都是kingbase進(jìn)程，問題指向數(shù)據(jù)庫，懷疑是部分SQL存在性能問題，導(dǎo)致數(shù)據(jù)庫IO過大。但是如何準(zhǔn)確定位數(shù)據(jù)庫等待事件成了一個(gè)難題，首先按照以往經(jīng)驗(yàn)我想到通過查詢sys_stat_activity字典確定，但是sys_stat_activity只能查詢當(dāng)前時(shí)間點(diǎn)的數(shù)據(jù)，后來我又采用一些其他方法試圖采集一些信息，但是這些信息分散、維度有限，不足以支撐問題的快速定位，一時(shí)間我陷入迷茫。

時(shí)間馬上到了第二天，一邊是我不知道該如何獲取更多幫助定位問題的數(shù)據(jù)信息，另一邊是客戶差不多每過半小時(shí)過來詢問一次解決進(jìn)展，后來干脆坐在我們身后看著我們解決問題。無形的壓力接踵而至，不斷加速的心跳仿佛是在呼喊：誰來拯救我!!!

柳暗花明，關(guān)鍵問題迎刃而解

9月21日凌晨1點(diǎn)

數(shù)不清是第多少次安撫完客戶，我強(qiáng)迫自己保持鎮(zhèn)定，心想不能這么僵持下去，得快點(diǎn)找到突破口。于是我重整精神，迅速在大腦中回放、梳理、挖掘，尋找突破方法。突然我想到前一陣產(chǎn)品內(nèi)部培訓(xùn)提到的產(chǎn)品新能力，可以通過工具KSH和KWR分別對數(shù)據(jù)庫的會話歷史和各種負(fù)載信息進(jìn)行收集，并能快速生成報(bào)告，趕緊和相關(guān)同事了解了下現(xiàn)場的版本情況和使用方法，并確認(rèn)現(xiàn)場版本已經(jīng)具備相關(guān)能力。于是嘗試先使用KSH工具進(jìn)行分析，皇天不負(fù)有心人，終于在黎明到來前，迎來了“柳岸花明”：。

1.通過KSH周期性采集數(shù)據(jù)庫的等待事件信息，展現(xiàn)當(dāng)前及過去一段時(shí)間的系統(tǒng)等待事件情況。

2.查看KSH 報(bào)告，我發(fā)現(xiàn)了 “BufFileWrite” 等待事件比例極高，該等待事件表示進(jìn)程正在等待將BUFFER內(nèi)容寫出到文件。“BufFileWrite” 等待事件，通常意味著進(jìn)程在進(jìn)行寫臨時(shí)文件操作。走到這里已經(jīng)很明顯了，可以確定是由于特定的SQL導(dǎo)致了系統(tǒng)的IO問題。接下來就是要找到這個(gè)“罪魁禍?zhǔn)?rdquo;，即確認(rèn)問題SQL并對其進(jìn)行優(yōu)化。

3.確認(rèn)問題SQL：再次分析KSH報(bào)告，找到等待“BufFileWrite”事件的SQL，確認(rèn)問題SQL如下：

4.分析優(yōu)化SQL：可以看到SQL采取hash join，而hash操作引發(fā)的磁盤寫，是引發(fā)大量磁盤IO的原因。

去掉hint后，執(zhí)行計(jì)劃如下：

可以看到，去掉hint之后，SQL采用索引掃描了，不但I(xiàn)O減少了很多，速度也更快了。

5.跟應(yīng)用開發(fā)人員溝通后，確認(rèn)是前期適配時(shí)，由于測試環(huán)境數(shù)據(jù)量較少，通過加hint (/*+set(enable_nestloop OFF)*/)，可以獲得更快的性能。而現(xiàn)在模擬生產(chǎn)環(huán)境測試時(shí)，測試數(shù)據(jù)量成倍增加，hint 不再適用。

6.修改SQL：協(xié)調(diào)應(yīng)用開發(fā)人員修改SQL，再次驗(yàn)證。

9月21日凌晨4點(diǎn)

確認(rèn)經(jīng)過修改，數(shù)據(jù)庫不再有IO 問題，壓測下，之前出現(xiàn)的卡死現(xiàn)象也未在出現(xiàn)。

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

完善的配套工具將我從問題的泥潭中解救，讓問題定位和解決的速度得到了飛速提升，客戶終于露出了笑臉。為了確保后續(xù)上線的順利，我和現(xiàn)場的同事不敢放松，擔(dān)心還會有潛在的風(fēng)險(xiǎn)，因此決定再進(jìn)行一遍“排雷”行動。因?yàn)橛泄ぞ叩募映郑屛覀冇行判哪茉趲仔r(shí)內(nèi)完成之前可能幾天都完成不了的事情。

9月21日凌晨5點(diǎn)

說干就干，應(yīng)用開發(fā)商繼續(xù)進(jìn)行對業(yè)務(wù)進(jìn)行壓測，我們在業(yè)務(wù)運(yùn)行過程中，采用各類巡檢手段，配合使用KWR對數(shù)據(jù)庫狀態(tài)開始進(jìn)行全面檢測，以排查可能還未被發(fā)現(xiàn)的“雷區(qū)”，果然，在持續(xù)的測試和監(jiān)控過程中，早上大約7點(diǎn)多，我發(fā)現(xiàn)系統(tǒng)CPU使用率此時(shí)非常高，但I(xiàn)O正常，顯然這不太正常。這下心又提到了嗓子眼，我趕緊展開新一輪的排查：

1.先確認(rèn)最耗CPU的進(jìn)程：使用top命令，查看最消耗CPU資源的進(jìn)程，確認(rèn)這些進(jìn)程都是kingbase進(jìn)程。

2.確認(rèn)數(shù)據(jù)庫等待事件：查看數(shù)據(jù)庫的 KWR報(bào)告，確認(rèn)數(shù)據(jù)庫的時(shí)間都花在CPU上，沒有明顯的等待事件。從這些現(xiàn)象可以推斷進(jìn)程狀態(tài)是正常的，特定SQL性能不佳，消耗大量CPU資源。

3.準(zhǔn)確定位SQL： KWR工具也提供了TOPSQL功能，可以根據(jù)CPU、IO、執(zhí)行時(shí)間對SQL進(jìn)行排序。對于當(dāng)前問題，通過查看“Top SQL By Elaspsed Time”章節(jié)，可以快速確定出最消耗CPU的SQL。。

4.SQL 效率分析：完整的SQL有4次調(diào)用了以上的子查詢，而且子查詢用到了窗口函數(shù)，窗口函數(shù)是最消耗CPU資源的。這部分對于性能的消耗如下：

5.可以看到，這部分簡單的查詢需要 768ms，4次調(diào)用總共需要3秒。因此可以考慮通過提取公共表達(dá)式(CTE)，整條SQL可以減少時(shí)間2秒左右。

通過提取SQL的公共表達(dá)式，將以上的子查詢提取到CTE。

9月21日上午10點(diǎn)

修改完SQL后，再次運(yùn)行KWR，確認(rèn)以上SQL性能問題得以解決。

接下來，一切都比較順利，但我們?nèi)匀徊桓曳潘删?，時(shí)刻關(guān)注數(shù)據(jù)庫的運(yùn)行狀態(tài)，好在有KWR和KSH能幫助我們快速進(jìn)行相關(guān)數(shù)據(jù)的收集，幫助我們做到心中有數(shù)，同時(shí)通過收集的數(shù)據(jù)，使用數(shù)據(jù)庫自帶的診斷工具——KDDM，對報(bào)告進(jìn)行階段性分析，進(jìn)一步診斷性能問題，為開發(fā)商又提供了一些優(yōu)化建議，比如下面的索引建議：

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

2.分析執(zhí)行計(jì)劃：從初始的執(zhí)行計(jì)劃看，執(zhí)行效率非常低。

3.KDDM 優(yōu)化建議：建議創(chuàng)建o.f_creattime 索引

4.根據(jù)KDDM的建議，創(chuàng)建索引后的執(zhí)行計(jì)劃如下：

5.可以看到，根據(jù)KDDM建議，創(chuàng)建索引后，SQL的執(zhí)行效率提升了500倍。

經(jīng)過24小時(shí)的奮戰(zhàn)，客戶的業(yè)務(wù)系統(tǒng)順利上線，并通過使用高峰期，隨著客戶宣布項(xiàng)目上線成功，項(xiàng)目組的房間里響起了熱烈的掌聲，掌聲既是對全體項(xiàng)目成員的感謝，也是對金倉產(chǎn)品和金倉人的肯定。

而我最要感謝的是我們研發(fā)團(tuán)隊(duì)為我們DBA提供的數(shù)據(jù)收集和診斷工具，幫我們從繁雜的數(shù)據(jù)中提煉出價(jià)值信息，讓我們能夠更高效輕松地面對現(xiàn)場優(yōu)化問題。

走出客戶大樓，吸一口北京秋天清冽的空氣，這24小時(shí)不是終點(diǎn)，數(shù)據(jù)庫國產(chǎn)化之路還會遇到很多棘手問題，但是作為人大金倉的一員，我有信心，我們將通過不斷打造產(chǎn)品能力，為用戶創(chuàng)造更多的價(jià)值。

（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）