Oracle SCN相關問題學習與測試

1、SCN的介紹

2、SCN的工作機制

3、SCN的增加

4、其他的SCN

5 測試

6 小結

7 問題

1、SCN的介紹

Oracle中的SCN有下面幾種：

1) 系統檢查點scn(v$database(checkpoint_change#))

當一個檢查點動作完成之後，Oracle就把系統檢查點的SCN儲存到控制檔案中

select checkpoint_change# from v$database;

2) 資料檔案檢查點scn (v$datafile(checkpoint_change#))

當一個檢查點動作完成之後，Oracle就把每個資料檔案的scn單獨存放在控制檔案中

select name,checkpoint_change# from v$datafile;

3) 資料檔案終止scn (v$datafile(last_change#))

每個資料檔案的終止scn都儲存在控制檔案中。在正常的資料庫操作過程中，所有正處於聯機讀寫模式下的資料檔案的終止scn都為null, 異常關閉後的Stop SCN, 也為 NULL.

select name,last_change# from v$datafile;

4) 資料檔案啟動scn (v$datafile_header(checkpoint_change#)

Oracle把這個檢查點的scn儲存在每個資料檔案的檔案頭中，這個值稱為啟動scn，因為它用於在資料庫例項啟動時，檢查是否需要執行資料庫恢復

select name,checkpoint_change# from v$datafile_header;

2、SCN的工作機制

1) 在資料庫開啟並執行之後，控制檔案中的系統檢查點scn、控制檔案中的資料檔案檢查點scn和每個資料檔案頭中的啟動scn都是相同的

2 ) 控制檔案中的每個資料檔案的終止scn都為null

3) NORMAL或IMMEDIATE關閉資料庫的過程中，系統會執行一個檢查點動作，這時所有資料檔案的終止scn都會設定成資料檔案頭中的那個啟動scn的值。

4) 在資料庫重新啟動的時，Oracle將執行兩次檢查

◆看資料檔案頭中的ckpt計數器(v$datafile_header.checkpoint_count)是否與對應控制檔案中的ckpt計數器(v$datafile.) 一致。若相等，進行第二次檢查

◆比較檔案頭中的啟動scn和對應控制檔案中的終止scn進行比較，如果終止scn等於啟動scn，則不需要對那個檔案進行恢復

5) 資料庫開啟之後，儲存在控制檔案中的資料檔案終止scn的值再次被更改為null，這表示資料檔案已經開啟並能夠正常使用了

注：當ABORT強制關閉資料庫時不進行檢查點處理，所以終止scn仍然為無窮大。在下次啟動期間，發現啟動scn和終止scn不同，需要進行執行緒恢復。

3、SCN的增加

1) SCN(System Change Number)只要資料庫被修改，就會+1，而不是一定要進行checkpoint，例如DML的發生即使沒有提交也會使SCN+1.(哪些情況下SCN會發生變化? )

注：SCN增加並不代表會在資料檔案頭中表現出來，而是需要等到checkpoint執行後才寫入(當然可能已經增加了很多)

2) 如果一個DML導致產生事務，則會產生一個SCN。這個意思是說如果一個事務包含多個dml，則只有第一個初始產生事務的dml產生scn，提交的時候又是一個scn，如果一個事務只有一個dml，那看起來就是dml產生一個scn，提交或者回滾產生一個scn。

3) Oracle 10g內部的SCN會預設不管有沒有動作，每隔3s自動增加一次。其他需要增加的情況則再加。

4) 只有ckpt程式才會修改檔案頭中的checkpoint計數器和SCN，DBWR只會修改資料塊，即ckpt通知dbwr寫資料檔案，寫完之後ckpt更新控制檔案和資料檔案頭。此時若DBWR發現資料塊的log block還沒有被寫入日誌檔案，則在dbwr寫塊之前通知lgwr把log buffer中的日誌寫入log檔案。

注：總結一下，日誌切換必定觸發ckpt，但ckpt不一定會觸發lgwr，但是一定會觸發dbwr

4、其他的SCN

1) 日誌檔案頭中包含了Low scn、Next scn，表示所給日誌檔案包含有從Low scn到Next scn的redo record. (如何檢視? REDO SCN)

注：當系統執行時，日誌檔案的Next scn同樣為無窮大。而且需要注意：在恢復時定位到底使用哪個日誌檔案的時候，並不是用資料檔案中的 low scn 去框，也不是隻要在日誌檔案的low scn and next scn 之間就利用該日誌檔案。而是在資料檔案頭中有 RBA 的記錄，RBA 包含了日誌序號Sequence#、block number 、slot number 。這樣可以直接定位到日誌檔案（歸檔日誌檔案）和具體的位置。

在確定了哪個資料檔案必須redo後,oracle會比較change vector（向量）中的SCN和資料檔案資料塊中的SCN,如果change vector的SCN小於資料塊的scn,則跳過此change vector,否則應用redo.

2) 資料塊中的SCN

data block裡面的SCN是當block被更改的時候的SCN，而資料檔案有那麼多block，自然不同的block有不同的SCN，block中存在block SCN和ITL中的commit SCN。block SCN又在塊頭和塊位都有，若不一致意味著block損壞。而ITL中的commit SCN則跟consistent gets and delay block cleanout有關。(Block SCN 如何檢視?)

3) v$database中的checkpoint_change#和dbms_flashback.get_system_change_number不同。前者是作為資料庫的最後一次checkpoint是的SCN，而後者是系統的最新SCN，所以一般後者都會比前者大，而當剛做完checkpoint時候兩者會差不多。(Checkpoint的觸發機制?)

4) 當begin backup命令發出後，相關資料檔案的checkpoint scn被凍結(以及狀態標誌被改變)，其他一切照舊。例如：日誌切換時checkpoint count正常遞增/檢查點照常寫檔案，自然檔案中的資料塊內的各種scn也照常遞增。

5 測試:

A. 正常關閉, mount 資料庫

SQL> col system_scn format 999999999999999999

SQL> col datafile_scn format 999999999999999999

SQL> col start_scn format 999999999999999999

SQL> col stop_scn format 999999999999999999

SQL> select a.checkpoint_change# system_scn, c.checkpoint_change# start_scn, scn, re rownum=1) c;

b.checkpoint_change# datafile_scn, decode(b.last_change#,NULL,'null',b.last_change#) stop_scnp_scn

from v$database a,

(select checkpoint_change#, last_change# from v$datafile where rownum =1 ) b,

(select checkpoint_change# from v$datafile_header where rownum=1) c;

SYSTEM_SCN START_SCN DATAFILE_SCN STOP_SCN

------------------- ------------------- ------------------- ----------------------------------------

2696048203982 2696048203982 2696048203982 2696048203982

上述查詢結果表明:

結束SCN都是跟啟動SCN是一樣的，這樣，當資料庫open的時候就可以不用recover了。

把資料庫開啟open

SQL> alter database open;

　　Database altered.

SQL> select a.checkpoint_change# system_scn, c.checkpoint_change# start_scn,

2 b.checkpoint_change# datafile_scn, decode(b.last_change#,NULL,'null',b.last_change#) stop_scn

3 from v$database a,

4 (select checkpoint_change#, last_change# from v$datafile where rownum =1 ) b,

5 (select checkpoint_change# from v$datafile_header where rownum=1) c;

SYSTEM_SCN START_SCN DATAFILE_SCN STOP_SCN

------------------- ------------------- ------------------- ----------------------------------------

2696048203983 2696048203983 2696048203983 null

系統檢查點scn增加了1。

控制檔案中的資料檔案檢查點scn和資料檔案的檔案頭中的啟動scn也都各自增加了1。

控制檔案中的資料檔案終止scn，變為NULL.

C.對系統觸發檢查點

SQL> alter system checkpoint;

　　System altered.

SQL> select a.checkpoint_change# system_scn, c.checkpoint_change# start_scn,

2 b.checkpoint_change# datafile_scn, decode(b.last_change#,NULL,'null',b.last_change#) stop_scn

3 from v$database a,

4 (select checkpoint_change#, last_change# from v$datafile where rownum =1 ) b,

5 (select checkpoint_change# from v$datafile_header where rownum=1) c;

SYSTEM_SCN START_SCN DATAFILE_SCN STOP_SCN

------------------- ------------------- ------------------- ----------------------------------------

2696048204212 2696048204212 2696048204212 null

系統檢查點scn 發生變化，增加不止1, 這與檢查點產生機制有關。

D 異常關閉啟動！沒有將Start SCN同步給Stop SCN,造成不一致.需要Instance Recovery

SQL> shutdown abort

SQL> startup mount

Database mounted.

SQL> select a.checkpoint_change# system_scn, c.checkpoint_change# start_scn,

2 b.checkpoint_change# datafile_scn, decode(b.last_change#,NULL,'null',b.last_change#) stop_scn

3 from v$database a,

4 (select checkpoint_change#, last_change# from v$datafile where rownum =1 ) b,

5 (select checkpoint_change# from v$datafile_header where rownum=1) c;

SYSTEM_SCN START_SCN DATAFILE_SCN STOP_SCN

------------------- ------------------- ------------------- ----------------------------------------

2696048204212 2696048204212 2696048204212 null

按理說在資料檔案啟動之前 End SCN的值不應為NULL,但這裡查出卻為NULL ,之前的理解是有誤的, 在Shutdown Abort後, Stop SCN仍為NULL. (異常關閉後的Start Mount,在開啟之前要做Instance Recovery)

SQL> alter database open;

Database altered.

Vi alert.log

alter database open

Mon Feb 1 14:27:05 2010

Beginning crash recovery of 1 threads

Mon Feb 1 14:27:05 2010

Started first pass scan

Mon Feb 1 14:27:05 2010

Completed first pass scan

61 redo blocks read, 30 data blocks need recovery

Mon Feb 1 14:27:05 2010

Started recovery at

Thread 1: logseq 71, block 7466, scn 0.0

Recovery of Online Redo Log: Thread 1 Group 1 Seq 71 Reading mem 0

Mem# 0 errs 0: /opt/oracle/oradata/mydb/redo01.log

Mon Feb 1 14:27:05 2010

Completed redo application

Mon Feb 1 14:27:05 2010

Ended recovery at

Thread 1: logseq 71, block 7527, scn 627.3103729640

30 data blocks read, 30 data blocks written, 61 redo blocks read

Crash recovery completed successfully

完成線上日誌應用

SQL> select a.checkpoint_change# system_scn, c.checkpoint_change# start_scn, scn,

b.checkpoint_change# datafile_scn, decode(b.last_change#,NULL,'null',b.last_change#) stop_scnp_scn

3 from v$database a,

4 (select checkpoint_change#, last_change# from v$datafile where rownum =1 ) b,

5 (select checkpoint_change# from v$datafile_header where rownum=1) c;

SYSTEM_SCN START_SCN DATAFILE_SCN STOP_SCN

------------------- ------------------- ------------------- ----------------------------------------

2696048224234 2696048224234 2696048224234 null

6 小結

1、系統正常關閉：

　　1)system checkpoint scn = datafile checkpoint scn = start scn，不需要介質恢復

　　2)stop scn is not null = start SCN,不需要例項恢復

2、系統異常關閉：

　　1)system checkpoint scn = datafile checkpoint scn = start scn，不需要介質恢復

　　2)stop scn is null,需要例項恢復

3、舊資料檔案

　　會使得：system checkpoint scn = datafile checkpoint scn > start scn，stop scn is null/ is not null

　　1)system checkpoint scn = datafile checkpoint scn > start scn

需要介質恢復成system checkpoint scn = datafile checkpoint scn = start scn

2)stop scn is null,需要例項恢復，is not null 不需要例項恢復

4、備份控制檔案

　　會使得：system checkpoint scn = datafile checkpoint scn <= start scn(當資料檔案為舊且和舊控制檔案為同一版本的時候相等，如果資料檔案是當前的資料檔案則是小於)，stop scn notnull/null

　　1)system checkpoint scn = datafile checkpoint scn <= start scn，需要使用using backup controlfile介質恢復成system scn = datafile scn = start scn = current log scn(當前日誌最大SCN)

2)為保證上一次恢復沒有用到log日誌不被使用，必須在恢復完成後用resetlogs開啟資料庫

5、以noresetlogs方式重建控制檔案

　　在以這種方式重建控制檔案時，控制檔案中的datafile checkpoint scn來自於Online logs中的Current log頭，因此

　　current log scn = system checkpoint scn = datafile scn >= start scn(如果資料檔案為備份而來則會大於start SCN，如果是當前的則為相等於start SCN), stop scn not null/null

　　1)current log scn = system checkpoint scn = datafile checkpoint scn >= start scn，因此需要介質恢復成system checkpoint scn = datafile scn = start scn = redolog scn(當前日誌最大SCN)

2)stopscn is not null 不需要例項恢復

6、以resetlogs方式重建控制檔案

　　控制檔案中datafile checkpoint scn 來自各資料檔案頭(start scn),而且system checkpoint scn會歸為0

　　system checkpoint scn < datafile checkpoint scn = start scn,stop scn not null/null

1)system checkpoint scn < datafile checkpoint scn = start scn，需要使用using backup controlfile介質恢復成system checkpoint scn = datafile checkpoint scn = start scn(當前日誌最大SCN),stop scn not null

2) stopscn is not null 不需要例項恢復,而且因為SCN已經為redolog scn，log已經不能使用，必須用resetlogs方式開啟資料庫

7 問題:

7.1 資料庫啟動過程的兩個比較.

v$datafile_header.checkpoint_count VS 對應控制檔案中的ckpt計數器(v$datafile.) 在哪個檢視 ?

7.2 哪些情況下SCN會發生變化? 這幾個SCN如何變化?

7.3 如何檢視 REDO SCN?

7.4 Block SCN 如何檢視?

7.5 Checkpoint的觸發機制?

下面這些操作將會觸發checkpoint事件：

1) 日誌切換，透過ALTER SYSTEM SWITCH LOGFILE。(之前的資料說這裡，發出的應是增量檢查點？是的,日誌切換隻能產生增量檢查點)

2) DBA發出checkpoint命令，透過ALTER SYSTEM checkpoint。

3) 對資料檔案進行熱備時，針對該資料檔案的checkpoint也會進行，ALTER TABLESPACE TS_NAME BEGIN BACKUP/END BACKUP。

4) 當執行ALTER TABLESPACE/DATAFILE READ ONLY的時候。

5) SHUTDOWN命令發出時。

Oracle SCN相關問題學習與測試

相關文章