Oracle體繫結構之SCN、執行個體恢複

SCN：System Change Number

SCN是Oracle資料庫的一個邏輯的內部時間戳記，用以標識資料庫在某個確切時刻提交的版本。在事務提交或復原時，它被賦予一個惟一的標識事務的SCN，用來保證資料庫的一致性。

SQL> select dbms_flashback.get_system_change_number, SCN_TO_TIMESTAMP(dbms_flashback.get_system_change_number) from dual;GET_SYSTEM_CHANGE_NUMBER SCN_TO_TIMESTAMP(DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER)------------------------ -------------------------------------------------------                 1819076 06-JUL-13 11.40.12.000000000 PMSQL>select  current_scn from v$database;CURRENT_SCN-----------    1819065

SCN在資料庫中是無處不在的，常見的控制檔案、資料檔案頭部、記錄檔等都記錄有SCN。

控制檔案中

• 系統檢查點SCN(System Checkpoint SCN)

SQL> select checkpoint_change# from v$database;CHECKPOINT_CHANGE#------------------           1809219

• 檔案檢查點SCN(Datafile Checkpoint SCN)
  

• 檔案結束SCN(Stop SCN)

SQL> select name,checkpoint_change#,last_change# from v$datafile;NAME                                          CHECKPOINT_CHANGE# LAST_CHANGE#--------------------------------------------- ------------------ ------------+DATA/orcl/datafile/system.256.817343229                 1809219+DATA/orcl/datafile/sysaux.257.817343231                 1809219+DATA/orcl/datafile/undotbs1.258.817343231               1809219+DATA/orcl/datafile/users.259.817343231                  1809219+DATA/orcl/datafile/example.265.817343543                1809219

資料檔案頭部

• 開始SCN(Start SCN)

SQL> select checkpoint_change# from v$datafile_header;CHECKPOINT_CHANGE#------------------           1809219           1809219           1809219           1809219           1809219

記錄檔中

• FIRST SCN：redo log file中第一條日誌的SCN

• NEXT SCN：redo log file中最後一條日誌的SCN(即下一個redo log file的第一條日誌的SCN)

通常,只有當前的重做記錄檔組寫滿後才發生日誌切換,但是可以通過設定參數ARCHIVE_LOG_TARGET控制日誌切換的時間間隔,在必要時也可以採用手工強制進行日誌切換.

一組redo log file寫滿後，會自動切換到下一組redo log file。上一組redo log的High SCN就是下一組redo log的Low SCN,且對於Current記錄檔的High SCN為無窮大(FFFFFFFF)。

SQL> select group#,sequence#,status,first_change#,next_change# from v$log;    GROUP#  SEQUENCE# STATUS           FIRST_CHANGE#       NEXT_CHANGE#---------- ---------- ---------------- ------------- ------------------         1         34 INACTIVE               1746572            1770739         2         35 INACTIVE               1770739            1808596         3         36 CURRENT                1808596    281474976710655

執行個體崩潰恢複：

在open資料庫時,Oracle通過控制檔案進行了以下驗證：

1. 檢查資料檔案頭部所記錄的Start SCN 和控制檔案中所記錄的System Checkpoint SCN 是否一致,若不同則需要進行介質恢複

2. 檢查資料檔案頭部所記錄的Start SCN 和控制檔案中記錄的Stop SCN是否也一致,若不同則需要進行執行個體恢複.

如果兩個都一致了,說明所有已被修改的資料區塊已經寫入到了資料檔案中,才可以正常open,

當資料庫open並正常運行期間,系統SCN、檔案SCN和資料檔案頭部的開始SCN都是一致的,且(大於或)等於ACTIVE/CURRENT記錄檔的最小FIRST SCN,但檔案結束SCN為NULL(無窮大);

當資料庫正常關閉時,Oracle通過完全檢查點將buffer cache中的所有緩衝寫到磁碟上,同時根據關閉資料庫的時間點更新控制檔案中的系統SCN、檔案SCN、結束SCN和資料檔案頭部中的開始SCN,且SCN都是一致的,且LRBA指標指向on disk RBA,否則需要前滾;

當資料庫非正常關閉(崩潰/掉電)後啟動執行個體時,Oracle將檢測到控制檔案中的系統SCN、檔案SCN和資料檔案頭部的開始SCN都是一致的,但是結束SCN為NULL,則在需要參與執行個體崩潰恢複的redo log file中根據控制檔案中記錄的LRBA地址(前滾起點)和on disk RBA(前滾終點)地址找出相應的日誌項進行執行個體崩潰恢複,最終才可將資料庫open.

執行個體恢複的詳細過程：

• 前滾階段(前滾靠redo,又叫緩衝區恢複cache recovery,即負責恢複已經在記憶體中但還沒有寫入資料檔案中的內容)

     Oracle是按照redo log file的記錄來前滾的(不管有沒有commit),所以前滾完成後,data file中可能會有沒有提交的資料(所以需要後面的回退過程).

     另外,由於undo的產生也是要記錄redo log的,所以還會按照redo重建後面回退時需要的undo資訊.

• 資料庫open階段

     前滾完畢後,資料庫中所有已被修改的資料區塊已經寫入到了資料檔案中才可以正常open

• 復原階段(復原靠undo,又叫事務恢複transaction recoery,即負責回退執行個體崩潰前沒有提交的事務)

正常關閉資料庫時：

系統SCN、檔案SCN、結束SCN和資料檔案頭部中的開始SCN都是相等的，且(大於或)等於ACTIVE/CURRENT記錄檔中的最小FIRST SCN

SQL> shutdown immediateDatabase closed.Database dismounted.ORACLE instance shut down.SQL> startup mountORACLE instance started.Total System Global Area  459304960 bytesFixed Size                  2214336 bytesVariable Size             289408576 bytesDatabase Buffers          159383552 bytesRedo Buffers                8298496 bytesDatabase mounted.SQL>  select checkpoint_change# from v$database;CHECKPOINT_CHANGE#------------------           1822573SQL>  select name,checkpoint_change#,last_change# from v$datafile;NAME                                          CHECKPOINT_CHANGE# LAST_CHANGE#--------------------------------------------- ------------------ ------------+DATA/orcl/datafile/system.256.817343229                 1822573      1822573+DATA/orcl/datafile/sysaux.257.817343231                 1822573      1822573+DATA/orcl/datafile/undotbs1.258.817343231               1822573      1822573+DATA/orcl/datafile/users.259.817343231                  1822573      1822573+DATA/orcl/datafile/example.265.817343543                1822573      1822573SQL> select name,checkpoint_change# from v$datafile_header;NAME                                          CHECKPOINT_CHANGE#--------------------------------------------- ------------------+DATA/orcl/datafile/system.256.817343229                 1822573+DATA/orcl/datafile/sysaux.257.817343231                 1822573+DATA/orcl/datafile/undotbs1.258.817343231               1822573+DATA/orcl/datafile/users.259.817343231                  1822573+DATA/orcl/datafile/example.265.817343543                1822573SQL> select group#,sequence#,status,first_change#,next_change# from v$log;    GROUP#  SEQUENCE# STATUS           FIRST_CHANGE#       NEXT_CHANGE#---------- ---------- ---------------- ------------- ------------------         1         37 CURRENT                1822207    281474976710655         3         36 INACTIVE               1808596            1822207         2         35 INACTIVE               1770739            1808596

正常open資料庫時：

檔案結束SCN為NULL(無窮大)

SQL> alter database open;Database altered.SQL> select name,checkpoint_change#,last_change# from v$datafile;NAME                                          CHECKPOINT_CHANGE# LAST_CHANGE#--------------------------------------------- ------------------ ------------+DATA/orcl/datafile/system.256.817343229                 1822576+DATA/orcl/datafile/sysaux.257.817343231                 1822576+DATA/orcl/datafile/undotbs1.258.817343231               1822576+DATA/orcl/datafile/users.259.817343231                  1822576+DATA/orcl/datafile/example.265.817343543                1822576

異常關機執行個體崩潰）時：

檔案結束SCN仍為NULL(無窮大)

SQL> shutdown abortORACLE instance shut down.SQL> startup mountORACLE instance started.Total System Global Area  459304960 bytesFixed Size                  2214336 bytesVariable Size             289408576 bytesDatabase Buffers          159383552 bytesRedo Buffers                8298496 bytesDatabase mounted.SQL> select name,checkpoint_change#,last_change# from v$datafile;NAME                                          CHECKPOINT_CHANGE# LAST_CHANGE#--------------------------------------------- ------------------ ------------+DATA/orcl/datafile/system.256.817343229                 1822576+DATA/orcl/datafile/sysaux.257.817343231                 1822576+DATA/orcl/datafile/undotbs1.258.817343231               1822576+DATA/orcl/datafile/users.259.817343231                  1822576+DATA/orcl/datafile/example.265.817343543                1822576

啟動執行個體將進行執行個體恢複：

SQL> alter database open;Database altered.$ tailf /u01/app/oracle/diag/rdbms/orcl/orcl/trace/alert_orcl.logSun Jul 07 00:10:07 2013alter database openBeginning crash recovery of 1 threads parallel recovery started with 3 processesStarted redo scanCompleted redo scan read 192 KB redo, 87 data blocks need recoveryStarted redo application at Thread 1: logseq 37, block 533Recovery of Online Redo Log: Thread 1 Group 1 Seq 37 Reading mem 0  Mem# 0: +DATA/orcl/onlinelog/group_1.261.817343457  Mem# 1: +FRA/orcl/onlinelog/group_1.257.817343463Completed redo application of 0.15MBCompleted crash recovery at Thread 1: logseq 37, block 918, scn 1843004 87 data blocks read, 87 data blocks written, 192 redo k-bytes readSun Jul 07 00:10:13 2013Thread 1 advanced to log sequence 38 (thread open)Thread 1 opened at log sequence 38  Current log# 2 seq# 38 mem# 0: +DATA/orcl/onlinelog/group_2.262.817343467  Current log# 2 seq# 38 mem# 1: +FRA/orcl/onlinelog/group_2.258.817343473Successful open of redo thread 1Sun Jul 07 00:10:14 2013SMON: enabling cache recoverySuccessfully onlined Undo Tablespace 2.Verifying file header compatibility for 11g tablespace encryption..Verifying 11g file header compatibility for tablespace encryption completedSMON: enabling tx recoveryDatabase Characterset is AL32UTF8No Resource Manager plan activeSun Jul 07 00:10:17 2013replication_dependency_tracking turned off (no async multimaster replication found)Starting background process QMNCSun Jul 07 00:10:21 2013QMNC started with pid=28, OS id=7140Sun Jul 07 00:10:31 2013Completed: alter database open

本文出自 “ゞ煙花っ笑” 部落格，請務必保留此出處http://vnimos.blog.51cto.com/2014866/1248546