DB2 deadlock若是不常發生
只是突發狀況 我建議可以使用snapshot的方式
抓取當時資料庫的狀況資訊
並可由此資料 知道是哪一個應用程式造成的
執行以下指令將monitor打開(當指令在執行的瞬間，CPU會衝高，執行完後即會下降)
db2 update monitor switches using bufferpool on lock on sort on statement on table on uow on
然後，若要抓約30秒時間的snapshot資料，則可以稍等30秒鐘
執行下面的指令：
db2 get snapshot for all applications > shapshot.log
在shapshot中可以看到目前是否的dead lock
並且可以看出是否有鎖定等待(lock waiting)
若搜尋的結果發現，鎖定等待的應用程式非常多，則很有可能發生了dead lock的狀態
若要找出根源，可由每個statement共同等待的應用程式控點(Application ID)慢慢往上找
會找到開始鎖定的應用程式，此時僅需下force application(xxx)將該應用程式強制自DB2切斷連線即可
若時常發生deadlock，且deadlock時已經DB2連線佔滿
那麼我們需要的則是經常性的監控整個DB的狀態
下面這個步驟僅針對table的deadlock事件做監控，
所以並不會耗費太多資源，但一但打開監控，則會不斷會寫evt檔，
所以請自行考量系統的檔案空間，再決定是否要一直開著
首先 我們需要先連結到要監控的資料庫
db2 connect to DBNAME
執行以下的指令，針對table建立一個叫做dlmon的monitor事件，
該監控事件是用來監控table deadlock，並且會將監控的歷程寫入/dlmon這個目錄
(請先建立好dlmon這個目錄)
下面是在AIX環境下的寫法：
db2 "create event monitor dlmon for tables, deadlocks with details write to file '/dlmon'"
打開監控的指令：
db2 "set event monitor dlmon state 1"
關閉監控的指令：
db2 "set event monitor dlmon state 0"
在我們收集完我們要的監控資料後，再來就是解讀我們得到的evt檔案
請執行下面的指令，將evt檔案轉換成我們可以閱讀的文字檔
db2evmon -path /dlmon /logs/dlmon.log
依我本身執行的經驗，當我們在執行轉檔時，會耗費CPU資源約20%左右
10個evt檔案，約需轉換60秒
解開後的檔案，我們會很清楚的可以找到發生deadlock的application、他所執行的statement及鎖定的table
找到了deadlock發生的點後，接下來，就是跟各AP的負責人討論及view code囉^^
留言列表
