——誰占有鎖，誰等待鎖
本次差旅發現過很多死鎖，有很多死鎖定位方式。但是能精確定位的還是比較少。通過本次差旅實踐，發現通過dbpd
來捕捉是最好的，也是最精確的。方法我總結如下：
1） 啟用死鎖監控
db2pdcfg –catch deadlock
當死鎖觸發時，會自動執行db2cos
指令碼（在
%db2dump%/bin
目錄下）。這個指令碼裡呼叫了
db2pd
來將當前資訊捕捉下來，其中主要捕捉的資訊包含如下：
db2pd共捕捉了
locks
（鎖）、
transaction
（事務）、
agents
（動態sql
，這個最重要，是用於定位到
sql）
，該檔案在
db2的診斷目錄下（可以通過
db2 get dbm cfg | grep 「dia」來獲取診斷目錄位置）
3） 分析db2cos
檔案：
a) 首先看-locks showlocks
模組，截圖如下：
找到其中包含【sts
】為w*
，並且根據【release***】定位到相同slot
的，總共會有兩處，一處狀態為 w*
（是死鎖）、一處是
g（代表鎖擁有）。
slot
相同，就代表他們是在同乙個資料物件上等待。尋找後的資料，如下截圖：
從上圖，可以看出如下資訊：
ø 在tabled=514
和tabspacesid=4
上等待（可以在
syscat.tables
檢視上根據資訊定位到表名稱
select tabname , tabschema from syscat.tables where tableid=514 and tbspaceid=4）
ø 佔據表鎖的transactionhandle id
為 28，是x
排他鎖
ø 等待表鎖的transactionhandle id為55
，是ns
（下一鍵共享鎖）
有了這兩個id
接著往下走。我們已經知道了誰在等待、誰在占有。
b) 檢視-transaction
，獲取transaction id
對應的agent id
對應值應有了，下面就需要根據這個
去找sql
執行的資訊，已經離目標不遠了哈。
c) 檢視-dynamic
資訊觀察如下列【c-anchid】、【c-stmtuid】、【l-anchid】、【l-stmtuid】
其中c-anchid是代表當前正在執行的sql
槽號，l-anchid是代表上次執行的sql
槽號。ok
，我們就需要通過這個槽號來找到對應的
sql。定位到如下模組：
然後根據【c-anchid】、【c-stmtuid】、【l-anchid】、【l-stmtuid】列值找到對應sql
（anchid->c- anchid,stmtuid-> c-stmtuid），如下：
自此，我們發現了導致死鎖的sql：
哪個sql
在等待鎖？
狀態為w*：
select count ( * )
from biz.wf_task a
inner join
biz.rei_form b
on a.receipt_no = b.rei_form_id
where a.task_status = ?
and a.handle_id = ?
and a.receipt_type = ?
and b.rei_form_no = ?
哪個sql
在占有鎖？
狀態為g：
update biz.rei_form
where rei_form_id = ?
整個過程截圖如下：
定位到sql
之後，我們就可以按照第三節中敘述的方法，該建索引就建立索引，
sql寫的不規範就調整
sql。
db2死鎖分析相關命令
檢視資料庫管理器級別快照資訊 db2 get monitor switches db2 update monitor switches using lock on statement on create event monitor mymonitor for deadlocks,statements...
如何查詢DB2資料
當我們在使用db2的過程中遇到問題的時候，該查詢那些文件才能既快又好的得到答案？我們不能總停留在遇到什麼問題都問度娘。如果是那樣的話，你的水平肯定只停留在初級水平，因為你在做和剛畢業的小鮮肉們同樣的事情。下面是我的一些經驗 1.db2 knowledge center 點評 ibm官方資料，海量資源...
db2鎖表後如何解鎖 DB2解除鎖表
背景 生產環境中，我幾乎沒有遇到過鎖表。多是在開發過程中遇到的，比如團隊開發中經常會遇到多個功能訪問同一張表的情況。如果有開發人員在這張表加了排它鎖，然後又忘記提交事務，那麼其他開發人員就要一直等待了。如開發人員在斷點除錯 debug 忘記點通過 資料庫客戶端中修改資料忘記commit 當我們在辦公...