Posted on 2009-08-06 19:47
Prayer 閱讀(407)
評論(0) 編輯 收藏 引用 所屬分類:
DB2
2003 年 1 月 01 日
在只讀情況下進行 COMMIT 時釋放鎖并釋放應用程序。
簡介
許多正在使用 DB2 for z/OS 或 DB2 for OS/390 的人都認為對只讀訪問使用 COMMIT 是沒有必要的。這些人認為，因為他們沒有更改任何數據，所以沒有必要使用 COMMIT 。但是 COMMIT 不僅應用更改, 它還釋放鎖和聲明（claim）, 所以 COMMIT 會影響應用程序可用性。
我要解釋在將 COMMIT 引入到進行只讀訪問的應用程序時要注意的可用性考慮事項以及聲明和放棄（drain）的概念。我將使用的示例特定于只讀環境；這些示例并不旨在討論有關更新活動的 COMMIT 考慮事項。本文的范圍限于在以下環境中對只讀應用程序進行 COMMIT 操作：可能在該環境中執行進行更新的實用程序和其它應用程序。本文中，我將使用術語“應用程序可用性”來表示關于允許讀訪問的可用性。
獲得聲明
如果您熟悉 DB2，那么您可能對于對象（例如行、頁面、表或表空間）上的不兼容鎖（例如 X 和 S）會降低并發性有相當的了解。但如果您將只讀程序與 ISOLATION Un COMMIT ted Read（UR）聯編在一起，會怎么樣呢？這樣做意味著您的只讀程序可能不會獲得任何鎖。要牢記的是，如果涉及到大量刪除，則與 ISOLATION UR 聯編的程序確實會獲得針對表或表空間的 MASS DELETE 鎖。如果表空間使用工作文件數據庫，則還會獲得針對它的 IX 鎖。但是，本文討論只讀方案。
所以問題是，在以 ISOLATION UR 隔離級別綁定進行只讀訪問的應用程序中使用 COMMIT 會對整個應用程序的可用性產生任何影響嗎？
回答是：會產生影響。
盡管以 ISOLATION UR 隔離級別進行綁定時，進行只讀訪問的應用程序沒有獲得鎖，但它確實聲明了這個對象。而正如我將在本文稍后解釋的，聲明可能就是導致可用性降低的原因。正如我前面提到的， COMMIT 釋放了聲明。
現在，在應用程序可用性極其重要的環境中，當更新活動很少時，最好安排數據庫維護作業（諸如 REORG 或 IMAGE COPIES ）。這樣做增加了 REORG 作業與長時間運行的只讀批處理作業并發運行的可能性 — 這就是可用性成為問題的原因所在。
REORG 類似于其它實用程序，（在某個階段）需要一個針對對象的 drain 鎖，它會一直等待，直到能獲得一個這樣的鎖為止。放棄是一種用于接管對象并序列化對它的訪問的機制。當釋放了對象上的所有聲明，而且預先不存在 drain 鎖時，就可以獲得 drain 鎖。Drain 請求器防止實用程序獲得已放棄對象上的任何新聲明。
從應用程序觀點來看，您可能對可用性問題是如何結束的感到疑惑。REORG 作業將一直等待，直到應用程序的作業完成為止嗎？如果在 REORG 實用程序可以請求放棄之前，應用程序獲取了聲明，則它會一直等待。但是如果 REORG 先請求放棄，那么它就不會等待。
當然，在啟動 REORG 實用程序之前可以初始化應用程序的作業，以確保 REORG 會等待批處理作業。但是，如果還有另一個批處理作業或在線事務，那么它將會進入等待，因為它不能獲取對象的聲明。（新作業或事務必需獲取聲明，但是 Drain 請求器 REORG 會阻止該對象的任何聲明。）
作為準備執行的只讀程序和 REORG 實用程序（我將解釋這兩個程序可能會也可能不會同時執行）的結果所產生的應用程序非可用性程度取決于：
REORG 上指定的 SHRLEVEL OPTION
- 與
REORG 并發執行的批處理作業的 COMMIT 頻率。
REORG 實用程序在終止之前，需要放棄所有聲明類。如果 REORG 在執行時使用 SHRLEVEL REFERENCE 或 SHRLEVEL CHANGE ，那么會在 SWITCH 階段發生這個放棄，如果該實用程序執行時使用 SHRLEVEL NONE ，那么會在 RELOAD 階段發生這個放棄。
長時間運行的進程的 COMMIT 頻率也會影響可用性。通過引入 COMMIT 就可以釋放對象上的聲明。注：如果批處理作業正在使用用 WITH HOLD 定義的游標，那么在經過 COMMIT 點之后仍會保留聲明。在所有其它情況下，在 COMMIT 時都釋放對象的聲明。對象聲明的持續時間并不取決于計劃或包的 BIND 過程中指定的 RELEASE 參數（ COMMIT 或 DEALLOCATE ）。
表 1 演示了 REORG SHRLEVEL 參數和 COMMIT 頻率對應用程序可用性的的影響。為簡單起見，我們假設采用一個未分區的表空間。該表還假設批處理作業正在執行，并且在 T1 時間觸發 REORG 作業。讓我們研究該表中顯示的各種情況。
表 1：比較使用 COMMIT 和不使用 COMMIT 時的進程
情況 1. 進程執行時不使用任何中間 COMMIT 。使用 SHRLEVEL NONE 的 REORG 作業在 T1 時間啟動。
情況 2. 進程執行時不使用任何中間 COMMIT 。使用 SHRLEVEL REFERENCE 或 CHANGE 的 REORG 作業在 T1 時間啟動。
情況 3. 進程執行時，在 T3 時間進行中間 COMMIT 。使用 SHRLEVEL NONE 的 REORG 作業在 T1 時間啟動。
情況 4. 進程執行時，在 T3 時間進行中間 COMMIT 。使用 SHRLEVEL REFERENCE 或 CHANGE 的 REORG 作業在 T1 時間啟動。
情況 5. 進程執行時，不包含任何中間 COMMIT ，但與情況 2 相比，執行完成所花的時間比較長。
情況 6. 進程執行時，在 T3 時間進行中間 COMMIT ，但與情況 4 相比，執行完成所花的時間比較長。
從表 1 您可以得出如下結論：
- 不進行中間
COMMIT 的批處理作業在與 REORG （ SHRLEVEL NONE ）作業并發執行時所產生的非可用性持續的時間最長。非可用性程度取決于進程（最可能的是批處理作業）的持續時間和正在被重組的表空間大小。
- 從情況 2 和情況 4 中可以看出，當
REORG 與不考慮 COMMIT 頻率的批處理作業并發執行時，非可用性時間看起來相同；但是事實并非如此。如果情況 2 中的進程執行的時間更長，它會導致 REORG 等待的時間更長，從而增加應用程序非可用性時間。如果情況 4 中也出現類似的情況，它導致很少的進程等待時間（ T5 時間），而 REORG 實用程序在切換（switch）階段執行并在該階段終止。但是，不會增加非可用性時間（請參閱情況 5 和情況 6）。
- 如果進程的等待時間超過了
DSNZPARM 中的 IRLMRWT 值，那么進程將以 -911 （超時）終止。如果應用程序中這種情況很常見，那么請考慮提高 IRLMRWT 值，或將重試邏輯合并到程序中。
- 如果實用程序的等待時間超過了實用程序的超時時間，那么實用程序就超時。通過使
UTIMOUT 與 IRLMRWT 相乘可以確定實用程序超時時間。您可能有興趣通過提高這兩個參數中任一個或同時提高這兩個參數來提高該實用程序的超時時間。但請謹慎使用這個方法。注：在所有情況中，每當 REORG 作業轉至等待狀態（等待獲得 drain 鎖），它會導致應用程序的非可用性。因此，當您在提高實用程序超時值時應該小心，因為它將對可用性產生直接影響。
 |
|
解決方案
用 SHRLEVEL REFERENCE （允許并發的讀操作）或用 SHRLEVEL CHANGE （允許并發的更改操作）方式執行 REORG 實用程序以及使長時間運行的進程發出中間 COMMIT 是解決可用性問題的優秀方案。決定 COMMIT 頻率的關鍵因素是非可用性最大容許量以及 DSNZPARM 中定義的實用程序超時值。 COMMIT 頻率應該小于非可用性最大容許度。如果大于或等于的話，從本文中您已經了解到，它會導致可能的非可用性（當 REORG 在等待放棄所有聲明時，禁止任何新的聲明）。
即使 COMMIT 頻率低于非可用性最大容許度，但使用 DB2 V6（或更低版本）時，已分區表空間的 SWITCH 階段也可能會花相當一段時間（以便 IDCAMS 進行重命名），從而導致非可用性。使用 DB2 V7，通過使用 FASTSWITCH YES （缺省值）會緩解該問題。如果 COMMIT 頻率大于實用程序超時值，那么它就可能使 REORG 實用程序未完成任何工作就超時了。DB2 V7 引入了兩個新選項： DRAIN WAIT （指定覆蓋實用程序超時值的時間）和 RETRY （在發出超時之前進行重試的次數），以防止 REORG 超時。
做就是了
雖然在引入中間 COMMIT 時會產生與之相關的額外開銷（至少需要一個額外的數據庫調用），但是通過仔細規劃，用相當低的投資（CPU 開銷）獲得相當好的回報（應用程序可用性）是可能的。
參考資料
DB2 for z/OS and OS/390
ibm.com/software/ db2zos
關于作者
http://www.ibm.com/developerworks/cn/data/library/techarticles/mag_0211sampat/0211sampat.html