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

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

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

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

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

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

Db2 數(shù)據(jù)庫(kù)常見(jiàn)堵塞問(wèn)題

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

圖 1. Db2 常見(jiàn)堵塞問(wèn)題分析

圖中所列的這些問(wèn)題都可以通過(guò) db2pd 工具獲取信息來(lái)分析。我也在一鍵檢查分析工具里面包含了這些場(chǎng)景。

鎖鏈分析和處理

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

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

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

清單 1. db2top 查看鎖鏈

[\]16:01:41,refresh=0secs(0.008) Locks  AIX,member=[4/4],DB2GDPC:CHGMDB[d=Y,a=N,e=N,p=ALL][qp=off] +---------------------------------------------------------------------------------+ |   | | Blocker->Blocked Agent Chain      | | --------------------------------------------------------------------------- | | 1546->64481->1309       | |   | |   | |   | |   | |   | |   | |   | |   | |   | |   | |   | | Press any key to resume...       | +---------------------------------------------------------------------------------+Quit: q, Help: h  Lock=49 (Entries=49), L: Lock Chain  db2top 2

在這個(gè)輸出里面，1546 這個(gè)應(yīng)用是鎖的持有者，其他都是等待者。下一步就是分析 1546 在執(zhí)行什么語(yǔ)句，是否需要?dú)ⅲ欠裥枰獌?yōu)化。

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

清單 2. db2pd 查看鎖等待

AGDPCMB1:/home/db2gdpc$db2pd -d chgmdb -wlocksksh: There is not enough space in the file system. Database Member 0 -- Database CHGMDB -- Active -- Up 19 days 01:18:29 -- Date2018-02-27-16.52.48.487758 Locks being waited on :AppHandl [nod-index] TranHdl Lockname   Type Mode Conv Sts CoorEDU AppName AuthID AppID 1546 [000-01546] 39  00030418000000000000000452 RowLock ..X G 176565 db2bp DB2GDPC *N0.db2gdpc.180430224639 1309 [000-01309] 40  00030418000000000000000452 RowLock ..X W 323302 db2bp DB2GDPC *N0.db2gdpc.180430224640  1546 [000-01546] 39  00030418000000000000000054 TableLock .IX G 176565db2bp DB2GDPC *N0.db2gdpc.180430224639 1309 [000-01309] 40  00030418000000000000000054 TableLock .IX G 323302 db2bp DB2GDPC *N0.db2gdpc.180430224640 64481 [000-64481] 3  00030418000000000000000054 TableLock ..S W 394879db2bp DB2GDPC *N0.db2gdpc.180430224637

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

分析鎖問(wèn)題

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

清單 3. db2pd 查看 application

AGDPCMB1:/home/db2gdpc$db2pd -d chgmdb -application 1546 Database Member 0 -- Database CHGMDB -- Active -- Up 20 days 18:31:55 -- Date 2018-03-01-10.06.14.595025 Applications:Address  AppHandl [nod-index] NumAgents CoorEDUID Status   C-AnchID C-StmtUID L-AnchID L-StmtUID Appid WorkloadID WorkloadOccID CollectActData  CollectActPartitionCollectSectionActuals 0x0A00020042CA0080 1546 [000-1546] 1  147263 UOW-Waiting  0 0  341 2  *N0.db2gdpc.1805040253241  37352  N   C   N  External Connection AttributesAddress  AppHandl [nod-index] ClientIPAddress EncryptionLvl SystemAuthID 0x0A00020042CA0080 1546 [000-1546] n/a     None DB2GDPC  Trusted Connection AttributesAddress  AppHandl [nod-index] TrustedContext ConnTrustType  RoleInherited 0x0A00020042CA0080 1546 [000-1546] n/a non trusted   n/a  Autonomous Routine ConnectionsAddress  AppHandl [nod-index] Status  Autonomous Routine Handl [nod-index] Status  Anonymous Block ConnectionsAddress  AppHandl [nod-index] Status  Anonymous Block Handl [nod-index] Status

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

清單 4. db2pd 查看動(dòng)態(tài)語(yǔ)句

AGDPCMB1:/home/db2gdpc$db2pd -d chgmdb -dynamic anch=341 Database Member 0 -- Database CHGMDB -- Active -- Up 20 days 19:16:16 -- Date 2018-03-01-10.50.35.125266 Dynamic Cache:Current Memory Used  1700359Total Heap Size  130191196Cache Overflow Flag  0Number of References  83506Number of Statement Inserts 74444Number of Statement Deletes 74408Number of Variation Inserts 48Number of Statements  36 Dynamic SQL Statements:Address  AnchID StmtUID NumEnv NumVar NumRef NumExe Text0x0A0005024E0EE9A0 341 2  1  1  3  3  select * from t with rr Dynamic SQL Environments:Address  AnchID StmtUID EnvID Iso QOpt Blk0x0A0005024E0EE520 341 2  2  CS 5 B Dynamic SQL Variations:Address  AnchID StmtUID EnvID VarID NumRef Typ Lockname Val Insert Time  Sect Size Num Copies0x0A0005024E0BEE60 341 2  2  1  2  6 000000020000000200012AA0D6 Y 2018-03-01-09.06.10.891027 6056 0

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

處理鎖問(wèn)題

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

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

我在 Db2 堵塞一鍵檢查工具里面對(duì)上述操作進(jìn)行了自動(dòng)化分析和處理。

清單 5. 一鍵檢查工具分析鎖問(wèn)題

AGDPCMB1:/home/db2gdpc$python db2_check_hang_105.py chgmdb lock ################################################################################    Lock Analyze    ################################################################################ #The lock chains are:["15412", "15657"]["15412", "19008"]#The root lock holders are: ["15412"]#The stmt for applicaiton 15412 is:The current stmt is:NULL .The last stmt is: select * from t with rr .#You can force the holders by:db2 "force application (15412) "

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

latch 鏈分析和處理

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

latch 問(wèn)題可能是數(shù)據(jù)庫(kù)管理員最頭疼的問(wèn)題。因?yàn)橥ǔ＿@種問(wèn)題牽涉的是 Db2 開(kāi)發(fā)的內(nèi)部機(jī)制，屬于未公開(kāi)的信息。基本上這個(gè)時(shí)候能做的只是想辦法解開(kāi) latch，收集信息給 IBM 支持團(tuán)隊(duì)分析原因。

查看 latch 堵塞

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

清單 6. db2pd 查看 latch 等待

AGDPCMB1:/home/db2gdpc$db2pd -latchesDatabase Member 0 -- Active -- Up 30 days 00:11:52 -- Date 2017-12-01-17.11.29.074912 Latches:Address  Holder Waiter Filename  LOC LatchType  HoldCount 0x0780000004F00478 1553 0  ../include/sqle_workload_disp.h 1391 SQLO_LT_sqeWLDispatcher__m_tunerLatch 1  0x0A00050000069D20 33105 589675 sqlpgResSpace.C 542 SQLO_LT_SQLP_DBCB__add_logspace_sem 1  0x0A00050000069D20 33105 528805 sqlpgResSpace.C 542 SQLO_LT_SQLP_DBCB__add_logspace_sem 1   Latch Waiters With No Holders:Address  Holder Waiter Filename  LOC LatchType  0x0A0005059594A800 0  529319 /view/db2_v105fp7_aix64_s151221/vbs/engn/include/sqlpt_inlines.h 2186 SQLO_LT_SQLB_BPD__bpdLatch_SX0x0A00050225DAA938 0  415209 /view/db2_v105fp7_aix64_s151221/vbs/engn/include/sqlpt_inlines.h 2186 SQLO_LT_SQLB_BPD__bpdLatch_SX

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

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

上面這個(gè)例子包含三種場(chǎng)景：

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

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

分析 latch 堵塞對(duì)象

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

清單 7. db2pd 查看 edu 等待

AAGDPCMB1:/home/db2gdpc$db2pd -edus Database Member 0 -- Active -- Up 21 days 00:00:06 -- Date 2018-03-01-15.26.59.059962 List of all EDUs for database member 0 db2sysc PID: 17760262db2wdog PID: 34930696db2acd PID: 45875450 EDU ID TID     Kernel TID   EDU NameUSR (s)   SYS (s) ===================================================================================================================23561  23561    67373307    db2agnta (XTCUR2) 0     0.232340  0.039394577794 577794    130024209   db2agnta (CHGMDB) 0     0.475758  0.083151526009 526009    21563441    db2loggr (CMPDB) 0      28.628607  4.885121525752 525752    39125599    db2logmgr.0 (CMPDB) 0     10.656058  6.702469525495 525495    58590885    db2castructevent SA (CMPDB) 0   0.000232  0.000020……

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

清單 8. db2pd 查看 application

AGDPCMB1:/home/db2gdpc$db2pd -d chgmdb -applications Database Member 0 -- Database CHGMDB -- Active -- Up 20 days 23:56:31 -- Date 2018-03-01-15.30.50.066987 Applications:Address   AppHandl [nod-index] NumAgents CoorEDUID Status     C-AnchID C-StmtUID L-AnchID L-StmtUID Appid       WorkloadID WorkloadOccID CollectActData   CollectActPartition  CollectSectionActuals 0x0A00020021180080 3842  [000-03842] 1   82548  ConnectCompleted  0  0   0  0   *N0.DB2.180208083025    0   0    N      C      N 0x0780000008B00080 3822  [000-03822] 1   72268  ConnectCompleted  0  0   0  0   *N0.DB2.180208083005    0   0    N      C      N ……

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

處理 latch 堵塞問(wèn)題

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

清單 9. 一鍵檢查工具分析 latch 問(wèn)題

AGDPCMB1:/home/db2gdpc$python db2_check_hang_105.py chgmdb latch ################################################################################Latch Analyse################################################################################    ############### Collect contentions on Address: ##############Address: 0x0A00050000069D20Holder: ["33105"]Waiter: ["589675", "528805"]LatchType: SQLO_LT_SQLP_DBCB__add_logspace_sem####Start analyse contentions:####Collect holder information: #Collect holder info: 33105The apphdl for tid 33105 is 0The last stmt is: No stmt found for 0.No edu found for eduid: 0 #You can force this holder by: ####Collect Waiter information: #Collect waiter info: 589675The apphdl for tid 589675 is 0The last stmt is: No stmt found for 0.No edu found for eduid: 0  #Collect waiter info: 528805The apphdl for tid 528805 is 0The last stmt is: No stmt found for 0.No edu found for eduid: 0    ############### Collect contentions on Address: ##############Address: 0x0A0005059594A800Holder: ["0"]Waiter: ["529319"]LatchType: SQLO_LT_SQLB_BPD__bpdLatch_SX####Start analyse contentions:####No holder on this address, collect stack and sanpshot for waiters: #Collect waiter info: 529319The apphdl for tid 529319 is 0The last stmt is: No stmt found for 0.No edu found for eduid: 0   ############### Collect contentions on Address: ##############Address: 0x0A00050225DAA938Holder: ["0"]Waiter: ["415209"]LatchType: SQLO_LT_SQLB_BPD__bpdLatch_SX####Start analyse contentions:####No holder on this address, collect stack and sanpshot for waiters: #Collect waiter info: 415209The apphdl for tid 415209 is 0The last stmt is: No stmt found for 0.No edu found for eduid: 0

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

查看當(dāng)前運(yùn)行時(shí)間長(zhǎng)的 SQL 語(yǔ)句

Db2 出現(xiàn)運(yùn)行緩慢如果不是因?yàn)殒i或者 latch 的等待問(wèn)題。這時(shí)就需要看看當(dāng)前哪些 SQL 運(yùn)行的時(shí)間比較長(zhǎng)。我會(huì)挑選 10 條運(yùn)行時(shí)間最長(zhǎng)的 SQL 來(lái)分析。

清單 10. 查看 activestatements

AGDPCMB1:/home/db2gdpc$db2pd -d chgmdb -activestatements Database Member 0 -- Database CHGMDB -- Active -- Up 21 days 00:37:29 -- Date 2018-03-01-16.11.48.180193 Active Statement List:Address   AppHandl [nod-index] UOW-ID  StmtID  AnchID StmtUID EffISO  EffLockTOut EffDegree EntryTime   StartTime   LastRefTime  0x0A0005024E322860 15657 [000-15657] 5   1   548 1   1   3000  0   Thu Mar 1 16:11:38 Thu Mar 1 16:11:38 Thu Mar 1 16:11:380x0A0005024DF5CE60 14933 [000-14933] 2   1   317 1   1   3000  0   Thu Mar 1 16:00:33 Thu Mar 1 16:00:33 Thu Mar 1 16:00:330x0A0005024E147CC0 19008 [000-19008] 6   1   365 2   1   3000  0   Thu Mar 1 16:11:42 Thu Mar 1 16:11:42 Thu Mar 1 16:11:42

這個(gè)輸出里面需要關(guān)注的是 StartTime，按照這個(gè)排序就可以找到運(yùn)行時(shí)間最長(zhǎng)的語(yǔ)句了。和分析鎖堵塞問(wèn)題里的方法一樣。這里的 AnchID 和 StmtUID 可以在 dynamic cache 里面定位到唯一的 SQL 語(yǔ)句。這個(gè)在一鍵檢查工具里面是自動(dòng)收集展示的。

清單 11. 一鍵檢查工具查看 TOP SQL

AGDPCMB1:/home/db2gdpc$python db2_check_hang_105.py chgmdb stmt    ################################################################################       Show top 10 running stmt       ################################################################################ #Check active statements for: CHGMDBThe apphdl is: 14933 , started at : Thu Mar 1 16:00:33  SELECT ID,substr(HOME_HOST,:L0 ,:L1 ) as HOME_HOST,substr(CURRENT_HOST,:L2 ,:L3 ) as CURRENT_HOST,STATE,ALERT FROM SYSIBMADM.DB2_MEMBERThe apphdl is: 15657 , started at : Thu Mar 1 16:11:38  update t set c1 =:L0The apphdl is: 19008 , started at : Thu Mar 1 16:11:42  delete from t

這個(gè)工具基于執(zhí)行時(shí)間排序，只抓取前 10 的 SQL 語(yǔ)句。獲得這些信息后就可以分析有沒(méi)有異常。

查看熱表和相關(guān) SQL 語(yǔ)句

Db2 運(yùn)行緩慢不可忽視的誘因之一就是存在熱點(diǎn)數(shù)據(jù)。通常熱點(diǎn)數(shù)據(jù)會(huì)伴隨鎖等待和 latch 等待等現(xiàn)象，但不是完全堵塞的狀態(tài)。現(xiàn)象就是熱點(diǎn)表相關(guān)的 SQL 會(huì)比正常情況下慢很多，從而導(dǎo)致整個(gè)數(shù)據(jù)庫(kù)運(yùn)行緩慢。

獲取熱點(diǎn)表

當(dāng)數(shù)據(jù)庫(kù)出現(xiàn)緩慢的時(shí)候，如果想要從熱點(diǎn)數(shù)據(jù)的角度去分析問(wèn)題，找到對(duì)應(yīng)的表，然后再找到對(duì)應(yīng)的熱點(diǎn)語(yǔ)句，就可以分析是否存在問(wèn)題，是否需要優(yōu)化。db2top 首頁(yè)鍵入 T 可以進(jìn)入 Tables 的監(jiān)控界面。在這個(gè)界面里能看到 Delta RowsRead 和 Delta RowsWritten 等信息，從而獲取當(dāng)前熱點(diǎn)表信息。

清單 12. db2top 查看熱點(diǎn)表

[/]15:52:03,refresh=2secs(0.003)  Tables  AIX,member=[4/4],DB2GDPC:CHGMDB[d=Y,a=N,e=N,p=ALL]      [qp=off]  Table Delta   Delta Name  RowsRead/s  RowsWritten/s ---------------------------------------- -------------- -------------- DB2GDPC.TEST   0    0 SYSIBM.SYSCOLUMNS  0    0 SYSIBM.SYSCONTEXTATTRIBUTES       0    0 SYSIBM.SYSCONTEXTS 0    0 SYSIBM.SYSDBAUTH  0    0 SYSIBM.SYSEVENTMONITORS0    0 SYSIBM.SYSEVENTTABLES 0    0 SYSIBM.SYSHISTOGRAMTEMPLATEBINS      0    0 SYSIBM.SYSHISTOGRAMTEMPLATES       0    0 SYSIBM.SYSHISTOGRAMTEMPLATEUSE      0    0 SYSIBM.SYSINDEXES  0    0 SYSIBM.SYSNODEGROUPS 0    0 SYSIBM.SYSPLAN  0    0 SYSIBM.SYSROLEAUTH 0    0 SYSIBM.SYSROUTINES 0    0 SYSIBM.SYSSERVICECLASSES0    0 SYSIBM.SYSSTOGROUPS 0    0Quit: q, Help: h   L: top temp storage consumers    db2top 2.

db2top 最強(qiáng)的地方就是能夠自動(dòng)獲取兩次捕獲信息之間的差異并計(jì)算出 Delta 值展示出來(lái)。其他監(jiān)控工具只能獲取當(dāng)前累計(jì)值，需要手工計(jì)算和排序。然而就像之前所擔(dān)心的那樣，db2top 在數(shù)據(jù)庫(kù)緩慢的情況下不一定能工作。這個(gè)時(shí)候只有 db2pd 工具能夠正常使用。db2pd 的 tcbstats 選項(xiàng)可以展示表和索引的累計(jì)訪問(wèn)信息。

清單 13. db2pd 查看表信息

AGDPCMB1:/home/db2gdpc$db2pd -d chgmdb -tcbstats nocatalog Database Member 0 -- Database CHGMDB -- Active -- Up 0 days 01:27:49 -- Date 2018-03-07-15.58.13.184798 TCB Table Information:Address   TbspaceID TableID PartID MasterTbs MasterTab TableName   SchemaNm ObjClass DataSize LfSize  LobSize XMLSize IxReqRebld0x0A0005024DDDDAB0 2   -1  n/a 2   -1  INTERNAL   SYSIBM Perm  1   0   0   0   No0x0A0005024DCF9430 3   1540 n/a 3   1540  LOCKS    DB2GDPC Perm  1787  0   64   0   No0x0A0005024DCF6EB0 3   -1  n/a 3   -1  INTERNAL   SYSIBM Perm  7   0   0   0   No0x0A0005024DDDE8B0 2   5  n/a 2   5   TEST    DB2GDPC Perm  8013  0   0   0   No TCB Table Stats:Address   TableName   SchemaNm Scans  UDI  RTSUDI    PgReorgs NoChgUpdts Reads  FscrUpdates Inserts Updates Deletes OvFlReads OvFlCrtes PgDictsCrt CCLogReads StoreBytes BytesSaved0x0A0005024DDDDAB0 INTERNAL   SYSIBM 0   0   0     0   0   4   0   0   0   0   0   0   0   0   -   -   0x0A0005024DCF9430 LOCKS    DB2GDPC 0   147  147     0   0   0   0   0   0   0   0   0   0   0   -   -   0x0A0005024DCF6EB0 INTERNAL   SYSIBM 0   0   0     0   0   7   0   0   0   0   0   0   0   0   -   -   0x0A0005024DDDE8B0 TEST    DB2GDPC 1   0   0     0   0   592865  0   0   0   0   0   0   0   0   -   -

db2pd 的這個(gè)輸出里面關(guān)注 Scans，Reads，Inserts，Updates 和 Deletes。其中 Scans 表示發(fā)生了表掃描的次數(shù)。Reads，Inserts，Updates 和 Deletes 分別是讀增改刪的次數(shù)。這些值都是累計(jì)值。如果需要當(dāng)前實(shí)際的訪問(wèn)數(shù)量，需要通過(guò)抓取多次取差值排序才能知道。這個(gè)是非常不直觀的。我在一鍵分析工具里面將個(gè)思路實(shí)現(xiàn)，最終通過(guò)計(jì)算出 Reads，Inserts，Updates 和 Deletes 的差值總和來(lái)排序獲取到熱點(diǎn)表。

獲取相關(guān)應(yīng)用和 SQL

獲取到熱點(diǎn)表之后的下一步就是找到當(dāng)前訪問(wèn)這個(gè)熱點(diǎn)表的應(yīng)用 AppHDL 和對(duì)應(yīng)的 SQL 語(yǔ)句。Db2 的默認(rèn)隔離級(jí)別是 RS。即便是查詢(xún)語(yǔ)句，也會(huì)在表上加共享鎖。所以通過(guò)查看當(dāng)前的數(shù)據(jù)庫(kù)鎖信息，找到在熱點(diǎn)表上加了鎖的應(yīng)用就好了。

清單 14. db2pd 查看表鎖信息

AGDPCMB1:/home/db2gdpc$db2pd -d chgmdb -lock showlocks|more Database Member 0 -- Database CHGMDB -- Active -- Up 0 days 02:00:29 -- Date 2018-03-07-16.30.53.779832 Locks:Address   TranHdl Lockname     Type   Mode Sts Owner  Dur HoldCount Att  ReleaseFlg rrIID TableNm   SchemaNm 0x0A0005000761CD00 40   414141414166416415C78BFEC1 PlanLock  ..S G 40   1 0   0x00000000 0x40000000 0  N/A    N/A   414141414166416415C78BFEC1 SQLP_PLAN ({41414141 41664164 15C78BFE}, loading=0)0x0A000500075BD600 13   00030604000000000000000054 TableLock  .IX G 13   1 1   0x00202000 0x40000000 0  LOCKS    DB2GDPC  00030604000000000000000054 SQLP_TABLE (obj={3;1540})0x0A000500075C2F80 14   00030604000000000000000054 TableLock  .IX G 14   1 1   0x00202000 0x40000000 0  LOCKS    DB2GDPC  00030604000000000000000054 SQLP_TABLE (obj={3;1540})0x0A000500075C6380 15   00030604000000000000000054 TableLock  .IX G 15   1 1   0x00202000 0x40000000 0  LOCKS    DB2GDPC  00030604000000000000000054 SQLP_TABLE (obj={3;1540})0x0A0005000761D400 40   00020005000000000000000054 TableLock  .IS G 40   1 0   0x00003000 0x40000000 0  TEST    DB2GDPC  00020005000000000000000054 SQLP_TABLE (obj={2;5})

通過(guò) TableNm 和 SchemaNm 匹配到熱點(diǎn)表，獲取到 TranHdl，然后通過(guò) db2pd 的 transactions 選項(xiàng)找到對(duì)應(yīng)的 AppHandl。例如在這個(gè)案例里面 TEST 是一張熱點(diǎn)表。從鎖信息來(lái)看 TranHdl 為 40 的事務(wù)占用了鎖。下一步通過(guò) TranHdl 找 AppHandl：

清單 15. db2pd 查看事務(wù)信息

AGDPCMB1:/home/db2gdpc$db2pd -d chgmdb -transactions 40  Database Member 0 -- Database CHGMDB -- Active -- Up 0 days 02:04:26 -- Date 2018-03-07-16.34.50.447672 Transactions:Address   AppHandl [nod-index] TranHdl Locks  State Tflag  Tflag2  Firstlsn   Lastlsn   Firstlso    Lastlso    LogSpace  SpaceReserved TID   AxRegCnt GXID  ClientUserID     ClientWrkstnName    ClientApplName     ClientAccntng     0x0A00050001064480 19451 [000-19451] 40   3   READ 0x00000000 0x00000000 0x0000000000000000 0x0000000000000000 0     0     0    0    0x0000081DB04F 1   0  n/a       n/a       n/a       n/a       Total application commits : 806     Total application rollbacks : 25

最后通過(guò)應(yīng)用的 AppHandl 找到對(duì)應(yīng)的 SQL，過(guò)程和前面幾個(gè)案例一樣。

一鍵分析熱點(diǎn)表問(wèn)題

我在一鍵檢查工具里將上述分析過(guò)程自動(dòng)化處理，間隔 10 秒抓取兩次表訪問(wèn)數(shù)據(jù)，計(jì)算差值，然后獲取到熱點(diǎn)表。基于每個(gè)熱點(diǎn)表的當(dāng)前加鎖信息找到對(duì)應(yīng)的事務(wù)和應(yīng)用，展示出當(dāng)前正在執(zhí)行的 SQL。

清單 16. db2pd 查看事務(wù)信息

AGDPCMB1:/home/db2gdpc$python db2_check_hang_105.py chgmdb hottable ################################################################################      Show hot tables and its statements     ################################################################################ #DB2GDPC.TEST is hot.#Reads: 12266 Inserts: 0 Updates: 0 Deletes: 0 Scans: 0#The apphdl on this table are: ["19451", "19452", "19453"]************statements 1 ***********The current stmt is:NULL . The last stmt is: select * from test . ************statements 2 ***********The current stmt is:NULL . The last stmt is: select * from test . ************statements 3 ***********The current stmt is:NULL . The last stmt is: select * from test .

這個(gè)輸出里面的語(yǔ)句是同一個(gè)，執(zhí)行時(shí)間應(yīng)該都超過(guò)了 10 秒，所以 Scans 差值為 0。但事實(shí)上這個(gè) SQL 是走的表掃描。通過(guò)這個(gè)工具可以立刻看到當(dāng)前的熱表，對(duì)應(yīng)的 apphdl 和 SQL。而 apphdl 可以用來(lái)殺 SQL。

查看占用臨時(shí)表的 SQL 語(yǔ)句

Db2 數(shù)據(jù)庫(kù)的 SQL 排序是在內(nèi)存里進(jìn)行的。SHEAPTHRES_SHR 參數(shù)是限制總的排序內(nèi)存大小。SORTHEAP 參數(shù)是限制單個(gè)排序能占用的內(nèi)存大小。當(dāng) SQL 排序的時(shí)候超出任意一個(gè)限制，那么數(shù)據(jù)需要放到系統(tǒng)臨時(shí)表里面來(lái)排序。相對(duì)于內(nèi)存里排序，這個(gè)開(kāi)銷(xiāo)就非常大，SQL 也會(huì)變得慢。如果系統(tǒng)臨時(shí)表對(duì)應(yīng)的磁盤(pán)出現(xiàn)瓶頸，那整個(gè)數(shù)據(jù)庫(kù)也會(huì)運(yùn)行緩慢。

誰(shuí)在占用臨時(shí)表

系統(tǒng)臨時(shí)表是存儲(chǔ)在系統(tǒng)臨時(shí)表空間的一種數(shù)據(jù)庫(kù)自動(dòng)創(chuàng)建和刪除的臨時(shí)表。通過(guò)查看 db2pd 的 tcbstats 選項(xiàng)能夠找到正在使用的臨時(shí)表。

清單 17. db2pd 查看臨時(shí)表

AGDPCMB1:/home/db2gdpc$db2pd -d chgmdb -tcbstats nocatalog Database Member 0 -- Database CHGMDB -- Active -- Up 0 days 19:13:27 -- Date 2018-03-08-09.43.51.707946 TCB Table Information:Address   TbspaceID TableID PartID MasterTbs MasterTab TableName   SchemaNm ObjClass DataSize LfSize  LobSize XMLSize IxReqRebld0x0A0005024DDDDAB0 2   -1  n/a 2   -1  INTERNAL   SYSIBM Perm  1   0   0   0   No0x0A0005024DCF9430 3   1540 n/a 3   1540  LOCKS    DB2GDPC Perm  1787  0   64   0   No0x0A0005024DCF6EB0 3   -1  n/a 3   -1  INTERNAL   SYSIBM Perm  7   0   0   0   No0x0A0005024E1132B0 1   2  n/a 1   2   TEMP (00001,00002) <54365>< Temp  8045  0   0   0   No0x0A0005024DDDE8B0 2   5  n/a 2   5   TEST    DB2GDPC Perm  8013  0   0   0   No TCB Table Stats:Address   TableName   SchemaNm Scans  UDI  RTSUDI    PgReorgs NoChgUpdts Reads  FscrUpdates Inserts Updates Deletes OvFlReads OvFlCrtes PgDictsCrt CCLogReads StoreBytes BytesSaved0x0A0005024DDDDAB0 INTERNAL   SYSIBM 0   0   0     0   0   10   0   0   0   0   0   0   0   0   -   -   0x0A0005024DCF9430 LOCKS    DB2GDPC 0   147  147     0   0   0   0   0   0   0   0   0   0   0   -   -   0x0A0005024DCF6EB0 INTERNAL   SYSIBM 0   0   0     0   0   7   0   0   0   0   0   0   0   0   -   -   0x0A0005024E1132B0 TEMP (00001,00002) <54365>< 0   0   0     0   0   60386  0   592865  0   0   0   0   0   0   126720902 0   0x0A0005024DDDE8B0 TEST    DB2GDPC 5   0   0     0   0   2964325 0   0   0   0   0   0   0   0   -   -

查找表名是 TEMP 的記錄，案例里面是"TEMP (00001,00002)" ，對(duì)應(yīng)的 SchemaNm 是"<54365><DB2GDPC >"（案例里的命令加上 full 選項(xiàng)就能看到全部?jī)?nèi)容：db2pd -d chgmdb -tcbstats nocatalog -full ） 。這里的 54365 就是應(yīng)用的鏈接句柄 AppHdl。DB2GDPC 是連接用戶(hù)也就是 schema。下面基于 AppHdl 就可以找到正在運(yùn)行的 SQL 是什么了。

我在一鍵檢查工具里面通過(guò) db2pd 獲取到所有占用了臨時(shí)表的應(yīng)用鏈接句柄 AppHDL，然后將 SQL 都展示出來(lái)。

清單 18. 一鍵檢查工具查看臨時(shí)表

AGDPCMB1:/home/db2gdpc$python db2_check_hang_105.py chgmdb temptable ################################################################################      Show applications using temptable     ################################################################################ ************Statements for application: 54365 ***********The current stmt is:NULL . The last stmt is: select * from test order by c5 .

獲取到了 SQL 就可以分析是否有異常，如果有異常，判斷是否基于 apphdl 來(lái)殺 SQL。

查看當(dāng)前運(yùn)行的管理操作

Db2 的一些管理類(lèi)操作也可能影響數(shù)據(jù)庫(kù)的性能。所以當(dāng)數(shù)據(jù)庫(kù)緩慢的時(shí)候，我們還需要查看一下當(dāng)前數(shù)據(jù)庫(kù)內(nèi)有哪些管理性的操作。

是否存在統(tǒng)計(jì)信息收集

統(tǒng)計(jì)信息收集（runstats）的對(duì)象是表和索引。Db2 在做 runstats 的時(shí)候需要掃描大量數(shù)據(jù)并計(jì)算，因此是一類(lèi)開(kāi)銷(xiāo)比較大的操作。db2pd 的 runstats 選項(xiàng)可以查看當(dāng)前正在執(zhí)行的 runstats。

清單 19. db2pd 查看 runstats

AGDPCMB1:/home/db2gdpc$db2pd -d chgmdb -runstats  Database Member 0 -- Database CHGMDB -- Active -- Up 12 days 20:23:45 -- Date 2017-12-18-11.02.56.265437  Table Runstats Information: Retrieval Time: 12/18/2017 11:02:56TbspaceID: -6  TableID: -32768Schema: CHGMDB TableName: SERVICE_LOG  Status: In Progress Access: Allow writeSampling: No   Sampling Rate: -Start Time: 12/18/2017 11:02:43 End Time: -     Total Duration: -Cur Count: 61797     Max Count: 500841     Retrieval Time: 12/18/2017 11:02:56TbspaceID: 2  TableID: 5  Schema: DB2GDPC TableName: TEST    Status: Completed  Access: Allow writeSampling: No   Sampling Rate: -Start Time: 12/18/2017 11:01:48 End Time: 12/18/2017 11:01:48Total Duration: 00:00:01Cur Count: 0      Max Count: 0      Index Runstats Information: Retrieval Time: 12/18/2017 11:02:56TbspaceID: 2  TableID: 5  Schema: DB2GDPC TableName: TEST    Status: Completed  Access: Allow writeStart Time: 12/18/2017 11:01:48 End Time: 12/18/2017 11:01:49Total Duration: 00:00:01Prev Index Duration [1]: 00:00:01Prev Index Duration [2]: -Prev Index Duration [3]: -Cur Index Start: 12/18/2017 11:01:48Cur Index: 2   Max Index: 2   Index ID: 2 Cur Count: 0      Max Count: 0

其中 End Time 為空的記錄就是當(dāng)前正在做的 runstats。這里能看到具體是表還是索引正在做 runstats。結(jié)合當(dāng)前的熱點(diǎn)表，長(zhǎng)時(shí)間運(yùn)行的 SQL 等信息一起分析數(shù)據(jù)庫(kù)變慢的原因。

是否存在表重組

數(shù)據(jù)庫(kù)的表和索引重組需要將磁盤(pán)上的數(shù)據(jù)重新整理一遍。這也是一個(gè)比較漫長(zhǎng)和耗資源的操作。db2pd 的 reorgs 選項(xiàng)能找到當(dāng)前正在執(zhí)行的重組操作。

清單 20. db2pd 查看 reorgs

AGDPCMB1:/home/db2gdpc$db2pd -d chgmdb -reorgsDatabase Member 0 -- Database CHGMDB -- Active -- Up 21 days 01:26:55 -- Date 2017-12-26-16.06.06.495099 Table Reorg Information:Address   TbspaceID TableID PartID MasterTbs MasterTab TableName   Type IndexID TempSpaceID0x0A0006024E14FB00 2   5  n/a n/a  n/a  TEST    Offline 0   2    Table Reorg Stats:Address   TableName   Start    End     PhaseStart   MaxPhase Phase  CurCount MaxCount Status Completion0x0A0006024E14FB00 TEST    12/26/2017 16:05:54 n/a     12/26/2017 16:05:55 3   Build  3007  8012  Started 0

找到了正在重組的表，再結(jié)合當(dāng)前的熱點(diǎn)表，長(zhǎng)時(shí)間運(yùn)行的 SQL 等信息一起分析數(shù)據(jù)庫(kù)變慢的原因。

是否存在 load 和 backup

Db2 內(nèi)部有一個(gè)內(nèi)存塊叫做 Utilities heap，用來(lái)做一些管理類(lèi)的操作。這個(gè)內(nèi)存塊的大小由數(shù)據(jù)庫(kù)參數(shù) UTIL_HEAP_SZ 來(lái)控制。例如 load 和 backup 這兩種操作就需要使用這塊內(nèi)存。這個(gè)內(nèi)存不足會(huì)導(dǎo)致 load 和 backup 變慢或者失敗。而 load 和 backup 也是開(kāi)銷(xiāo)比較大的操作。db2pd 工具提供了 utilities 選項(xiàng)查看實(shí)例級(jí)別的此類(lèi)操作。

清單 21. db2pd 查看 utilities

AGDPCMB1:/home/db2gdpc$db2pd -utilities Database Member 0 -- Active -- Up 0 days 20:11:37 -- Date 2018-03-08-10.40.23.994613 Utilities:Address   ID   Type     State  Invoker Priority StartTime   DBName NumPhases CurPhase Description    Progress:Address   ID   PhaseNum CompletedWork    TotalWork     StartTime   Description

數(shù)據(jù)庫(kù)緩慢的時(shí)候第一時(shí)間發(fā)現(xiàn)是否存在管理類(lèi)的操作很有必要。這對(duì)于分析堵塞問(wèn)題的方向很有幫助。這類(lèi)管理性的操作不能隨便處理。需要具體分析它的影響。例如 load 操作如果殺掉，會(huì)導(dǎo)致當(dāng)前表不可用，需要 load 重置。可能導(dǎo)致更壞的結(jié)果。但是基于表的大小，load 的數(shù)據(jù)量可以估算還需要多長(zhǎng)時(shí)間這個(gè)操作會(huì)完成，期間是否可以有辦法加速等。

一鍵檢查分析工具介紹

根據(jù)上述各種導(dǎo)致數(shù)據(jù)庫(kù)堵塞的場(chǎng)景和分析方法，我編寫(xiě)了一個(gè) python 腳本的一鍵檢查分析工具，用來(lái)快速定位和分析數(shù)據(jù)庫(kù)堵塞問(wèn)題。這個(gè)腳本完全基于 db2pd 命令，可以在數(shù)據(jù)庫(kù)堵塞的情況下，避免連接數(shù)據(jù)庫(kù)失敗，從內(nèi)存直接獲取診斷信息。這個(gè)腳本是基于 Db2 10.5 版本編寫(xiě)的，不適用與其他版本。

清單 22. 一鍵檢查工具使用方法

AGDPCMB1:/home/db2gdpc$python db2_check_hang_105.pyusage ./db2_check_hang.py <dbname> <option>#Valid <options> are:all  :collect all information, which is default.lock  : show lock chains and statements of holders, and print killcmd.latch : show latch chains and get snapshot, stack for holders. print killcmd.stmt  : show top 10 running statements and its apolication handler.hottable : show top tables(siud > 1000 in 10 seconds), get running stmt and apphdl.util  : show runstats, reorgs, loads, backup.temptable: show applications using temtable, and show the sql statement.

這是個(gè) python 腳本，需要安裝 python 來(lái)調(diào)用。執(zhí)行用戶(hù)為數(shù)據(jù)庫(kù)實(shí)例用戶(hù)。dbname 是數(shù)據(jù)庫(kù)名。option 選項(xiàng)可以選擇案例里的內(nèi)容。如果不輸入 option，默認(rèn)是 all，收集全部?jī)?nèi)容。如果輸入單項(xiàng)，例如 lock，那么只收集鎖等待相關(guān)的信息。

總結(jié)

導(dǎo)致數(shù)據(jù)庫(kù)堵塞的問(wèn)題根源可能性非常多。處理緊急問(wèn)題最忌慌亂，找錯(cuò)方向浪費(fèi)時(shí)間，選擇錯(cuò)誤的處理步驟，還可能導(dǎo)致問(wèn)題更嚴(yán)重。我經(jīng)歷過(guò)一個(gè)反面案例：某個(gè)分區(qū)數(shù)據(jù)庫(kù)發(fā)生了堵塞問(wèn)題，管理員分析定位到是一個(gè)大事務(wù)造成的。這個(gè)事務(wù)查詢(xún)了大量數(shù)據(jù)并在做插入操作。數(shù)據(jù)庫(kù)管理員一著急殺掉了這個(gè)事務(wù)，導(dǎo)致事務(wù)回滾。結(jié)果這個(gè)事務(wù)回滾非常慢，整整花了兩天才釋放。期間業(yè)務(wù)完全受影響。其實(shí)如果當(dāng)時(shí)評(píng)估下實(shí)際完成的數(shù)據(jù)量是不是已經(jīng)很多，是不是快要完成了，然后耐心等待事務(wù)完成可能會(huì)更快。當(dāng)然這方面的判斷需要依賴(lài)數(shù)據(jù)庫(kù)管理員的處理經(jīng)驗(yàn)。
這個(gè)文章里面將一些常見(jiàn)的原因做了分析和處理。借助一鍵檢查工具，快速分析問(wèn)題和找到解決方案。

參考資源

• Db2 for Linux UNIX and Windows：獲得 DB2 家族產(chǎn)品和特性的描述。
• 參考 IBM DB2 database and SAP software，了解更多 DB2 SAP 相關(guān)內(nèi)容。
• 通過(guò)訪問(wèn) developerWorks 中國(guó) Information Management 專(zhuān)區(qū) 的 Information Management 技術(shù)資源中心獲得更多的文章、教程和多媒體課件等學(xué)習(xí)資源。

好了，以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問(wèn)大家可以留言交流，謝謝大家對(duì)的支持。