Db2 數(shù)據(jù)庫堵塞怎么辦

作為一個數(shù)據(jù)庫管理員，工作中經(jīng)常會遇到的一個問題：當數(shù)據(jù)庫出現(xiàn)故障的情況下，如何快速定位問題和找到解決方案。尤其是在運維非常重要系統(tǒng)的時候，解決問題恢復(fù)服務(wù)是分秒必爭。Db2 作為廣泛使用的商業(yè)數(shù)據(jù)庫，內(nèi)部提供了眾多方法論和診斷工具等來協(xié)助分析問題。然而當問題真正發(fā)生的時候，數(shù)據(jù)庫管理員還是會手忙腳亂，不知道從何處下手。如果著手分析的方向發(fā)生了錯誤，時間更是浪費嚴重，問題得不到及時解決，甚至有可能采取了錯誤的措施，導(dǎo)致更嚴重的后果。

導(dǎo)致數(shù)據(jù)庫堵塞原因有很多，即便是現(xiàn)在總結(jié)，也僅僅是總結(jié)曾經(jīng)遇到過的情況。即便是曾經(jīng)遇到的問題重復(fù)發(fā)生的時候，快速找到源頭并處理也是很大的挑戰(zhàn)。這個時候腦子里想著方法論，手上敲著各種診斷工具的命令，從輸出的結(jié)果再繼續(xù)分析處理。整個過程即便是非常有經(jīng)驗的數(shù)據(jù)庫管理員也需要很多操作時間。如果可以針對常見的堵塞問題，開發(fā)出一個自動分析的工具，直接展示堵塞原因和處理語句，就能夠大大加快處理的速度。這也是一直以來數(shù)據(jù)庫管理員亟需的工具。然而因為導(dǎo)致數(shù)據(jù)庫堵塞原因的多樣性和未知性，寫這樣一個工具并不容易，所以市場上并沒有這樣的成熟工具。

退而求其次，僅僅針對常見的堵塞問題，是可以開發(fā)出這樣的一鍵檢查處理工具的。所以我開發(fā)了一個簡單的 python 腳本，幫助分析日常工作中的遇到的數(shù)據(jù)庫問題。后續(xù)也需要慢慢加強和改進。最重要的是，寫這個文章是為了總結(jié)幾種 Db2 數(shù)據(jù)庫常見的堵塞問題并提供解決方案。

開發(fā)這個工具的時候，我聯(lián)想到在以前遇到過數(shù)據(jù)庫堵塞問題的時候，數(shù)據(jù)庫甚至都沒有辦法連接，新請求也會被堵塞住。db2top 等命令完全出不來結(jié)果。只有 db2pd 這樣的工具能夠使用。db2pd 工具是從內(nèi)存直接獲取信息，不需要連接數(shù)據(jù)庫，屬于輕量級的診斷工具。所以在數(shù)據(jù)庫發(fā)生堵塞，數(shù)據(jù)庫無法連接的情況下，db2pd 是最好的選擇。

DB2 數(shù)據(jù)庫堵塞怎么辦？首先是快速定位原因，使用 db2pd 將常見的堵塞現(xiàn)象分析一遍。如果定位到是曾經(jīng)碰到的問題，那就比較好辦了，趕緊實行對應(yīng)的解決方案。如果不是常見的問題，盡量收集足夠多的信息，例如 stack 等，然后重啟實例恢復(fù)數(shù)據(jù)庫，但是這樣可能堵塞問題還是會重現(xiàn)，不能根本解決問題。

Db2 數(shù)據(jù)庫常見堵塞問題

Db2 數(shù)據(jù)庫發(fā)生性能緩慢或者堵塞的最常見現(xiàn)象是數(shù)據(jù)庫活動會話激增，數(shù)據(jù)庫相關(guān)命令和語句運行緩慢。導(dǎo)致性能緩慢的原因有很多，最常見的可能是出現(xiàn)鎖問題。一個長 sql 堵塞其他相關(guān) sql，導(dǎo)致短時間并發(fā) sql 變多，系統(tǒng)變慢。也有可能是出現(xiàn)了大 sql，耗盡系統(tǒng)資源等。如下圖所示，我歸納列舉了一些常見的堵塞原因，整理了相關(guān)問題解決的方法。

圖 1. Db2 常見堵塞問題分析

圖中所列的這些問題都可以通過 db2pd 工具獲取信息來分析。我也在一鍵檢查分析工具里面包含了這些場景。

鎖鏈分析和處理

Db2 的鎖機制與其他數(shù)據(jù)庫差異很大，鎖問題也是在數(shù)據(jù)庫運維中重點關(guān)注的對象。鎖是用來控制事務(wù)的一致性和并發(fā)性的。Db2 的隔離級別和其他數(shù)據(jù)庫差不多，都是解決臟讀，幻讀，不可重復(fù)讀等問題。然而不同于其他數(shù)據(jù)庫，Db2 的鎖是存放在內(nèi)存里的。數(shù)據(jù)庫的 locklist 參數(shù)控制這個內(nèi)存的大小。如果出現(xiàn)某個實務(wù)需要加的鎖特別多，可能會導(dǎo)致這個內(nèi)存里放不下，觸發(fā)鎖升級。鎖升級更容易引起堵塞。

發(fā)現(xiàn)鎖堵塞

一個正常運行的數(shù)據(jù)庫突然出現(xiàn)鎖問題通常有兩種情況： 一種是運行了不常運行的 SQL 事務(wù)，堵塞了正常的交易。一種是正常的交易事務(wù)突然性能有問題，例如查詢計劃改變。不管是哪種情況，最緊要的是將源頭找出來。db2top 工具有一個非常好用的功能，就是查看鎖鏈的信息。

清單 1. db2top 查看鎖鏈

在這個輸出里面，1546 這個應(yīng)用是鎖的持有者，其他都是等待者。下一步就是分析 1546 在執(zhí)行什么語句，是否需要殺，是否需要優(yōu)化。

然而對于已經(jīng)堵塞的 Db2 數(shù)據(jù)庫，db2top 可能根本打不開。這個時候就需要 db2pd 工具來查看鎖等待的信息。

清單 2. db2pd 查看鎖等待

在這個 db2pd 的輸出里面，第八列 Sts 就是持有者（G）和等待者（W）。第四列 lockname 是對應(yīng)的鎖。需要綜合這兩個信息，才能知道應(yīng)用的等待關(guān)系。這里分析鎖等待關(guān)系并不是非常直觀。所以我在開發(fā)的工具里結(jié)合 lockname 和鎖狀態(tài)信息組織出鎖鏈關(guān)系，然后展示出來。

分析鎖問題

基于上述信息，找到鎖的持有者源頭，現(xiàn)在還需要知道持有者在運行什么語句。這個可以通過 db2pd 的 application 選項和 dynamic 選項綜合分析出當前正在執(zhí)行和上次執(zhí)行的語句。

清單 3. db2pd 查看 application

在 db2pd 工具的 application 輸出里面，C-AnchID 和 C-StmtUID 結(jié)合起來指向當前正在運行的語句。L-AnchID 和 L-StmtUID 結(jié)合起來指向上一次執(zhí)行的語句。要獲得詳細的語句，需要從 dynamic cache 里找到。圖中 C-AnchID 和 C-StmtUID 都是 0，也就是當前應(yīng)用沒有執(zhí)行任何語句。而 L-AnchID 和 L-StmtUID 是 341 和 2，上一次執(zhí)行的語句是可以獲取到的。

清單 4. db2pd 查看動態(tài)語句

基于 L-AnchID 為 341 去查 dynamic cache，可以看到 StmtUID 為 2 的 sql 語句是"select * from t with rr"。至此就得到了鎖的持有者正在運行的語句或者最后運行的語句是什么。這樣就可以和開發(fā)一起分析這個問題是什么原因?qū)е碌摹?/p>

處理鎖問題

通常異常出現(xiàn)鎖問題的原因分兩種：

• 不常見的 SQL：當前 SQL 不是業(yè)務(wù)常用 SQL，例如新上線的功能，管理節(jié)點發(fā)起的維護 SQL，或者個人后臺發(fā)起的 SQL 等。因為測試不充分，沒有評估好對生產(chǎn)業(yè)務(wù)的影響。這種情況下一般選擇先殺掉，并且控制不要再次發(fā)起，等優(yōu)化完再上線。
• 常見 SQL 突然變慢：例如執(zhí)行計劃發(fā)生變化，導(dǎo)致 SQL 變慢，從而促發(fā)了鎖競爭的問題。這種情況僅僅殺 SQL 可能是不管用的，因為 SQL 還會被調(diào)用起來。這時需要立刻獲取 SQL 的查詢計劃，抓緊時間調(diào)優(yōu)。例如運行 runstats，創(chuàng)建必要的索引等方式。

我在 Db2 堵塞一鍵檢查工具里面對上述操作進行了自動化分析和處理。

清單 5. 一鍵檢查工具分析鎖問題

工具在分析鎖問題的時候，首先展示鎖鏈并排序，然后找到所有鎖鏈中鎖持有者執(zhí)行的 SQL 語句，并將需要快速殺應(yīng)用的語句打印出來，便于快速決策是否調(diào)用。

latch 鏈分析和處理

Db2 的 latch 是一個教科書里沒有詳細闡述也無法詳細枚舉所有 latch 種類的機制。Latch 簡單來說就是線程鎖。它和 Db2 的鎖不一樣但是堵塞時的現(xiàn)象差不多，都是一個線程獲取到了 latch，堵塞了其他需要這個 latch 的線程。Latch 促發(fā)的問題可能還要嚴重。Lock 通過殺掉持有者的 apphdl 還可以釋放，Latch 的持有者可能并不是應(yīng)用，可能是 Db2 的其他內(nèi)部線程，是沒有開放接口去殺的。這種情況下只有等待或者重啟實例。

latch 問題可能是數(shù)據(jù)庫管理員最頭疼的問題。因為通常這種問題牽涉的是 Db2 開發(fā)的內(nèi)部機制，屬于未公開的信息?；旧线@個時候能做的只是想辦法解開 latch，收集信息給 IBM 支持團隊分析原因。

查看 latch 堵塞

處理這類問題首先是監(jiān)控是否發(fā)生了 latch 等待：

清單 6. db2pd 查看 latch 等待

圖中的輸出信息分兩個主要部分。第一部分是有持有者的 latch 信息，包含有等待的和沒等待的。沒有等待者的持有者是不需要關(guān)心的。第二部分是找不到持有者但是有等待者的 latch 信息。相對第一部分，這個是因為持有者在內(nèi)部開發(fā)的代碼里沒有顯示給監(jiān)控，并不是真的沒有持有者。解讀下這個輸出里面的內(nèi)容：

• Address：latch 地址，唯一定位一個 latch 對象。
• Holder：latch 的持有者。這是個 EDUID。
• Waiter：latch 的等待者。這是個 EDUID。
• Filename：獲取這個 latch 的源文件名。
• LOC：源文件里的代碼位置。
• LatchType：latch 名稱。
• HoldCount：持有數(shù)量。

上面這個例子包含三種場景：

• latch 地址為 0x0780000004F00478 的持有者是 1553，等待者是 0 也就是沒有等待者。這是一個正常的現(xiàn)象，不需要去關(guān)注。
• latch 地址為 0x0A00050000069D20 的持有者是 33105，等待者有 589675 和 528805。這是一個典型的堵塞現(xiàn)象。33105 堵塞了 589675 和 528805。這個 latch 的名稱是 SQLO_LT_SQLP_DBCB__add_logspace_sem。
• latch 地址為 0x0A0005059594A800 和 0x0A00050225DAA938 沒有顯示持有者（顯示持有者的代價太高，所以 Db2 內(nèi)部屏蔽了），但是分別有等待者 529319 和 415209。這個 latch 的名稱是 SQLO_LT_SQLB_BPD__bpdLatch_SX。

Latch 的等待信息是瞬間抓取的，如果想要確定是否存在堵塞現(xiàn)象，需要多抓一次 latch 信息來確認。在確認了 latch 堵塞問題的情況下，需要抓取 stack 來獲取詳細信息給 IBM 的支持開 case。Latch 問題的處理里面 stack 是關(guān)鍵信息。發(fā)生競爭的 latch 持有者和等待者都需要抓取 stack。抓取 stack 的語句是：db2pd -stack <eduid> 。 這里的 eduid 輸入就是 latch 選項輸出里面的 Holder 和 Waiter。

分析 latch 堵塞對象

如果是有持有者的堵塞現(xiàn)象，可以檢查持有者是什么 EDU，是否對應(yīng)到 application，然后確定能否通過解決持有者的方式釋放這個堵塞問題。

清單 7. db2pd 查看 edu 等待

通過 db2pd 工具能夠查看 EDUID 對應(yīng)的 EDU Name 是什么。如果 EDU Name 是 db2agent，那么就能對應(yīng)到一個 application。這個時候查看對應(yīng)數(shù)據(jù)庫的 applications 輸出，就找到 CoorEDUID 對應(yīng)的 AppHandl 了。

清單 8. db2pd 查看 application

找到了 AppHandl，就可以查看到對應(yīng)的 SQL 語句是什么，知道這個應(yīng)用在做什么。方法分析鎖問題的時候找 SQL 一樣。最后嘗試"db2 force application (<AppHandl>)" ，運氣好的話這個堵塞問題可能就暫時解決了。

處理 latch 堵塞問題

獲取到 latch 名稱后，首先去 IBM 網(wǎng)站查找這個 latch 的關(guān)鍵詞，看看有沒有已知的問題現(xiàn)象一致，有沒有解決辦法。最后一定要開 CASE 找 IBM 官方支持，找到真正原因，避免再出現(xiàn)這樣的問題。我在一鍵檢查工具里面按照這個思路處理 latch 問題。

清單 9. 一鍵檢查工具分析 latch 問題

這個工具會對每個出現(xiàn)堵塞的 latch 地址展開 latch 鏈，然后對相關(guān) eduid 收集 stack，最后嘗試找到這些 eduid 對應(yīng)的 apphandl 和 sql 語句。如果持有者對應(yīng)到 apphandl，那么也把處理的 force 語句打印出來。