淺述當(dāng)前模式讀與一致性讀的區(qū)別
讓我從以下2個(gè)例子展開(kāi)我們的探討。
- 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>
如果你觀察得足夠仔細(xì)，你可以從上面2個(gè)例子看到一個(gè)有趣的現(xiàn)象：無(wú)論session 1是否命中到數(shù)據(jù)，it最終都沒(méi)有修改數(shù)據(jù)。其根本原因就是當(dāng)前模式讀與一致性讀的區(qū)別。
我們知道，為了減少并發(fā)沖突，Oracle引入了MVCC（多版本并發(fā)控制，也叫MCC）方法。在這種機(jī)制中，并發(fā)事務(wù)不會(huì)因?yàn)橐恢滦缘脑蚨嗷プ枞?，除非他們要修改同一條記錄。他們會(huì)將日志中所有SCN大于本身事務(wù)SCN的日志做回滾，以保證本事務(wù)讀取到的數(shù)據(jù)塊與事務(wù)SCN的一致。在Oracle中，這樣的讀取行為就稱(chēng)為一致性讀。
然而，一致性讀所讀取到數(shù)據(jù)塊僅僅是某個(gè)時(shí)間點(diǎn)的一個(gè)快照，也就是說(shuō)這樣的數(shù)據(jù)是只讀的。如果要修改數(shù)據(jù)，那么oracle需要讀取到當(dāng)前的數(shù)據(jù)塊，也就是當(dāng)前模式讀。
在一個(gè)UPDATE過(guò)程中，oracle會(huì)先一致性讀取與事務(wù)SCN一致的數(shù)據(jù)快照，并用where條件進(jìn)行過(guò)濾。讓后根據(jù)讀取到數(shù)據(jù)塊的ID，再?gòu)漠?dāng)前數(shù)據(jù)中讀取到相應(yīng)的數(shù)據(jù)塊進(jìn)行修改。但是，如在事務(wù)啟動(dòng)后到數(shù)據(jù)塊被讀取之間的這段時(shí)間內(nèi)，相應(yīng)的數(shù)據(jù)塊發(fā)生了改變，那么可能就會(huì)有我們意想不到的事情發(fā)生。
往回看我們的***個(gè)例子。我們?cè)趕ession 1中，在10:22:25啟動(dòng)了update事務(wù)。但是，由于該事務(wù)中存在一個(gè)大的子查詢(xún)，它會(huì)在幾十秒后才會(huì)讀取到需要被修改的數(shù)據(jù)。在Session 2中，我們?cè)?0:22:37開(kāi)始update這些數(shù)據(jù)并在10:23:02提交了事務(wù)。而這個(gè)時(shí)間是早于數(shù)據(jù)在session 1中被讀取到的時(shí)間的。當(dāng)session 2中的數(shù)據(jù)改變被提交后，session 1中的事務(wù)讀取到了該數(shù)據(jù)塊。因?yàn)閟ession 2中的事務(wù)SCN大于session 1中的事務(wù)SCN，因此會(huì)讀取UNDO中的數(shù)據(jù)進(jìn)行回滾，也就是說(shuō)它讀取到數(shù)據(jù)SECONDARY是'A'，再通過(guò)條件(SECONDARY='B')過(guò)濾后，沒(méi)有數(shù)據(jù)被命中，因此也沒(méi)有數(shù)據(jù)被修改。
在第二個(gè)例子中，session 1的事務(wù)在一致性讀取到數(shù)據(jù)塊之前也發(fā)生了類(lèi)似的事情。當(dāng)它回滾了數(shù)據(jù)后，它一致性讀取到了滿(mǎn)足過(guò)濾條件(SECONDARY='A')的數(shù)據(jù)塊。此時(shí)，它需要通過(guò)該數(shù)據(jù)塊ID再到當(dāng)前數(shù)據(jù)中讀取該數(shù)據(jù)塊。但是因?yàn)楫?dāng)前數(shù)據(jù)塊的內(nèi)容已經(jīng)被session 2中的事務(wù)所修改，它還是沒(méi)有能修改到數(shù)據(jù)。
我想，通過(guò)這兩個(gè)例子，讀者應(yīng)該更容易理解到當(dāng)前模式讀與一致性讀之間的區(qū)別。
【編輯推薦】
