|
SCN是當(dāng)Oracle數(shù)據(jù)庫(kù)更新后，由DBMS自動(dòng)維護(hù)去累積遞增的一個(gè)數(shù)字。當(dāng)一筆交易commit時(shí)，LGWR會(huì)將log buffer寫(xiě)入redo log file，同時(shí)也會(huì)將該筆交易的SCN同步寫(xiě)入到redo log file內(nèi)（wait-until-completed）。因此當(dāng)你commit transaction時(shí)，在交易成功的訊息返回之前，LGWR必須先完整的完成上述行為之后，否則你是看不到提交成功的回應(yīng)訊息。
可以查詢(xún)目前系統(tǒng)最新的SCN
SQL>select dbms_flashback.get_system_change_number from dual; 可以理解，這里返回的SCN，也是目前redo log file最新的SCN紀(jì)錄。因?yàn)閏ommit后的交易才會(huì)有SCN，而一旦commit就會(huì)立刻寫(xiě)入redo log file中。 checkpoint 發(fā)生的時(shí)候?qū)?yīng)了一個(gè) scn ，表示 檢查點(diǎn)發(fā)生的時(shí)間點(diǎn)，也表示對(duì)應(yīng)在這個(gè) 時(shí)間點(diǎn)之前的dirty buffer 都將被寫(xiě)到數(shù)據(jù)文件。 當(dāng)寫(xiě)完的時(shí)候也就是這個(gè)檢查點(diǎn)對(duì)應(yīng)結(jié)束，然后把這個(gè)scn寫(xiě)到數(shù)據(jù)文件頭，表示這個(gè)時(shí)間點(diǎn)之前的數(shù)據(jù)安全寫(xiě)到數(shù)據(jù)文件，oracle在將來(lái)恢復(fù)的時(shí)候就可以從這個(gè)時(shí)間點(diǎn)開(kāi)始應(yīng)用歸檔日志。此句出自biti_rainy 人生就是如此
CHECKPOINT和SCN的關(guān)聯(lián) Checkpoint發(fā)生的目的就是要把存儲(chǔ)在buffer內(nèi)的已提交交易寫(xiě)回disk，否則一旦發(fā)生crash，需要進(jìn)行recovery時(shí)，就必須花很多時(shí)間從redo log file內(nèi)最后的SCN交易開(kāi)始進(jìn)行recovery，這樣在商業(yè)應(yīng)用上是很浪費(fèi)時(shí)間和沒(méi)有效率的。 當(dāng)commit一筆交易時(shí)，只會(huì)立刻將redo buffer寫(xiě)入redo log file內(nèi)，但是并不會(huì)馬上將該update后的block（dirty block）同步寫(xiě)回disk datafile中，這是為了減少過(guò)多disk IO，所以采取batch方式寫(xiě)入。 When a checkpoint occurs. Oracle must update the headers of all datafiles to record the details of the checkpoint. This is done by the CKPT process. The CKPT process does not write blocks to disk; DBWn always performs that work. 在shutdown normal or shutdown immediate下，也就是所謂的clean shutdown, checkpoint也會(huì)自動(dòng)觸發(fā)。當(dāng)發(fā)生checkpoint時(shí)，會(huì)把SCN寫(xiě)到四個(gè)地方去。三個(gè)地方在control file 內(nèi)，一個(gè)在datafile header。 Control file三個(gè)地方為： 1、 System checkpoint SCN SQL> select to_char(checkpoint_change#, 'XXXXXXXXXXXX') from v$database; TO_CHAR(CHECKPOINT_CHANGE#,'XX --------------------------------------------------------------------------- 7161D7365DC 2、 Datafile checkpoint SCN SQL> select name, to_char(checkpoint_change#,'XXXXXXXXXXXX') from v$datafile where name like '%gisdts01%'; NAME ----------------------------------------------------------------------------------------------------------------TO_CHAR(CHECKPOINT_CHANGE#,'XX ---------------------------------------------------------------------------------------------------------------- /gisdata/datafile/gisdts01.dbf 7161D7365DC 3、 Stop SCN SQL> select name,last_change# from v$datafile where name like '%gisdts01%'; NAME -------------------------------- /gisdata/datafile/gisdts01.dbf 正常datafile在read-write mode運(yùn)作下，last_change#一定是null 還有一個(gè)SCN在datafile header內(nèi) 4、 Start SCN SQL>select name,to_char(checkpoint_change#,'XXXXXXXXXXXX') from v$datafile_header where name like '%gisdts01%'; NAME ---------------------------------------------------------------------------------------------------------------- TO_CHAR(CHECKPOINT_CHANGE#,'XX ---------------------------------------------------------------------------------------------------------------- /gisdata/datafile/gisdts01.dbf 7161D7365DC 為什么儲(chǔ)存在control file中要分為兩個(gè)地方（system checkpoint scn, datafile checkpoint scn?）。當(dāng)把一個(gè)tbs設(shè)為read-only時(shí)，他的scn會(huì)凍結(jié)停止，此時(shí)datafile checkpoint scn是不會(huì)再遞增改變的，但是整體的system checkpoint scn卻仍然會(huì)不斷遞增前進(jìn)。所以這是為什么需要分別在兩個(gè)地方儲(chǔ)存SCN。 正常shutdown database后，SCN會(huì)發(fā)生什么變化？ 可以把數(shù)據(jù)庫(kù)開(kāi)在mount mode SQL> select to_char(checkpoint_change#,'XXXXXXXXXXXX') from v$database; TO_CHAR(CHECKPOINT_CHANGE#,'XX -------------------------------------------------------------------------------- 7161D7455B9 SQL>select name,to_char(checkpoint_change#,’XXXXXXXXXXXX’),to_char(last_change#,’XXXXXXXXXXXX’) from v$datafile where name like '%gisdts01%'; NAME -------------------------------------------------------------------------------- TO_CHAR(CHECKPOINT_CHANGE#,'XX -------------------------------------------------------------------------------- TO_CHAR(LAST_CHANGE#,'XXXXXXXX -------------------------------------------------------------------------------- /gisdata/datafile/gisdts01.dbf 7161D7455B9 7161D7455B9 可以看到儲(chǔ)存在control file中的三個(gè)SCN的數(shù)值都是相同的，注意此時(shí)的stop scn不會(huì)是null，而是等于start scn。 再來(lái)查詢(xún)datafile header中的SCN： SQL> select name, to_char(checkpoint_change#,'XXXXXXXXXXXX') from v$datafile_hea der where name like '%gisdts01%'; NAME -------------------------------------------------------------------------------- TO_CHAR(CHECKPOINT_CHANGE#,'XX -------------------------------------------------------------------------------- /gisdata/datafile/gisdts01.dbf 7161D7455B9 當(dāng)clean shutdown時(shí)，checkpoint會(huì)進(jìn)行，并且此時(shí)datafile的stop scn和start scn會(huì)相同。等我們打開(kāi)數(shù)據(jù)庫(kù)時(shí)，oracle會(huì)檢查datafile header中的start scn和存于control file中的datafile的scn是否相同，如果相同，接著檢查start scn和stop scn是否相同，如果仍然相同，數(shù)據(jù)庫(kù)會(huì)正常啟動(dòng)，否則就需要recovery….等到數(shù)據(jù)庫(kù)open后，儲(chǔ)存在control file中的stop scn就會(huì)恢復(fù)為null值，此時(shí)表示datafile是open在正常模式下。 如果不正常shutdown(shutdown abort)，則mount數(shù)據(jù)庫(kù)后，會(huì)發(fā)現(xiàn)stop scn并不等于其它位置的scn，而是等于null。這表示oracle在shutdown時(shí)沒(méi)有進(jìn)行checkpoint，下次啟動(dòng)必須進(jìn)行crash recovery |
|
|
來(lái)自： 168一路發(fā) > 《維護(hù)》
