在DB2日常營運中,我們時常會碰到某幾條sql執行很慢,但是資料庫伺服器cpu和記憶體使用量率又不高的情況,類似的問題基本上由於鎖、排序等原因造成的。下面就從一個執行個體來分析如何去快速定位鎖等待問題以及鎖在那個表。
一、鎖在日誌中的資訊
當你在資料庫日誌DB2DIAG.LOG中發現大量sqlcode報911資訊時,一般都是有鎖等待問題。
2014-01-03-10.05.26.616285+480 I4936115E839 LEVEL: Severe
PID : 16724 TID : 47174238857536PROC : db2sysc 0
INSTANCE: db2inst1 NODE : 000 DB : PORTALDB
APPHDL : 0-47283 APPID: 10.4.125.115.38673.140109201531
AUTHID : IPORTAL
EDUID : 88 EDUNAME: db2agent (PORTALDB) 0
FUNCTION: DB2 UDB, relation data serv, sqlrr_array_input, probe:210
DATA #1 : SQLCA, PD_DB2_TYPE_SQLCA, 136 bytes
sqlcaid : SQLCA sqlcabc: 136 sqlcode: -911 sqlerrml: 1
sqlerrmc: 2
sqlerrp : SQLRI2C4
sqlerrd : (1) 0x80100002 (2) 0x00000002 (3) 0x00000000
(4) 0x00000000 (5) 0xFFFFFE0C (6) 0x00000000
sqlwarn : (1) (2) (3) (4) (5) (6)
(7) (8) (9) (10) (11)
二、DB2PD分析鎖等待
db2pd工具主要用於收集 DB2 執行個體和資料庫的統計資訊,db2pd的最大優點是資訊擷取非常快,並 且不需要消耗資料庫引擎資源。使用這種強大的工具,必須具有 SYSADMIN 許可權,而且在 UNIX或 Linux環境中必須是執行個體的所有者。
$db2pd -db portaldb -app|more #擷取應用程式的資訊
Database Partition 0 -- Database PORTALDB -- Active -- Up 17 days 07:04:15 -- Date 2014-01-10-15.33.14.983796
Applications:
Address AppHandl [nod-index] NumAgents CoorEDUID Status C-AnchID C-StmtUID L-AnchID L-StmtUID Appid
WorkloadID WorkloadOccID CollectActData CollectActPartition CollectSectionActuals
0x0000000201050080 26 [000-00026] 1 61 ConnectCompleted 0 0 0 0 *LOCAL.DB2.131224002909
0 0 N C N
0x0000000201450080 47914 [000-47914] 1 104 UOW-Waiting 0 0 677 41 10.4.125.114.11658.140110014742
1 3694 N C N
0x0000000200F80080 19 [000-00019] 1 54 UOW-Waiting 0 0 0 0 *LOCAL.DB2.131224002902
0 0 N C N
進一步分析找到applid為47914的 anchid
$db2pd -db portaldb -app|grep -i "47914"
0x0000000201450080 47914 [000-47914] 1 104 UOW-Waiting 0 0 98 1 10.4.125.114.11658.140110014742 1 3694 N C N
0x0000000201450080 47914 [000-47914] 10.4.125.114 None IPORTAL
0x0000000201450080 47914 [000-47914] n/a
--anchid 為98
--然後使用db2pd -dynamic 功能, 根據anch =98 尋找出該47914應用id號對應的正在執行的sql(v9以上版本適用,v8版本db2pd -dynamic無anch= **這個選項)
$db2pd -db portaldb -dynamic anch=98|more
System Temp Table Stats:
Number of System Temp Tables : 69817
Comp Eligible Sys Temps : 0
Compressed Sys Temps : 0
Total Sys Temp Bytes Stored : 16140381976
Total Sys Temp Bytes Saved : 0
Total Sys Temp Compressed Rows : 0
Total Sys Temp Table Rows: : 1134615144
User Temp Table Stats:
Number of User Temp Tables : 720
Comp Eligible User Temps : 0
Compressed User Temps : 0
Total User Temp Bytes Stored : 90045
Total User Temp Bytes Saved : 0
Total User Temp Compressed Rows : 0
Total User Temp Table Rows: : 551
Database Partition 0 -- Database PORTALDB -- Active -- Up 17 days 07:06:14 -- Date 2014-01-03-15.35.13.996815
Dynamic Cache:
Current Memory Used 733842896
Total Heap Size 1675218370
Cache Overflow Flag 0
Number of References 19142165
Number of Statement Inserts 151614
Number of Statement Deletes 116009
Number of Variation Inserts 116930
Number of Statements 35605
Dynamic SQL Statements:
Address AnchID StmtUID NumEnv NumVar NumRef NumExe Text
0x00002AEA103CF0C0 98 90 1 1 1 1 select count(*) as col_0_0 from KC_USER user0_ where user0_.USER_ID=349289
---同樣也可以使用擷取快照的方式來看當前applid為47914的application在執行什麼sql
$db2 get snapshot for application agentid 47914
當你發現是這樣一條查詢語句發生了鎖等,可以立即終止鎖等
方法是:
$db2 "force application(47914)"
註:後來聯絡開發,知道他們正在修改KC_USER表,長時間沒有提交,所以造成了大量有關這個表的鎖等。事務提交後,該問題解決。
總結:
通過上面的執行個體分析,我們簡單描述了一個db2鎖問題和語句的定位方法,希望能給大家在分析和定位應用效能問題的時候起到一定的協助。
本文出自 “滴水穿石孫傑” 部落格,謝絕轉載!