使用select監視update的操作

問題描述:在secureCRT上開了兩個會話連線的資料倉儲系統,A會話中執行一個大表的update操作,覆蓋所有記錄;
B會話在此期間select該表當前記錄數,發現記錄數逐漸減少到零有增加到原記錄條數.

之前方向錯了,想從update的處理機制來找原因,其實這個問題透過分析併發的隔離級別就可以很清晰了:
DB2中列出的四種併發問題:
? 丟失更新：這種情況發生在兩個事務讀取並嘗試更新同一資料時，其中一個更新會丟失。例如：事務 1 和事務 2 讀取同一行資料，並都根據所讀取的資料計算出該行的新值。如果事務 1 用它的新值更新該行以後，事務 2 又更新了同一行，則事務 1 所執行的更新操作就丟失了。由於設計 DB2 的方法，DB2 不允許發生此類現象。
? 髒讀：當事務讀取尚未提交的資料時，就會發生這種情況。例如：事務 1 更改了一行資料，而事務 2 在事務 1 提交更改之前讀取了已更改的行。如果事務 1 回滾該更改，則事務 2 就會讀取被認為是不曾存在的資料。
? 不可重複的讀：當一個事務兩次讀取同一行資料，但每次獲得不同的資料值時，就會發生這種情況。例如：事務 1 讀取了一行資料，而事務 2 在更改或刪除該行後提交了更改。當事務 1 嘗試再次讀取該行時，它會檢索到不同的資料值（如果該行已經被更新的話），或發現該行不復存在了（如果該行被刪除的話）。
? 幻像：當最初沒有看到某個與搜尋條件匹配的資料行，而在稍後的讀操作中又看到該行時，就會發生這種情況。例如：事務 1 讀取滿足某個搜尋條件的一組資料行，而事務 2 插入了與事務 1 的搜尋條件匹配的新行。如果事務 1 再次執行產生原先行集的查詢，就會檢索到不同的行集。

四種隔離級別:
? 可重複的讀（Repeatable Read）
? 讀穩定性（Read Stability）
? 遊標穩定性（Cursor Stability）
? 未提交的讀（Uncommitted Read）

四種隔離級別可以處理的問題:
可重複讀隔離級別是最嚴格的隔離級別。在使用它時，一個事務的影響完全與其他併發事務隔離：髒讀、不可重複的讀、幻像都不會發生。
讀穩定性隔離級別沒有可重複讀隔離級別那麼嚴格；因此，它沒有將事務與其他併發事務的效果完全隔離。讀穩定性隔離級別可以防止髒讀和不可重複的讀，但是可能出現幻像。
遊標穩定性隔離級別在隔離事務效果方面非常寬鬆。它可以防止髒讀；但有可能出現不可重複的讀和幻像。
未提交的讀隔離級別是最不嚴格的隔離級別。實際上，在使用這個隔離級別時，僅當另一個事務試圖刪除或更改被檢索的行所在的表時，才會鎖定一個事務檢索的行。

如何選擇隔離級別:
? 如果正在執行大型查詢，而且不希望併發事務所做的修改導致查詢的多次執行返回不同的結果，則使用可重複的讀隔離級別。
? 如果希望在應用程式之間獲得一定的併發性，還希望限定的行在事務執行期間保持穩定，則使用讀穩定性隔離級別。
? 如果希望獲得最大的併發性，同時不希望查詢看到未提交的資料，則使用遊標穩定性隔離級別。
? 如果正在只讀的表/檢視/資料庫上執行查詢，或者並不介意查詢是否返回未提交的資料，則使用未提交的讀隔離級別。
[@more@]