本文闡述了開(kāi)發(fā)人員和測(cè)試人員如何確定 DB2 for z/OS 環(huán)境下復(fù)雜 Web 應(yīng)用程序中的死鎖原因。簡(jiǎn)介在任何數(shù)據(jù)庫(kù)環(huán)境中，死鎖檢測(cè)對(duì)于應(yīng)用程序并發(fā)性都是很重要的。就像其他應(yīng)用程序一樣，在復(fù)雜 Web 環(huán)境中也需要能夠確定任何死鎖的起因。本文解釋了如何配置 DB2 for os/390 的死鎖跟蹤設(shè)置，以啟用死鎖分析。先闡述了如何指定相關(guān)的 DB2 for z/OS 跟蹤以獲取足夠信息，然后說(shuō)明如何分析這些跟蹤報(bào)告，并指出引起 DB2 for z/OS 環(huán)境中運(yùn)行的復(fù)雜 Web 應(yīng)用程序出現(xiàn)死鎖的不良 SQL 語(yǔ)句。本文假定讀者熟悉基本的 z/OS 操作。使用 DB2 Performance Monitor 來(lái)配置跟蹤Locking 跟蹤若要啟用 Locking 跟蹤，首先打開(kāi) IBM DB2 Performance Monitor 應(yīng)用程序。然后執(zhí)行下面步驟：配置 Collect Task A 以收集死鎖跟蹤。設(shè)置 Trigger by 4=Immediate Start 以立即激活任務(wù)。選擇 Locking, Data Type, IFICD, Requesting Location, Plan name and Authid，然后按 Enter。圖 1. 配置 Collect Task A選擇數(shù)據(jù)類(lèi)型 Lockout，然后按 Enter。在 IFCID Selection 面板中，選擇下面的 IFICD，然后按 Enter。105DBID/OBID for database and tablespace translation　107Data set open/close information172Deadlock在 Trace Qualification 面板中，填入 DB 用戶名（在本例中為 TUSER03）和 DB 模式（在本例中為 TGUSER03），然后按 Enter。圖 2. Trace qualification 面板在 Trigger Immediately 面板中，填入 DB2 跟蹤數(shù)據(jù)的輸出數(shù)據(jù)集（例如，TGUSER03.DB2PM.TRACE01）。設(shè)置 Disposition 為 Overwrite。注重：可以使用其他方法來(lái)配置 DB2 跟蹤停止觸發(fā)器（例如，經(jīng)過(guò)一段時(shí)間后）。圖 3. Trigger immediately 面板按 Enter，完成 Locking 跟蹤配置。假如 Web 應(yīng)用程序運(yùn)行期間有死鎖，則激活 Collect Task A 來(lái)收集死鎖信息。SQL Activity 跟蹤按照下面步驟來(lái)配置 SQL Activity 跟蹤：配置 Collect Task B 以收集 SQL Activity 跟蹤。設(shè)置 Trigger by 4=Immediate Start 來(lái)立即激活任務(wù)。選擇 SQL Activity, Data Type, IFCID, Requesting Location, Plan name and Authid，然后按 Enter。選擇全部收集數(shù)據(jù)類(lèi)型，然后按 Enter。在 IFCID Selection 面板中，選擇下面的 IFCID，然后按 Enter：16Start of the first insert20Lock summary　53Describe, SQL commit/rollback or error before SQL analyzed58End of SQL statement execution59Start of FETCH　60start of SELECT61Start of INSERT, UPDATE or DELETE63SQL statement to be parsed　64start of PREPARE65start of OPEN CURSOR for static or dynamic SQL　66Start of CLOSE CURSOR for static or dynamic SQL　68Start of ROLLBACK69End of ROLLBACK　70Start of COMMIT phase 2　71End of COMMIT phase 288start of synchronous request (commit phase 1)89End of synchronous request (commit phase 1)　105DBID/OBID for database and tablespace translation在 Trace Qualification 面板中，填入 DB 用戶名（例如，TUSER03）和 DB 模式（例如，TGUSER03），然后按 Enter。在 Trigger Immediately 面板中，填入 DB2 跟蹤數(shù)據(jù)的輸出數(shù)據(jù)集（例如，TGUSER03.DB2PM.TRACE02）。設(shè)置 Disposition 為 Overwrite。注重：可以使用其他方法來(lái)配置 DB2 跟蹤停止觸發(fā)器（例如，經(jīng)過(guò)一段時(shí)間后）。按 Enter 完成 SQL Activity 配置。在 Web 應(yīng)用程序運(yùn)行期間，激活 Collect Task B 來(lái)收集 SQL 語(yǔ)句。分析跟蹤報(bào)告以確定不良 SQL 語(yǔ)句Web 應(yīng)用程序中 DB2 鎖的原理通常 Web 應(yīng)用程序有頁(yè)鎖和行鎖。根據(jù)創(chuàng)建數(shù)據(jù)庫(kù)所使用的數(shù)據(jù)定義語(yǔ)言 (DDL) 模式文件，可以確定正在使用的鎖類(lèi)型。行鎖有三種模式：S(Share)、U(Update) 和 X(Exclusive)。要盡量避免的鎖影響是掛起、超時(shí)和死鎖。當(dāng)兩個(gè)或兩個(gè)以上應(yīng)用程序進(jìn)程均持有對(duì)資源（該資源是其他進(jìn)程所需，且沒(méi)有該資源時(shí)進(jìn)程無(wú)法繼續(xù)進(jìn)行）的鎖時(shí)，會(huì)發(fā)生死鎖。下面是關(guān)于發(fā)生死鎖情況的具體解釋?zhuān)篔obOne 和 JobTwo 是兩個(gè)事務(wù)。JobOne 訪問(wèn)表 M，并持有頁(yè) B 的 X (exclusive) 鎖，包含記錄 000300。JobTwo 訪問(wèn)表 N，并持有頁(yè) A 的 X (exclusive) 鎖，包含記錄 000010。JobOne 請(qǐng)求表 N 頁(yè) A 的鎖，同時(shí)仍持有表 M 頁(yè) B 的鎖。因?yàn)?JobTwo 持有頁(yè) A 的 X 鎖，所以作業(yè)被掛起。JobTwo 請(qǐng)求表 M 頁(yè) B 的鎖，同時(shí)仍持有表 N 頁(yè) A 的鎖。因?yàn)?JobOne 持有頁(yè) B 的 X 鎖，所以作業(yè)被掛起。這種情況就是死鎖。為了改善應(yīng)用程序的并發(fā)性，您需要找到引起死鎖的 SQL 語(yǔ)句。然后，優(yōu)化 SQL 語(yǔ)句以消除死鎖。根據(jù)死鎖報(bào)告來(lái)分析鎖信息作為例子，我們假定當(dāng)多個(gè)顧客同時(shí)登錄并注冊(cè)一個(gè)商店時(shí)發(fā)生死鎖。您已經(jīng)得到死鎖跟蹤報(bào)告和 SQL 語(yǔ)句報(bào)告。首先，您應(yīng)檢查死鎖跟蹤報(bào)告（在本文中為 TGUSER03.DB2PM.LOCKS）。下面是跟蹤報(bào)告中一些要害參數(shù)的說(shuō)明，有助于理解該進(jìn)程：圖 4. 跟蹤參數(shù)分析一下表 USERS（圖 5 和圖 6）上的第一個(gè)死鎖。在圖 5 中，可以看到死鎖涉及到兩個(gè)資源。分別是 row X'2B'、page X'00004E'、page USERS、DB SW03DB1 和 row X'2B'、page X'00004C'、table USERS、DB SW03DB1。WAITERS =2 表明死鎖中有兩個(gè)等待者（0CC544053119 和 0E26A4053107）。死鎖發(fā)生在 12/05/05 06:30:09.40。從圖 6 可以看到資源持有者和等待者與圖 5 中的相反。等待者（實(shí)際上是圖 5 中的持有者）正在請(qǐng)求持有者（實(shí)際上是圖 5 中的等待者）所持有的資源。按照死鎖的定義，在這種情況下會(huì)發(fā)生死鎖。現(xiàn)在，利用圖 5 和圖 6 來(lái)總結(jié)一下鎖關(guān)系。從圖 5 中可以看到 LUW 0CC544053119 所持有的鎖是 row X'2B'、page X'00004E'、table USERS、DB SW03DB1 上的行鎖，且保持在 X 狀態(tài)。等待者 LUW 實(shí)例 0E26A4053107 正在請(qǐng)求同一個(gè)資源上的 S 鎖模式。而在圖 6 中，LUW 0E26A4053107 所持有的鎖是 row X'2B'、page X'00004C'、table USERS、DB SW03DB1 上的行鎖，且保持在 X 狀態(tài)。等待者 LUW 實(shí)例 0CC544053119 正在請(qǐng)求同一個(gè)資源上的 S 鎖模式。因此發(fā)生死鎖。最后，請(qǐng)注重圖 5 中的 BLOCKER is HOLDER --*VICTIM*，該線程 ("victim") 的作用是回滾以進(jìn)行其他線程。圖 5. Locking 跟蹤 —— 死鎖報(bào)告圖 6. Locking 跟蹤 —— 死鎖報(bào)告表 1 總結(jié)死鎖分析：表 1. 死鎖分析LUW 實(shí)例持有的資源（X 鎖）請(qǐng)求的資源（S 鎖）死鎖時(shí)間表0CC544053119SW03DB1.USERS.X'00004E'.X'2B'SW03DB1.USERS.X'00004C'.X'2B'06:30:09.410449910E26A4053107SW03DB1.USERS.X'00004C'.X'2B'SW03DB1.USERS.X'00004E'.X'2B'06:30:09.41044991根據(jù) SQL 活動(dòng)報(bào)告來(lái)分析 SQL 信息打印 SQL ACTIVITY 跟蹤（在本文中為 TGUSER03.DB2PM.SQL），使用死鎖所涉及的 LUW INSTANCE 數(shù)量(0CC544053119 和 0E26A4053107）進(jìn)行過(guò)濾。可以發(fā)現(xiàn)最后一次 commit 操作應(yīng)正好在死鎖出現(xiàn) (06:30:09.41044991) 前完成。接下來(lái)，搜索僅在完成最后一次 commit 操作后執(zhí)行的 SQL 語(yǔ)句。COMMIT processing in SQL ACTIVITY trace for INSTANCE 0CC544053119COMMIT RECEIVED　06:28:50.72COMMIT RECEIVED　06:28:50.85COMMIT RECEIVED　06:28:50.97COMMIT RECEIVED　06:28:51.04the latest commit before the deadlock occurred.COMMIT RECEIVED　06:30:09.61COMMIT RECEIVED　06:30:09.64COMMIT RECEIVED　06:30:09.73COMMIT RECEIVED　06:30:09.77COMMIT RECEIVED　06:30:09.80因此，應(yīng)該研究那些訪問(wèn)過(guò) SW03DB1.USERS 且在 06:28:51.04 到 06:30:09.41044991 之間執(zhí)行的 SQL 語(yǔ)句。如圖 7 所示。圖 7. SQL 報(bào)告根據(jù)鎖狀態(tài) X 和 S，對(duì)于資源 SW03DB1.USERS，在 SELECT 語(yǔ)句之前應(yīng)是 INSERT 語(yǔ)句。按照同樣的方法，對(duì)于 INSTANCE 0E26A4053107，可以找到在出現(xiàn)死鎖前進(jìn)行最后一次 commit 的時(shí)間.COMMIT processing in SQL ACTIVITY trace for INSTANCE 0E26A4053107COMMIT RECEIVED 06:28:50.65the latest commit before the deadlock occurred.COMMIT RECEIVED 06:30:49.67然后，研究那些訪問(wèn)過(guò) SW03DB1.USERS 且在 06:28:50.65 到 06:30:09.41044991 之間執(zhí)行的 SQL 語(yǔ)句。如圖 8 所示。圖 8. SQL 報(bào)告從圖 5 和圖 6 中可以看到兩個(gè)實(shí)例 0CC544053119 和 0E26A4053107 正嘗試提交 INSTER INTO USERS 和 SELECT FROM USERS SQL 語(yǔ)句。由于 INSERT 和 SELECT 語(yǔ)句之間沒(méi)有 COMMIT，死鎖可能是由表掃描引起的。因此運(yùn)行并發(fā)線程時(shí)，出現(xiàn)了死鎖。結(jié)束語(yǔ)本文闡述了如何使用 DB2 Performance Monitor 工具來(lái)收集死鎖和 SQL Activity 跟蹤。另外，給出了一個(gè)例子，演示如何通過(guò)分析跟蹤找到一個(gè)死鎖情況所涉及的 SQL 語(yǔ)句。使用該方法，開(kāi)發(fā)人員和測(cè)試人員都可以發(fā)現(xiàn)不良 SQL 語(yǔ)句，并完成并發(fā)性能問(wèn)題解決方案的第一步。