淺述當(dāng)前模式讀與一致性讀的區(qū)別
讓我從以下2個例子展開我們的探討。
- Case1:
- HELLODBA.COM>set time on
- 10:22:09 HELLODBA.COM>update t_test1 set SECONDARY='A' where object_id = -1;
- 1 row updated.
- 10:22:22 HELLODBA.COM>commit;
- Commit complete.
- Session 1:
- 10:22:25 HELLODBA.COM>update t_test1 set SECONDARY='B' where object_id = -1 and SECONDARY='B' and (select count(*) from t_test2 t1, t_test2 t2) > 0;
- 0 rows updated.
- 10:23:15 HELLODBA.COM>
- Session 2:
- 10:22:37 HELLODBA.COM>update t_test1 set SECONDARY='B' where object_id = -1;
- 1 row updated.
- 10:23:02 HELLODBA.COM>commit;
- Commit complete.
- 10:23:04 HELLODBA.COM>
- Case2:
- 10:25:38 HELLODBA.COM>update t_test1 set SECONDARY='A' where object_id = -1;
- 1 row updated.
- 10:25:48 HELLODBA.COM>commit;
- Commit complete.
- Session 1:
- 10:26:05 HELLODBA.COM>update t_test1 set SECONDARY='B' where object_id = -1 and SECONDARY='A' and (select count(*) from t_test2 t1, t_test2 t2) > 0;
- 0 rows updated.
- 10:27:21 HELLODBA.COM>
- Session 2:
- 10:26:16 HELLODBA.COM>update t_test1 set SECONDARY='B' where object_id = -1;
- 1 row updated.
- 10:26:41 HELLODBA.COM>commit;
- Commit complete.
- 10:26:42 HELLODBA.COM>
如果你觀察得足夠仔細，你可以從上面2個例子看到一個有趣的現(xiàn)象：無論session 1是否命中到數(shù)據(jù)，it最終都沒有修改數(shù)據(jù)。其根本原因就是當(dāng)前模式讀與一致性讀的區(qū)別。
我們知道，為了減少并發(fā)沖突，Oracle引入了MVCC（多版本并發(fā)控制，也叫MCC）方法。在這種機制中，并發(fā)事務(wù)不會因為一致性的原因而相互阻塞，除非他們要修改同一條記錄。他們會將日志中所有SCN大于本身事務(wù)SCN的日志做回滾，以保證本事務(wù)讀取到的數(shù)據(jù)塊與事務(wù)SCN的一致。在Oracle中，這樣的讀取行為就稱為一致性讀。
然而，一致性讀所讀取到數(shù)據(jù)塊僅僅是某個時間點的一個快照，也就是說這樣的數(shù)據(jù)是只讀的。如果要修改數(shù)據(jù)，那么oracle需要讀取到當(dāng)前的數(shù)據(jù)塊，也就是當(dāng)前模式讀。
在一個UPDATE過程中，oracle會先一致性讀取與事務(wù)SCN一致的數(shù)據(jù)快照，并用where條件進行過濾。讓后根據(jù)讀取到數(shù)據(jù)塊的ID，再從當(dāng)前數(shù)據(jù)中讀取到相應(yīng)的數(shù)據(jù)塊進行修改。但是，如在事務(wù)啟動后到數(shù)據(jù)塊被讀取之間的這段時間內(nèi)，相應(yīng)的數(shù)據(jù)塊發(fā)生了改變，那么可能就會有我們意想不到的事情發(fā)生。
往回看我們的***個例子。我們在session 1中，在10:22:25啟動了update事務(wù)。但是，由于該事務(wù)中存在一個大的子查詢，它會在幾十秒后才會讀取到需要被修改的數(shù)據(jù)。在Session 2中，我們在10:22:37開始update這些數(shù)據(jù)并在10:23:02提交了事務(wù)。而這個時間是早于數(shù)據(jù)在session 1中被讀取到的時間的。當(dāng)session 2中的數(shù)據(jù)改變被提交后，session 1中的事務(wù)讀取到了該數(shù)據(jù)塊。因為session 2中的事務(wù)SCN大于session 1中的事務(wù)SCN，因此會讀取UNDO中的數(shù)據(jù)進行回滾，也就是說它讀取到數(shù)據(jù)SECONDARY是'A'，再通過條件(SECONDARY='B')過濾后，沒有數(shù)據(jù)被命中，因此也沒有數(shù)據(jù)被修改。
在第二個例子中，session 1的事務(wù)在一致性讀取到數(shù)據(jù)塊之前也發(fā)生了類似的事情。當(dāng)它回滾了數(shù)據(jù)后，它一致性讀取到了滿足過濾條件(SECONDARY='A')的數(shù)據(jù)塊。此時，它需要通過該數(shù)據(jù)塊ID再到當(dāng)前數(shù)據(jù)中讀取該數(shù)據(jù)塊。但是因為當(dāng)前數(shù)據(jù)塊的內(nèi)容已經(jīng)被session 2中的事務(wù)所修改，它還是沒有能修改到數(shù)據(jù)。
我想，通過這兩個例子，讀者應(yīng)該更容易理解到當(dāng)前模式讀與一致性讀之間的區(qū)別。
【編輯推薦】
