分析DB2 9.5中的鎖定超時(shí)原因
在 DB29.5中，分析鎖定超時(shí)的方法得到了極大改進(jìn)，鎖定超時(shí)分析變得更加簡單。本文主要是探索這些全新的鎖定超時(shí)報(bào)告功能，并檢查收集的附加信息以確定發(fā)生鎖定超時(shí)的具體原因。
回顧DB2 9.1中的鎖定超時(shí)分析
使用db2pd工具和db2cos腳本進(jìn)行鎖定超時(shí)分析的方法包含以下幾步：
1.使用一個特殊的DB2腳本 — 名為 db2cos — 在每次調(diào)用db2cos腳本時(shí)執(zhí)行一個db2pd調(diào)用。db2pd 調(diào)用收集與鎖定、事務(wù)、應(yīng)用程序、語句緩存相關(guān)的信息，并將信息存儲在一個文本文件中以供分析。
2.要在鎖定超時(shí)發(fā)生時(shí)自動執(zhí)行 db2cos 腳本(以及包含的 db2pd 命令，需要使用 db2pdcfg 命令注冊鎖定超時(shí)事件。
3.在鎖定超時(shí)事件中，DBA 可以檢查通過自動調(diào)用 db2cos 腳本生成的 db2pd 輸出。這使 DBA 能夠確定發(fā)生鎖定爭用的原因，從而設(shè)法在以后避免發(fā)生這類情形。
盡管其中介紹的方法提供了大量信息，使得鎖定超時(shí)分析比以前的 DB2 9 for Linux, Unix, and Windows 版本更加簡單，但它仍然存在一些不足：
◆使用此方法需要手動改寫 db2cos 腳本并通過調(diào)用 db2pdcfg 來注冊鎖定超時(shí)事件。兩個步驟都不復(fù)雜，但是對于新手來說可能有些困難。
◆解釋 db2pd 輸出以識別鎖定超時(shí)情形中涉及的應(yīng)用程序和 SQL 語句，這個任務(wù)并不容易，而且需要一些嘗試。
◆如果鎖定超時(shí)是由包含多個 SQL 命令的事務(wù)引起的，那么 db2pd 收集的信息可能還不足以確定導(dǎo)致鎖定的 SQL 語句。
DB2 9.5 中全新的鎖定超時(shí)報(bào)告功能
在 DB2 9.5 的鎖定超時(shí)報(bào)告功能中，引入了一個新特性，使得鎖定超時(shí)分析變得非常簡單。要激活鎖定超時(shí)報(bào)告，只需將 DB2 注冊變量 DB2_CAPTURE_LOCKTIMEOUT 設(shè)置為 ON，并重新啟動您的 DB2 實(shí)例：
清單 1. 激活 DB2 9.5 中的鎖定超時(shí)報(bào)告
- db2set DB2_CAPTURE_LOCKTIMEOUT=ON
- db2stop
- db2start
是的，就是這么簡單。當(dāng) DB2_CAPTURE_LOCKTIMEOUT 設(shè)置為 ON 時(shí)，DB2 為每個鎖定超時(shí)事件自動創(chuàng)建一個報(bào)告文件。報(bào)告文件保存在 DIAGPATH 數(shù)據(jù)庫管理員配置(DBM CFG)參數(shù)指向的目錄中，包含的信息有：鎖定超時(shí)的日期和時(shí)間、存在問題的鎖定、鎖定請求程序和鎖定擁有者。
那么 DB2 9.5 中就不使用 db2cos 腳本了嗎?事實(shí)并非如此。將 db2cos 腳本和 db2pd 工具結(jié)合具有非常廣泛的用途。這意味著，這些工具組合仍然可用于捕捉與 SQL 代碼和 DB2 內(nèi)部返回代碼相關(guān)的任何 DB2 事件信息，而不僅僅是鎖定超時(shí)信息。
現(xiàn)在看看新的 DB2 9.5 注冊變量 DB2_CAPTURE_LOCKTIMEOUT 并查看一個使用 DB2 SAMPLE 數(shù)據(jù)庫的鎖定超時(shí)示例場景。如果 SAMPLE 數(shù)據(jù)庫不存在，可以調(diào)用下面的命令創(chuàng)建一個：
分析DB2 9.5中的鎖定超時(shí)原因
作者: kaduo, 出處:IT專家網(wǎng)論壇, 責(zé)任編輯: 陳子琪, 2009-05-20 07:00
在 DB29.5中，分析鎖定超時(shí)的方法得到了極大改進(jìn)，鎖定超時(shí)分析變得更加簡單。本文探索這些全新的鎖定超時(shí)報(bào)告功能，并檢查收集的附加信息以確定發(fā)生鎖定超時(shí)的原因。
在 DB29.5中，分析鎖定超時(shí)的方法得到了極大改進(jìn)，鎖定超時(shí)分析變得更加簡單。本文探索這些全新的鎖定超時(shí)報(bào)告功能，并檢查收集的附加信息以確定發(fā)生鎖定超時(shí)的原因。
回顧DB2 9.1中的鎖定超時(shí)分析
使用db2pd工具和db2cos腳本進(jìn)行鎖定超時(shí)分析的方法包含以下幾步：
1.使用一個特殊的DB2腳本 — 名為 db2cos — 在每次調(diào)用db2cos腳本時(shí)執(zhí)行一個db2pd調(diào)用。db2pd 調(diào)用收集與鎖定、事務(wù)、應(yīng)用程序、語句緩存相關(guān)的信息，并將信息存儲在一個文本文件中以供分析。
2.要在鎖定超時(shí)發(fā)生時(shí)自動執(zhí)行 db2cos 腳本(以及包含的 db2pd 命令，需要使用 db2pdcfg 命令注冊鎖定超時(shí)事件。
3.在鎖定超時(shí)事件中，DBA 可以檢查通過自動調(diào)用 db2cos 腳本生成的 db2pd 輸出。這使 DBA 能夠確定發(fā)生鎖定爭用的原因，從而設(shè)法在以后避免發(fā)生這類情形。
盡管其中介紹的方法提供了大量信息，使得鎖定超時(shí)分析比以前的 DB2 9 for Linux, Unix, and Windows 版本更加簡單，但它仍然存在一些不足：
◆使用此方法需要手動改寫 db2cos 腳本并通過調(diào)用 db2pdcfg 來注冊鎖定超時(shí)事件。兩個步驟都不復(fù)雜，但是對于新手來說可能有些困難。
◆解釋 db2pd 輸出以識別鎖定超時(shí)情形中涉及的應(yīng)用程序和 SQL 語句，這個任務(wù)并不容易，而且需要一些嘗試。
◆如果鎖定超時(shí)是由包含多個 SQL 命令的事務(wù)引起的，那么 db2pd 收集的信息可能還不足以確定導(dǎo)致鎖定的 SQL 語句。
DB2 9.5 中全新的鎖定超時(shí)報(bào)告功能
在 DB2 9.5 的鎖定超時(shí)報(bào)告功能中，引入了一個新特性，使得鎖定超時(shí)分析變得非常簡單。要激活鎖定超時(shí)報(bào)告，只需將 DB2 注冊變量 DB2_CAPTURE_LOCKTIMEOUT 設(shè)置為 ON，并重新啟動您的 DB2 實(shí)例：
清單 1. 激活 DB2 9.5 中的鎖定超時(shí)報(bào)告
- db2set DB2_CAPTURE_LOCKTIMEOUT=ON
- db2stop
- db2start
是的，就是這么簡單。當(dāng) DB2_CAPTURE_LOCKTIMEOUT 設(shè)置為 ON 時(shí)，DB2 為每個鎖定超時(shí)事件自動創(chuàng)建一個報(bào)告文件。報(bào)告文件保存在 DIAGPATH 數(shù)據(jù)庫管理員配置(DBM CFG)參數(shù)指向的目錄中，包含的信息有：鎖定超時(shí)的日期和時(shí)間、存在問題的鎖定、鎖定請求程序和鎖定擁有者。
那么 DB2 9.5 中就不使用 db2cos 腳本了嗎?事實(shí)并非如此。將 db2cos 腳本和 db2pd 工具結(jié)合具有非常廣泛的用途。這意味著，這些工具組合仍然可用于捕捉與 SQL 代碼和 DB2 內(nèi)部返回代碼相關(guān)的任何 DB2 事件信息，而不僅僅是鎖定超時(shí)信息。
現(xiàn)在看看新的 DB2 9.5 注冊變量 DB2_CAPTURE_LOCKTIMEOUT 并查看一個使用 DB2 SAMPLE 數(shù)據(jù)庫的鎖定超時(shí)示例場景。如果 SAMPLE 數(shù)據(jù)庫不存在，可以調(diào)用下面的命令創(chuàng)建一個：#p#
清單6. 鎖定超時(shí)報(bào)告
- LOCK TIMEOUT REPORT
- Date: 03/01/2008
- Time: 07:34:31
- Instance: DB2
- Database: SAMPLE
- Database Partition: 0
- Lock Information:
- Lock Name: 02000600040040010000000052
- Lock Type: Row
- Lock Specifics: Tablespace ID=2, Table ID=6, Row ID=x0400400100000000
- Lock Requestor:
- System Auth ID: FECHNER
- Application Handle: [0-38]
- Application ID: *LOCAL.DB2.080103063343
- Application Name: db2bp.exe
- Requesting Agent ID: 5232
- Coordinator Agent ID: 5232
- Coordinator Partition: 0
- Lock timeout Value: 10000 milliseconds
- Lock mode requested: ..U
- Application Status: (SQLM_UOWEXEC)
- Current Operation: (SQLM_EXECUTE_IMMEDIATE)
- Lock Escalation: No
- Context of Lock Request:
- Identification: UOW ID (1); Activity ID (1)
- Activity Information:
- Package Schema: (NULLID )
- Package Name: (SQLC2G13NULLID )
- Package Version: ()
- Section Entry Number: 203
- SQL Type: Dynamic
- Statement Type: DML, Insert/Update/Delete
- Effective Isolation: Cursor Stability
- Statement Unicode Flag: No
- Statement: UPDATE EMPLOYEE SET BONUS = SALARY * 0.1
- WHERE JOB = 'MANAGER'
- Lock Owner (Representative):
- System Auth ID: FECHNER
- Application Handle: [0-33]
- Application ID: *LOCAL.DB2.080103063332
- Application Name: db2bp.exe
- Requesting Agent ID: 5488
- Coordinator Agent ID: 5488
- Coordinator Partition: 0
- Lock mode held: ..X
- List of Active SQL Statements: Not available
- List of Inactive SQL Statements from current UOW: Not available
清單6. 鎖定超時(shí)報(bào)告
- LOCK TIMEOUT REPORT
- Date: 03/01/2008
- Time: 07:34:31
- Instance: DB2
- Database: SAMPLE
- Database Partition: 0
- Lock Information:
- Lock Name: 02000600040040010000000052
- Lock Type: Row
- Lock Specifics: Tablespace ID=2, Table ID=6, Row ID=x0400400100000000
- Lock Requestor:
- System Auth ID: FECHNER
- Application Handle: [0-38]
- Application ID: *LOCAL.DB2.080103063343
- Application Name: db2bp.exe
- Requesting Agent ID: 5232
- Coordinator Agent ID: 5232
- Coordinator Partition: 0
- Lock timeout Value: 10000 milliseconds
- Lock mode requested: ..U
- Application Status: (SQLM_UOWEXEC)
- Current Operation: (SQLM_EXECUTE_IMMEDIATE)
- Lock Escalation: No
- Context of Lock Request:
- Identification: UOW ID (1); Activity ID (1)
- Activity Information:
- Package Schema: (NULLID )
- Package Name: (SQLC2G13NULLID )
- Package Version: ()
- Section Entry Number: 203
- SQL Type: Dynamic
- Statement Type: DML, Insert/Update/Delete
- Effective Isolation: Cursor Stability
- Statement Unicode Flag: No
- Statement: UPDATE EMPLOYEE SET BONUS = SALARY * 0.1
- WHERE JOB = 'MANAGER'
- Lock Owner (Representative):
- System Auth ID: FECHNER
- Application Handle: [0-33]
- Application ID: *LOCAL.DB2.080103063332
- Application Name: db2bp.exe
- Requesting Agent ID: 5488
- Coordinator Agent ID: 5488
- Coordinator Partition: 0
- Lock mode held: ..X
- List of Active SQL Statements: Not available
- List of Inactive SQL Statements from current UOW: Not available
清單9. 包含 SQL 語句歷史信息的鎖定超時(shí)報(bào)告
- LOCK TIMEOUT REPORT
- Date: 03/01/2008
- Time: 15:10:13
- Instance: DB2
- Database: SAMPLE
- Database Partition: 0
- Lock Information:
- Lock Name: 02000600040040010000000052
- Lock Type: Row
- Lock Specifics: Tablespace ID=2, Table ID=6, Row ID=x0400400100000000
- Lock Requestor:
- System Auth ID: FECHNER
- Application Handle: [0-202]
- Application ID: *LOCAL.DB2.080103140934
- Application Name: db2bp.exe
- Requesting Agent ID: 2356
- Coordinator Agent ID: 2356
- Coordinator Partition: 0
- Lock timeout Value: 10000 milliseconds
- Lock mode requested: ..U
- Application Status: (SQLM_UOWEXEC)
- Current Operation: (SQLM_EXECUTE_IMMEDIATE)
- Lock Escalation: No
- Context of Lock Request:
- Identification: UOW ID (1); Activity ID (1)
- Activity Information:
- Package Schema: (NULLID )
- Package Name: (SQLC2G13NULLID )
- Package Version: ()
- Section Entry Number: 203
- SQL Type: Dynamic
- Statement Type: DML, Insert/Update/Delete
- Effective Isolation: Cursor Stability
- Statement Unicode Flag: No
- Statement: UPDATE EMPLOYEE SET BONUS = SALARY * 0.1
- WHERE JOB = 'MANAGER'
- Lock Owner (Representative):
- System Auth ID: FECHNER
- Application Handle: [0-188]
- Application ID: *LOCAL.DB2.080103140511
- Application Name: db2bp.exe
- Requesting Agent ID: 5488
- Coordinator Agent ID: 5488
- Coordinator Partition: 0
- Lock mode held: ..X
- List of Active SQL Statements: Not available
- List of Inactive SQL Statements from current UOW:
- Entry: #1
- Identification: UOW ID (6); Activity ID (2)
- Package Schema: (NULLID )
- Package Name: (SQLC2G13)
- Package Version: ()
- Section Entry Number: 201
- SQL Type: Dynamic
- Statement Type: DML, Select (blockable)
- Effective Isolation: Cursor Stability
- Statement Unicode Flag: No
- Statement: SELECT LASTNAME, FIRSTNME, SALARY FROM EMPLOYEE
- ORDER BY LASTNAME ASC
- Entry: #2
- Identification: UOW ID (6); Activity ID (1)
- Package Schema: (NULLID )
- Package Name: (SQLC2G13)
- Package Version: ()
- Section Entry Number: 203
- SQL Type: Dynamic
- Statement Type: DML, Insert/Update/Delete
- Effective Isolation: Cursor Stability
- Statement Unicode Flag: No
- Statement: UPDATE EMPLOYEE SET SALARYSALARY = SALARY * 1.02
這個鎖定超時(shí)報(bào)告的開始部分與前面看到的相同。但是，這次的 Lock Owner 部分包含額外的、有價(jià)值的信息。在標(biāo)題 List of Inactive SQL Statements from current UOW 下邊，可以看到在發(fā)生鎖定超時(shí)之前鎖持有者的事務(wù)執(zhí)行的所有 SQL 語句。從這組 SQL 語句中，可以找到導(dǎo)致問題鎖定的語句。在這個場景中，使用 UPDATE 語句增加每個員工的工資。
注意，這個功能是對結(jié)合使用 db2cos 和 db2pd 方法的一個重大改進(jìn)。使用 db2cos 與 db2pd 相結(jié)合的方法，只能看到鎖持有者的應(yīng)用程序執(zhí)行的***一條語句 — 在這個場景中是對 EMPLOYEE 表的查詢。但是由于查詢并沒有導(dǎo)致出現(xiàn)問題的獨(dú)占鎖，您仍然不知道是哪條語句導(dǎo)致了鎖定。使用新方法 — DB2_CAPTURE_LOCKTIMEOUT 和死鎖事件監(jiān)視器 — 您擁有在鎖擁有者的事務(wù)中執(zhí)行的所有 SQL 語句的歷史信息，這就可以將 UPDATE 確定為相關(guān)的語句。
使用鎖定超時(shí)報(bào)告的提示
帶有語句歷史功能的死鎖事件監(jiān)視器適用于所有應(yīng)用程序，會增加 DB2 數(shù)據(jù)庫管理程序?qū)ΡO(jiān)視器堆的大量使用。所以應(yīng)該謹(jǐn)慎使用。您應(yīng)該始終首先設(shè)置 DB2_CAPTURE_LOCKTIMEOUT=ON，然后只在必要的時(shí)候使用 DETAILS HISTORY 選項(xiàng)激活死鎖事件監(jiān)視器。
使用鎖定超時(shí)報(bào)告時(shí)，您可能會注意到，DIAGPATH 中的鎖定超時(shí)報(bào)告文件的數(shù)量在持續(xù)增加。DB2 不會刪除這些報(bào)告文件，所以 DBA 需要刪除它們或者將它們移動到不同的位置，以便在 DIAGPATH 的文件系統(tǒng)上始終有足夠的空間。
即使擁有了鎖定超時(shí)報(bào)告功能，也不是總能夠輕松確定出導(dǎo)致鎖定超時(shí)的原因。例如，如果鎖定超時(shí)由靜態(tài) SQL 或 DB2 內(nèi)部鎖定引起時(shí)，就沒有那么容易確定原因。DB2 9.5 文檔的 Lock timeout reporting 一章提供了這些局限性的一個簡短列表(參見下面的 參考資料)。但是，DB2 9.5 中的鎖定超時(shí)報(bào)告絕對是一個許多 DBA 期待已久的功能，而且將大大簡化對鎖定超時(shí)的分析。
以上的相關(guān)內(nèi)容就是對分析DB2 9.5中的鎖定超時(shí)原因的介紹，望你能有所收獲。
【編輯推薦】
