透析SCN號

SCN是當Oracle數據庫更新後，由DBMS自動維護去累積遞增的一個數字。當一筆交易commit時，LGWR會將log buffer寫入redo log file，同時也會將該筆交易的SCN同步寫入到redo log file內（wait-until-completed）。所以當你commit transaction時，在交易成功的訊息返回以前，LGWR必須先完整的完成上述行爲以後，不然你是看不到提交成功的迴應訊息。
能夠查詢目前系統最新的SCN
SQL>select dbms_flashback.get_system_change_number from dual;
能夠理解，這裏返回的SCN，也是目前redo log file最新的SCN紀錄。由於commit後的交易纔會有SCN，而一旦commit就會馬上寫入redo log file中。

CHECKPOINT和SCN的關聯
Checkpoint發生的目的就是要把存儲在buffer內的已提交交易寫回disk，不然一旦發生crash，須要進行recovery時，就必須花不少時間從redo log file內最後的SCN交易開始進行recovery，這樣在商業應用上是很浪費時間和沒有效率的。
當commit一筆交易時，只會馬上將redo buffer寫入redo log file內，可是並不會立刻將該update後的block（dirty block）同步寫回disk datafile中，這是爲了減小過多disk IO，因此採起batch方式寫入。
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也會自動觸發。當發生checkpoint時，會把SCN寫到四個地方去。三個地方在control file 內，一個在datafile header。

Control file三個地方爲：
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運做下，last_change#必定是null


還有一個SCN在datafile header內
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
爲何儲存在control file中要分爲兩個地方（system checkpoint scn, datafile checkpoint scn?）。當把一個tbs設爲read-only時，他的scn會凍結中止，此時datafile checkpoint scn是不會再遞增改變的，可是總體的system checkpoint scn卻仍然會不斷遞增前進。因此這是爲何須要分別在兩個地方儲存SCN。

正常shutdown database後，SCN會發生什麼變化？
能夠把數據庫開在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
能夠看到儲存在control file中的三個SCN的數值都是相同的，注意此時的stop scn不會是null，而是等於start scn。
再來查詢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

當clean shutdown時，checkpoint會進行，而且此時datafile的stop scn和start scn會相同。等咱們打開數據庫時，oracle會檢查datafile header中的start scn和存於control file中的datafile的scn是否相同，若是相同，接着檢查start scn和stop scn是否相同，若是仍然相同，數據庫會正常啓動，不然就須要recovery….等到數據庫open後，儲存在control file中的stop scn就會恢復爲null值，此時表示datafile是open在正常模式下。
若是不正常shutdown(shutdown abort)，則mount數據庫後，會發現stop scn並不等於其它位置的scn，而是等於null。這表示oracle在shutdown時沒有進行checkpoint，下次啓動必須進行crash recovery。

原文地址http://blog.chinaunix.net/u/12476/showart.php?id=142021