日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間:8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
分析DB29.5中的鎖定超時原因

在 DB29.5中,分析鎖定超時的方法得到了極大改進,鎖定超時分析變得更加簡單。本文主要是探索這些全新的鎖定超時報告功能,并檢查收集的附加信息以確定發(fā)生鎖定超時的具體原因。

回顧DB2 9.1中的鎖定超時分析

使用db2pd工具和db2cos腳本進行鎖定超時分析的方法包含以下幾步:

1.使用一個特殊的DB2腳本 — 名為 db2cos — 在每次調(diào)用db2cos腳本時執(zhí)行一個db2pd調(diào)用。db2pd 調(diào)用收集與鎖定、事務(wù)、應(yīng)用程序、語句緩存相關(guān)的信息,并將信息存儲在一個文本文件中以供分析。

2.要在鎖定超時發(fā)生時自動執(zhí)行 db2cos 腳本(以及包含的 db2pd 命令,需要使用 db2pdcfg 命令注冊鎖定超時事件。

3.在鎖定超時事件中,DBA 可以檢查通過自動調(diào)用 db2cos 腳本生成的 db2pd 輸出。這使 DBA 能夠確定發(fā)生鎖定爭用的原因,從而設(shè)法在以后避免發(fā)生這類情形。

盡管其中介紹的方法提供了大量信息,使得鎖定超時分析比以前的 DB2 9 for Linux, Unix, and Windows 版本更加簡單,但它仍然存在一些不足:

◆使用此方法需要手動改寫 db2cos 腳本并通過調(diào)用 db2pdcfg 來注冊鎖定超時事件。兩個步驟都不復(fù)雜,但是對于新手來說可能有些困難。

◆解釋 db2pd 輸出以識別鎖定超時情形中涉及的應(yīng)用程序和 SQL 語句,這個任務(wù)并不容易,而且需要一些嘗試。

◆如果鎖定超時是由包含多個 SQL 命令的事務(wù)引起的,那么 db2pd 收集的信息可能還不足以確定導(dǎo)致鎖定的 SQL 語句。

DB2 9.5 中全新的鎖定超時報告功能

在 DB2 9.5 的鎖定超時報告功能中,引入了一個新特性,使得鎖定超時分析變得非常簡單。要激活鎖定超時報告,只需將 DB2 注冊變量 DB2_CAPTURE_LOCKTIMEOUT 設(shè)置為 ON,并重新啟動您的 DB2 實例:

清單 1. 激活 DB2 9.5 中的鎖定超時報告

 
 
 
  1. db2set DB2_CAPTURE_LOCKTIMEOUT=ON 
  2. db2stop 
  3. db2start 

是的,就是這么簡單。當 DB2_CAPTURE_LOCKTIMEOUT 設(shè)置為 ON 時,DB2 為每個鎖定超時事件自動創(chuàng)建一個報告文件。報告文件保存在 DIAGPATH 數(shù)據(jù)庫管理員配置(DBM CFG)參數(shù)指向的目錄中,包含的信息有:鎖定超時的日期和時間、存在問題的鎖定、鎖定請求程序和鎖定擁有者。

那么 DB2 9.5 中就不使用 db2cos 腳本了嗎?事實并非如此。將 db2cos 腳本和 db2pd 工具結(jié)合具有非常廣泛的用途。這意味著,這些工具組合仍然可用于捕捉與 SQL 代碼和 DB2 內(nèi)部返回代碼相關(guān)的任何 DB2 事件信息,而不僅僅是鎖定超時信息。

現(xiàn)在看看新的 DB2 9.5 注冊變量 DB2_CAPTURE_LOCKTIMEOUT 并查看一個使用 DB2 SAMPLE 數(shù)據(jù)庫的鎖定超時示例場景。如果 SAMPLE 數(shù)據(jù)庫不存在,可以調(diào)用下面的命令創(chuàng)建一個:

分析DB2 9.5中的鎖定超時原因

作者: kaduo,  出處:IT專家網(wǎng)論壇, 責任編輯: 陳子琪, 2009-05-20 07:00

在 DB29.5中,分析鎖定超時的方法得到了極大改進,鎖定超時分析變得更加簡單。本文探索這些全新的鎖定超時報告功能,并檢查收集的附加信息以確定發(fā)生鎖定超時的原因。

在 DB29.5中,分析鎖定超時的方法得到了極大改進,鎖定超時分析變得更加簡單。本文探索這些全新的鎖定超時報告功能,并檢查收集的附加信息以確定發(fā)生鎖定超時的原因。

回顧DB2 9.1中的鎖定超時分析

使用db2pd工具和db2cos腳本進行鎖定超時分析的方法包含以下幾步:

1.使用一個特殊的DB2腳本 — 名為 db2cos — 在每次調(diào)用db2cos腳本時執(zhí)行一個db2pd調(diào)用。db2pd 調(diào)用收集與鎖定、事務(wù)、應(yīng)用程序、語句緩存相關(guān)的信息,并將信息存儲在一個文本文件中以供分析。

2.要在鎖定超時發(fā)生時自動執(zhí)行 db2cos 腳本(以及包含的 db2pd 命令,需要使用 db2pdcfg 命令注冊鎖定超時事件。

3.在鎖定超時事件中,DBA 可以檢查通過自動調(diào)用 db2cos 腳本生成的 db2pd 輸出。這使 DBA 能夠確定發(fā)生鎖定爭用的原因,從而設(shè)法在以后避免發(fā)生這類情形。

盡管其中介紹的方法提供了大量信息,使得鎖定超時分析比以前的 DB2 9 for Linux, Unix, and Windows 版本更加簡單,但它仍然存在一些不足:

◆使用此方法需要手動改寫 db2cos 腳本并通過調(diào)用 db2pdcfg 來注冊鎖定超時事件。兩個步驟都不復(fù)雜,但是對于新手來說可能有些困難。

◆解釋 db2pd 輸出以識別鎖定超時情形中涉及的應(yīng)用程序和 SQL 語句,這個任務(wù)并不容易,而且需要一些嘗試。

◆如果鎖定超時是由包含多個 SQL 命令的事務(wù)引起的,那么 db2pd 收集的信息可能還不足以確定導(dǎo)致鎖定的 SQL 語句。

DB2 9.5 中全新的鎖定超時報告功能

在 DB2 9.5 的鎖定超時報告功能中,引入了一個新特性,使得鎖定超時分析變得非常簡單。要激活鎖定超時報告,只需將 DB2 注冊變量 DB2_CAPTURE_LOCKTIMEOUT 設(shè)置為 ON,并重新啟動您的 DB2 實例:

清單 1. 激活 DB2 9.5 中的鎖定超時報告

 
 
 
  1. db2set DB2_CAPTURE_LOCKTIMEOUT=ON 
  2. db2stop 
  3. db2start 

是的,就是這么簡單。當 DB2_CAPTURE_LOCKTIMEOUT 設(shè)置為 ON 時,DB2 為每個鎖定超時事件自動創(chuàng)建一個報告文件。報告文件保存在 DIAGPATH 數(shù)據(jù)庫管理員配置(DBM CFG)參數(shù)指向的目錄中,包含的信息有:鎖定超時的日期和時間、存在問題的鎖定、鎖定請求程序和鎖定擁有者。

那么 DB2 9.5 中就不使用 db2cos 腳本了嗎?事實并非如此。將 db2cos 腳本和 db2pd 工具結(jié)合具有非常廣泛的用途。這意味著,這些工具組合仍然可用于捕捉與 SQL 代碼和 DB2 內(nèi)部返回代碼相關(guān)的任何 DB2 事件信息,而不僅僅是鎖定超時信息。

現(xiàn)在看看新的 DB2 9.5 注冊變量 DB2_CAPTURE_LOCKTIMEOUT 并查看一個使用 DB2 SAMPLE 數(shù)據(jù)庫的鎖定超時示例場景。如果 SAMPLE 數(shù)據(jù)庫不存在,可以調(diào)用下面的命令創(chuàng)建一個:#p#

清單6. 鎖定超時報告

 
 
 
  1. LOCK TIMEOUT REPORT 
  2. Date: 03/01/2008 
  3. Time: 07:34:31 
  4. Instance: DB2 
  5. Database: SAMPLE 
  6. Database Partition: 0 
  7. Lock Information: 
  8. Lock Name: 02000600040040010000000052 
  9. Lock Type: Row 
  10. Lock Specifics: Tablespace ID=2, Table ID=6, Row ID=x0400400100000000 
  11. Lock Requestor: 
  12. System Auth ID: FECHNER 
  13. Application Handle: [0-38] 
  14. Application ID: *LOCAL.DB2.080103063343 
  15. Application Name: db2bp.exe 
  16. Requesting Agent ID: 5232 
  17. Coordinator Agent ID: 5232 
  18. Coordinator Partition: 0 
  19. Lock timeout Value: 10000 milliseconds 
  20. Lock mode requested: ..U 
  21. Application Status: (SQLM_UOWEXEC) 
  22. Current Operation: (SQLM_EXECUTE_IMMEDIATE) 
  23. Lock Escalation: No 
  24. Context of Lock Request: 
  25. Identification: UOW ID (1); Activity ID (1) 
  26. Activity Information: 
  27. Package Schema: (NULLID ) 
  28. Package Name: (SQLC2G13NULLID ) 
  29. Package Version: () 
  30. Section Entry Number: 203 
  31. SQL Type: Dynamic 
  32. Statement Type: DML, Insert/Update/Delete 
  33. Effective Isolation: Cursor Stability 
  34. Statement Unicode Flag: No 
  35. Statement: UPDATE EMPLOYEE SET BONUS = SALARY * 0.1 
  36. WHERE JOB = 'MANAGER' 
  37. Lock Owner (Representative): 
  38. System Auth ID: FECHNER 
  39. Application Handle: [0-33] 
  40. Application ID: *LOCAL.DB2.080103063332 
  41. Application Name: db2bp.exe 
  42. Requesting Agent ID: 5488 
  43. Coordinator Agent ID: 5488 
  44. Coordinator Partition: 0 
  45. Lock mode held: ..X 
  46. List of Active SQL Statements: Not available 
  47. List of Inactive SQL Statements from current UOW: Not available 

清單6. 鎖定超時報告

 
 
 
  1. LOCK TIMEOUT REPORT 
  2. Date: 03/01/2008 
  3. Time: 07:34:31 
  4. Instance: DB2 
  5. Database: SAMPLE 
  6. Database Partition: 0 
  7. Lock Information: 
  8. Lock Name: 02000600040040010000000052 
  9. Lock Type: Row 
  10. Lock Specifics: Tablespace ID=2, Table ID=6, Row ID=x0400400100000000 
  11. Lock Requestor: 
  12. System Auth ID: FECHNER 
  13. Application Handle: [0-38] 
  14. Application ID: *LOCAL.DB2.080103063343 
  15. Application Name: db2bp.exe 
  16. Requesting Agent ID: 5232 
  17. Coordinator Agent ID: 5232 
  18. Coordinator Partition: 0 
  19. Lock timeout Value: 10000 milliseconds 
  20. Lock mode requested: ..U 
  21. Application Status: (SQLM_UOWEXEC) 
  22. Current Operation: (SQLM_EXECUTE_IMMEDIATE) 
  23. Lock Escalation: No 
  24. Context of Lock Request: 
  25. Identification: UOW ID (1); Activity ID (1) 
  26. Activity Information: 
  27. Package Schema: (NULLID ) 
  28. Package Name: (SQLC2G13NULLID ) 
  29. Package Version: () 
  30. Section Entry Number: 203 
  31. SQL Type: Dynamic 
  32. Statement Type: DML, Insert/Update/Delete 
  33. Effective Isolation: Cursor Stability 
  34. Statement Unicode Flag: No 
  35. Statement: UPDATE EMPLOYEE SET BONUS = SALARY * 0.1 
  36. WHERE JOB = 'MANAGER' 
  37. Lock Owner (Representative): 
  38. System Auth ID: FECHNER 
  39. Application Handle: [0-33] 
  40. Application ID: *LOCAL.DB2.080103063332 
  41. Application Name: db2bp.exe 
  42. Requesting Agent ID: 5488 
  43. Coordinator Agent ID: 5488 
  44. Coordinator Partition: 0 
  45. Lock mode held: ..X 
  46. List of Active SQL Statements: Not available 
  47. List of Inactive SQL Statements from current UOW: Not available 

 清單9. 包含 SQL 語句歷史信息的鎖定超時報告

 
 
 
  1. LOCK TIMEOUT REPORT 
  2. Date: 03/01/2008 
  3. Time: 15:10:13 
  4. Instance: DB2 
  5. Database: SAMPLE 
  6. Database Partition: 0 
  7. Lock Information: 
  8. Lock Name: 02000600040040010000000052 
  9. Lock Type: Row 
  10. Lock Specifics: Tablespace ID=2, Table ID=6, Row ID=x0400400100000000 
  11. Lock Requestor: 
  12. System Auth ID: FECHNER 
  13. Application Handle: [0-202] 
  14. Application ID: *LOCAL.DB2.080103140934 
  15. Application Name: db2bp.exe 
  16. Requesting Agent ID: 2356 
  17. Coordinator Agent ID: 2356 
  18. Coordinator Partition: 0 
  19. Lock timeout Value: 10000 milliseconds 
  20. Lock mode requested: ..U 
  21. Application Status: (SQLM_UOWEXEC) 
  22. Current Operation: (SQLM_EXECUTE_IMMEDIATE) 
  23. Lock Escalation: No 
  24. Context of Lock Request: 
  25. Identification: UOW ID (1); Activity ID (1) 
  26. Activity Information: 
  27. Package Schema: (NULLID ) 
  28. Package Name: (SQLC2G13NULLID ) 
  29. Package Version: () 
  30. Section Entry Number: 203 
  31. SQL Type: Dynamic 
  32. Statement Type: DML, Insert/Update/Delete 
  33. Effective Isolation: Cursor Stability 
  34. Statement Unicode Flag: No 
  35. Statement: UPDATE EMPLOYEE SET BONUS = SALARY * 0.1 
  36. WHERE JOB = 'MANAGER' 
  37. Lock Owner (Representative): 
  38. System Auth ID: FECHNER 
  39. Application Handle: [0-188] 
  40. Application ID: *LOCAL.DB2.080103140511 
  41. Application Name: db2bp.exe 
  42. Requesting Agent ID: 5488 
  43. Coordinator Agent ID: 5488 
  44. Coordinator Partition: 0 
  45. Lock mode held: ..X 
  46. List of Active SQL Statements: Not available 
  47. List of Inactive SQL Statements from current UOW: 
  48. Entry: #1 
  49. Identification: UOW ID (6); Activity ID (2) 
  50. Package Schema: (NULLID ) 
  51. Package Name: (SQLC2G13) 
  52. Package Version: () 
  53. Section Entry Number: 201 
  54. SQL Type: Dynamic 
  55. Statement Type: DML, Select (blockable) 
  56. Effective Isolation: Cursor Stability 
  57. Statement Unicode Flag: No 
  58. Statement: SELECT LASTNAME, FIRSTNME, SALARY FROM EMPLOYEE 
  59. ORDER BY LASTNAME ASC 
  60. Entry: #2 
  61. Identification: UOW ID (6); Activity ID (1) 
  62. Package Schema: (NULLID ) 
  63. Package Name: (SQLC2G13) 
  64. Package Version: () 
  65. Section Entry Number: 203 
  66. SQL Type: Dynamic 
  67. Statement Type: DML, Insert/Update/Delete 
  68. Effective Isolation: Cursor Stability 
  69. Statement Unicode Flag: No 
  70. Statement: UPDATE EMPLOYEE SET SALARYSALARY = SALARY * 1.02 

這個鎖定超時報告的開始部分與前面看到的相同。但是,這次的 Lock Owner 部分包含額外的、有價值的信息。在標題 List of Inactive SQL Statements from current UOW 下邊,可以看到在發(fā)生鎖定超時之前鎖持有者的事務(wù)執(zhí)行的所有 SQL 語句。從這組 SQL 語句中,可以找到導(dǎo)致問題鎖定的語句。在這個場景中,使用 UPDATE 語句增加每個員工的工資。

注意,這個功能是對結(jié)合使用 db2cos 和 db2pd 方法的一個重大改進。使用 db2cos 與 db2pd 相結(jié)合的方法,只能看到鎖持有者的應(yīng)用程序執(zhí)行的***一條語句 — 在這個場景中是對 EMPLOYEE 表的查詢。但是由于查詢并沒有導(dǎo)致出現(xiàn)問題的獨占鎖,您仍然不知道是哪條語句導(dǎo)致了鎖定。使用新方法 — DB2_CAPTURE_LOCKTIMEOUT 和死鎖事件監(jiān)視器 — 您擁有在鎖擁有者的事務(wù)中執(zhí)行的所有 SQL 語句的歷史信息,這就可以將 UPDATE 確定為相關(guān)的語句。

使用鎖定超時報告的提示

帶有語句歷史功能的死鎖事件監(jiān)視器適用于所有應(yīng)用程序,會增加 DB2 數(shù)據(jù)庫管理程序?qū)ΡO(jiān)視器堆的大量使用。所以應(yīng)該謹慎使用。您應(yīng)該始終首先設(shè)置 DB2_CAPTURE_LOCKTIMEOUT=ON,然后只在必要的時候使用 DETAILS HISTORY 選項激活死鎖事件監(jiān)視器。

使用鎖定超時報告時,您可能會注意到,DIAGPATH 中的鎖定超時報告文件的數(shù)量在持續(xù)增加。DB2 不會刪除這些報告文件,所以 DBA 需要刪除它們或者將它們移動到不同的位置,以便在 DIAGPATH 的文件系統(tǒng)上始終有足夠的空間。

即使擁有了鎖定超時報告功能,也不是總能夠輕松確定出導(dǎo)致鎖定超時的原因。例如,如果鎖定超時由靜態(tài) SQL 或 DB2 內(nèi)部鎖定引起時,就沒有那么容易確定原因。DB2 9.5 文檔的 Lock timeout reporting 一章提供了這些局限性的一個簡短列表(參見下面的 參考資料)。但是,DB2 9.5 中的鎖定超時報告絕對是一個許多 DBA 期待已久的功能,而且將大大簡化對鎖定超時的分析。
以上的相關(guān)內(nèi)容就是對分析DB2 9.5中的鎖定超時原因的介紹,望你能有所收獲。


標題名稱:分析DB29.5中的鎖定超時原因
標題URL:http://www.dlmjj.cn/article/djisjpg.html