oracle工作機制問題

bjup

請教高手！～～
  在對數(shù)據(jù)庫表進行update且未commit時，這時進行的update是否已經(jīng)修改了數(shù)據(jù)文件,rollback時是從回滾段中把修改前的數(shù)據(jù)再重新寫回數(shù)據(jù)文件。

ora_admin

未commit時update并未修改數(shù)據(jù)文件，只是修改了內(nèi)存中的一個鏡像塊，dbwr運行時才會修改數(shù)據(jù)文件，

bjup

看了一些資料，個人認為在未進行commit時，也有可能已經(jīng)更新將數(shù)據(jù)文件更新，因為雖然在未commit時修改的是db buffer中的數(shù)據(jù)塊，假如更新的數(shù)據(jù)塊很多，臟數(shù)據(jù)列表達到一定長度時會觸發(fā)DBWR將數(shù)據(jù)塊寫入數(shù)據(jù)文件，不知道是否是這樣的。下邊是個人總結(jié)的oracle執(zhí)行update時的工作流程，請高人指點是否正確。

假如update語句影響的數(shù)據(jù)塊在db buffer沒有
第一步:從數(shù)據(jù)文件提前數(shù)據(jù)塊
第二步:將讀入的數(shù)據(jù)塊的頭部事務(wù)列表及SCN信息及被影響的行數(shù)據(jù)原值寫入回滾段
第三步:將update語句影響的被讀入DB BUFFER塊中的這些行的ROWID及將要更新的原值和新值及SCN等信息寫入log buffer
第四步:修改DB BUFFER中的數(shù)據(jù)塊
第五步:服務(wù)器進程在臟數(shù)據(jù)列表中建立一條指向此DB BUFFER緩沖塊的指針
第六步:假如update語句影響的數(shù)據(jù)塊比較多，則重復(fù)執(zhí)行1至5步
第七步:commit
在執(zhí)行上述步驟時，LGWR根據(jù)一定機制將log buffer的日志寫入日志文件，DBWR根據(jù)一定機制將db buffer中修改過的數(shù)據(jù)塊里的信息寫入數(shù)據(jù)文件

blue_stone

你看Oracle官方文檔的Concepts了么?
這里邊有關(guān)于各種概念的標準答案

blue_stone

原帖由 bjup 于 2008-10-13 15:08 發(fā)表
請教高手！～～
  在對數(shù)據(jù)庫表進行update且未commit時，這時進行的update是否已經(jīng)修改了數(shù)據(jù)文件,rollback時是從回滾段中把修改前的數(shù)據(jù)再重新寫回數(shù)據(jù)文件。

是否修改數(shù)據(jù)文件重要么?

在update的時候, oracle會修改buffer cache中的數(shù)據(jù)塊, 原數(shù)據(jù)塊的內(nèi)容被復(fù)制到了rollback segment的buffer cache中, rollback時rollback segment的buffer cache中的原數(shù)據(jù)塊被復(fù)制到數(shù)據(jù)段的baffer cache中.

致于buffer cache中的數(shù)據(jù)是否被寫到數(shù)據(jù)文件, 則要看DBWR的了.

big.dragon.bj

贊同3樓的說法，即便不commit，對數(shù)據(jù)的修改也可能寫入數(shù)據(jù)文件，commit包含兩種方式：直接執(zhí)行commit屬于顯式提交，還有一種試隱式提交的。

bjup

在同一個session下，執(zhí)行update后未commit，在當前session下查詢的數(shù)據(jù)為甚么顯示已經(jīng)更新。步驟如下：
1.select * from test;
num         date
1        2008-10-9 15:13:08
2        2008-10-9 15:13:08
3        2008-10-9 15:13:12
4        2008-10-9 15:13:13
5        2008-10-9 15:13:19
6        2008-10-9 15:13:25
7        2008-10-9 15:33:05
8        2008-10-9 15:33:06
9        2008-10-9 16:53:01
10        2008-10-9 16:53:09

2.執(zhí)行uptate test set num=num+1;
3.查詢select * from test;
num         date
2        2008-10-9 15:13:08
3        2008-10-9 15:13:08
4        2008-10-9 15:13:12
5        2008-10-9 15:13:13
6        2008-10-9 15:13:19
7        2008-10-9 15:13:25
8        2008-10-9 15:33:05
9        2008-10-9 15:33:06
10        2008-10-9 16:53:01
11        2008-10-9 16:53:09

4.重新打開一個session，查詢select * from test;
num         date
1        2008-10-9 15:13:08
2        2008-10-9 15:13:08
3        2008-10-9 15:13:12
4        2008-10-9 15:13:13
5        2008-10-9 15:13:19
6        2008-10-9 15:13:25
7        2008-10-9 15:33:05
8        2008-10-9 15:33:06
9        2008-10-9 16:53:01
10        2008-10-9 16:53:09

目前可以理解步驟4查詢的結(jié)果為甚么不更新。步驟3為甚么執(zhí)行update未commit后，查詢的數(shù)據(jù)為甚么做了更新，請高手指點。

blue_stone

當前session做的更新當然應(yīng)該可以馬上被當前session看到！

關(guān)于讀一致性，多版本，并發(fā)等問題，最好先看看Oracle® Database Concepts中相關(guān)的章節(jié)
http://download.oracle.com/docs/ ... /b14220/consist.htm

這個問題也可以參考各種關(guān)系數(shù)據(jù)庫管理系統(tǒng)的教材，特別是大學教材。在教材中會對各種機制進行學術(shù)上的討論，而不拘泥于某種單一的數(shù)據(jù)庫技術(shù)。

bjup

多謝blue_stone指點！