Prayer

2003 年 1 月 01 日

在只讀情況下進行 COMMIT 時釋放鎖并釋放應(yīng)用程序。

簡介

許多正在使用 DB2 for z/OS 或 DB2 for OS/390 的人都認為對只讀訪問使用 COMMIT 是沒有必要的。這些人認為，因為他們沒有更改任何數(shù)據(jù)，所以沒有必要使用 COMMIT 。但是 COMMIT 不僅應(yīng)用更改, 它還釋放鎖和聲明（claim）, 所以 COMMIT 會影響應(yīng)用程序可用性。

我要解釋在將 COMMIT 引入到進行只讀訪問的應(yīng)用程序時要注意的可用性考慮事項以及聲明和放棄（drain）的概念。我將使用的示例特定于只讀環(huán)境；這些示例并不旨在討論有關(guān)更新活動的 COMMIT 考慮事項。本文的范圍限于在以下環(huán)境中對只讀應(yīng)用程序進行 COMMIT 操作：可能在該環(huán)境中執(zhí)行進行更新的實用程序和其它應(yīng)用程序。本文中，我將使用術(shù)語“應(yīng)用程序可用性”來表示關(guān)于允許讀訪問的可用性。

回頁首

獲得聲明

如果您熟悉 DB2，那么您可能對于對象（例如行、頁面、表或表空間）上的不兼容鎖（例如 X 和 S）會降低并發(fā)性有相當(dāng)?shù)牧私狻５绻鷮⒅蛔x程序與 ISOLATION Un COMMIT ted Read（UR）聯(lián)編在一起，會怎么樣呢？這樣做意味著您的只讀程序可能不會獲得任何鎖。要牢記的是，如果涉及到大量刪除，則與 ISOLATION UR 聯(lián)編的程序確實會獲得針對表或表空間的 MASS DELETE 鎖。如果表空間使用工作文件數(shù)據(jù)庫，則還會獲得針對它的 IX 鎖。但是，本文討論只讀方案。

所以問題是，在以 ISOLATION UR 隔離級別綁定進行只讀訪問的應(yīng)用程序中使用 COMMIT 會對整個應(yīng)用程序的可用性產(chǎn)生任何影響嗎？

回答是：會產(chǎn)生影響。

盡管以 ISOLATION UR 隔離級別進行綁定時，進行只讀訪問的應(yīng)用程序沒有獲得鎖，但它確實聲明了這個對象。而正如我將在本文稍后解釋的，聲明可能就是導(dǎo)致可用性降低的原因。正如我前面提到的， COMMIT 釋放了聲明。

現(xiàn)在，在應(yīng)用程序可用性極其重要的環(huán)境中，當(dāng)更新活動很少時，最好安排數(shù)據(jù)庫維護作業(yè)（諸如 REORG 或 IMAGE COPIES ）。這樣做增加了 REORG 作業(yè)與長時間運行的只讀批處理作業(yè)并發(fā)運行的可能性 — 這就是可用性成為問題的原因所在。

REORG 類似于其它實用程序，（在某個階段）需要一個針對對象的 drain 鎖，它會一直等待，直到能獲得一個這樣的鎖為止。放棄是一種用于接管對象并序列化對它的訪問的機制。當(dāng)釋放了對象上的所有聲明，而且預(yù)先不存在 drain 鎖時，就可以獲得 drain 鎖。Drain 請求器防止實用程序獲得已放棄對象上的任何新聲明。

從應(yīng)用程序觀點來看，您可能對可用性問題是如何結(jié)束的感到疑惑。REORG 作業(yè)將一直等待，直到應(yīng)用程序的作業(yè)完成為止嗎？如果在 REORG 實用程序可以請求放棄之前，應(yīng)用程序獲取了聲明，則它會一直等待。但是如果 REORG 先請求放棄，那么它就不會等待。

當(dāng)然，在啟動 REORG 實用程序之前可以初始化應(yīng)用程序的作業(yè)，以確保 REORG 會等待批處理作業(yè)。但是，如果還有另一個批處理作業(yè)或在線事務(wù)，那么它將會進入等待，因為它不能獲取對象的聲明。（新作業(yè)或事務(wù)必需獲取聲明，但是 Drain 請求器 REORG 會阻止該對象的任何聲明。）

作為準備執(zhí)行的只讀程序和 REORG 實用程序（我將解釋這兩個程序可能會也可能不會同時執(zhí)行）的結(jié)果所產(chǎn)生的應(yīng)用程序非可用性程度取決于：

• REORG 上指定的 SHRLEVEL OPTION
• 與 REORG 并發(fā)執(zhí)行的批處理作業(yè)的 COMMIT 頻率。

REORG 實用程序在終止之前，需要放棄所有聲明類。如果 REORG 在執(zhí)行時使用 SHRLEVEL REFERENCE 或 SHRLEVEL CHANGE ，那么會在 SWITCH 階段發(fā)生這個放棄，如果該實用程序執(zhí)行時使用 SHRLEVEL NONE ，那么會在 RELOAD 階段發(fā)生這個放棄。

長時間運行的進程的 COMMIT 頻率也會影響可用性。通過引入 COMMIT 就可以釋放對象上的聲明。注：如果批處理作業(yè)正在使用用 WITH HOLD 定義的游標，那么在經(jīng)過 COMMIT 點之后仍會保留聲明。在所有其它情況下，在 COMMIT 時都釋放對象的聲明。對象聲明的持續(xù)時間并不取決于計劃或包的 BIND 過程中指定的 RELEASE 參數(shù)（ COMMIT 或 DEALLOCATE ）。

表 1 演示了 REORG SHRLEVEL 參數(shù)和 COMMIT 頻率對應(yīng)用程序可用性的的影響。為簡單起見，我們假設(shè)采用一個未分區(qū)的表空間。該表還假設(shè)批處理作業(yè)正在執(zhí)行，并且在 T1 時間觸發(fā) REORG 作業(yè)。讓我們研究該表中顯示的各種情況。

表 1：比較使用 COMMIT 和不使用 COMMIT 時的進程

情況 1. 進程執(zhí)行時不使用任何中間 COMMIT 。使用 SHRLEVEL NONE 的 REORG 作業(yè)在 T1 時間啟動。

情況 2. 進程執(zhí)行時不使用任何中間 COMMIT 。使用 SHRLEVEL REFERENCE 或 CHANGE 的 REORG 作業(yè)在 T1 時間啟動。

情況 3. 進程執(zhí)行時，在 T3 時間進行中間 COMMIT 。使用 SHRLEVEL NONE 的 REORG 作業(yè)在 T1 時間啟動。

情況 4. 進程執(zhí)行時，在 T3 時間進行中間 COMMIT 。使用 SHRLEVEL REFERENCE 或 CHANGE 的 REORG 作業(yè)在 T1 時間啟動。

情況 5. 進程執(zhí)行時，不包含任何中間 COMMIT ，但與情況 2 相比，執(zhí)行完成所花的時間比較長。

情況 6. 進程執(zhí)行時，在 T3 時間進行中間 COMMIT ，但與情況 4 相比，執(zhí)行完成所花的時間比較長。

從表 1 您可以得出如下結(jié)論：

• 不進行中間 COMMIT 的批處理作業(yè)在與 REORG （ SHRLEVEL NONE ）作業(yè)并發(fā)執(zhí)行時所產(chǎn)生的非可用性持續(xù)的時間最長。非可用性程度取決于進程（最可能的是批處理作業(yè)）的持續(xù)時間和正在被重組的表空間大小。
• 從情況 2 和情況 4 中可以看出，當(dāng) REORG 與不考慮 COMMIT 頻率的批處理作業(yè)并發(fā)執(zhí)行時，非可用性時間看起來相同；但是事實并非如此。如果情況 2 中的進程執(zhí)行的時間更長，它會導(dǎo)致 REORG 等待的時間更長，從而增加應(yīng)用程序非可用性時間。如果情況 4 中也出現(xiàn)類似的情況，它導(dǎo)致很少的進程等待時間（ T5 時間），而 REORG 實用程序在切換（switch）階段執(zhí)行并在該階段終止。但是，不會增加非可用性時間（請參閱情況 5 和情況 6）。
• 如果進程的等待時間超過了 DSNZPARM 中的 IRLMRWT 值，那么進程將以 -911 （超時）終止。如果應(yīng)用程序中這種情況很常見，那么請考慮提高 IRLMRWT 值，或?qū)⒅卦囘壿嫼喜⒌匠绦蛑小?
• 如果實用程序的等待時間超過了實用程序的超時時間，那么實用程序就超時。通過使 UTIMOUT 與 IRLMRWT 相乘可以確定實用程序超時時間。您可能有興趣通過提高這兩個參數(shù)中任一個或同時提高這兩個參數(shù)來提高該實用程序的超時時間。但請謹慎使用這個方法。注：在所有情況中，每當(dāng) REORG 作業(yè)轉(zhuǎn)至等待狀態(tài)（等待獲得 drain 鎖），它會導(dǎo)致應(yīng)用程序的非可用性。因此，當(dāng)您在提高實用程序超時值時應(yīng)該小心，因為它將對可用性產(chǎn)生直接影響。

 

回頁首

解決方案

用 SHRLEVEL REFERENCE （允許并發(fā)的讀操作）或用 SHRLEVEL CHANGE （允許并發(fā)的更改操作）方式執(zhí)行 REORG 實用程序以及使長時間運行的進程發(fā)出中間 COMMIT 是解決可用性問題的優(yōu)秀方案。決定 COMMIT 頻率的關(guān)鍵因素是非可用性最大容許量以及 DSNZPARM 中定義的實用程序超時值。 COMMIT 頻率應(yīng)該小于非可用性最大容許度。如果大于或等于的話，從本文中您已經(jīng)了解到，它會導(dǎo)致可能的非可用性（當(dāng) REORG 在等待放棄所有聲明時，禁止任何新的聲明）。

即使 COMMIT 頻率低于非可用性最大容許度，但使用 DB2 V6（或更低版本）時，已分區(qū)表空間的 SWITCH 階段也可能會花相當(dāng)一段時間（以便 IDCAMS 進行重命名），從而導(dǎo)致非可用性。使用 DB2 V7，通過使用 FASTSWITCH YES （缺省值）會緩解該問題。如果 COMMIT 頻率大于實用程序超時值，那么它就可能使 REORG 實用程序未完成任何工作就超時了。DB2 V7 引入了兩個新選項： DRAIN WAIT （指定覆蓋實用程序超時值的時間）和 RETRY （在發(fā)出超時之前進行重試的次數(shù)），以防止 REORG 超時。

回頁首

做就是了

雖然在引入中間 COMMIT 時會產(chǎn)生與之相關(guān)的額外開銷（至少需要一個額外的數(shù)據(jù)庫調(diào)用），但是通過仔細規(guī)劃，用相當(dāng)?shù)偷耐顿Y（CPU 開銷）獲得相當(dāng)好的回報（應(yīng)用程序可用性）是可能的。

回頁首

參考資料

DB2 for z/OS and OS/390
ibm.com/software/ db2zos

關(guān)于作者

		Pranav Sampat 是 Cognizant Technology Solutions 的顧問。他是數(shù)據(jù)庫設(shè)計、性能、恢復(fù)和可用性方面的 IBM 認證的 DB2 DBA。可以通過 spranav@email.cognizant.com與他聯(lián)系。