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 PM
SQL>select current_scn from v$database;
CURRENT_SCN
-----------
1819065SCN在數據庫中是無處不在的，常見的控制文件、數據文件頭部、日誌文件等都記錄有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通過控制文件進行了以下驗證：
檢查數據文件頭部所記錄的Start SCN 和控制文件中所記錄的System Checkpoint SCN 是否一致,若不同則需要進行介質恢復
檢查數據文件頭部所記錄的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 immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 459304960 bytes
Fixed Size 2214336 bytes
Variable Size 289408576 bytes
Database Buffers 159383552 bytes
Redo Buffers 8298496 bytes
Database mounted.
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
1822573
SQL> 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 1822573
SQL> 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 1822573
SQL> 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 abort ORACLE instance shut down. SQL> startup mount ORACLE instance started. Total System Global Area 459304960 bytes Fixed Size 2214336 bytes Variable Size 289408576 bytes Database Buffers 159383552 bytes Redo Buffers 8298496 bytes Database 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.log Sun Jul 07 00:10:07 2013 alter database open Beginning crash recovery of 1 threads parallel recovery started with 3 processes Started redo scan Completed redo scan read 192 KB redo, 87 data blocks need recovery Started redo application at Thread 1: logseq 37, block 533 Recovery 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.817343463 Completed redo application of 0.15MB Completed crash recovery at Thread 1: logseq 37, block 918, scn 1843004 87 data blocks read, 87 data blocks written, 192 redo k-bytes read Sun Jul 07 00:10:13 2013 Thread 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.817343473 Successful open of redo thread 1 Sun Jul 07 00:10:14 2013 SMON: enabling cache recovery Successfully onlined Undo Tablespace 2. Verifying file header compatibility for 11g tablespace encryption.. Verifying 11g file header compatibility for tablespace encryption completed SMON: enabling tx recovery Database Characterset is AL32UTF8 No Resource Manager plan active Sun Jul 07 00:10:17 2013 replication_dependency_tracking turned off (no async multimaster replication found) Starting background process QMNC Sun Jul 07 00:10:21 2013 QMNC started with pid=28, OS id=7140 Sun Jul 07 00:10:31 2013 Completed: alter database open