SCN（System Chang Number）作為oracle中的一個重要機制在數據恢復Data GuardStreams復制RAC節點間的同步等各個功能中起著重要作用理解SCN的運作機制可以幫助你更加深入地了解上述功能
在理解SCN之前我們先看下oracle事務中的數據變化是如何寫入數據文件的
事務開始
在buffer cache中找到需要的數據塊如果沒有找到則從數據文件中載入buffer cache中
事務修改buffer cache的數據塊該數據被標識為髒數據並被寫入log buffer中
事務提交LGWR進程將log buffer中的髒數據寫入redo log file中
當發生checkpointCKPT進程更新所有數據文件的文件頭中的信息DBWn進程則負責將Buffer Cache中的髒數據寫入到數據文件中
經過上述個步驟事務中的數據變化最終被寫入到數據文件中但是一旦在上述中間環節時數據庫意外宕機了在重新啟動時如何知道哪些數據已經寫入數據文件哪些沒有寫呢（同樣在DGstreams中也存在類似疑問redo log中哪些是上一次同步已經復制過的數據哪些沒有）？SCN機制就能比較完善的解決上述問題
SCN是一個數字確切的說是一個只會增加不會減少的數字正是它這種只會增加的特性確保了Oracle知道哪些應該被恢復哪些應該被復制
總共有中SCN系統檢查點（System Checkpoint）SCN數據文件檢查點（Datafile Checkpoint）SCN結束SCN（Stop SCN）開始SCN（Start SCN）其中其面中SCN存在於控制文件中最後一種則存在於數據文件的文件頭中
在控制文件中System Checkpoint SCN是針對整個數據庫全局的因而之存在一個而Datafile Checkpoint SCN和Stop SCN是針對每個數據文件的因而一個數據文件就對應在控制文件中存在一份Datafile Checkpoint SCN和Stop SCN在數據庫正常運行期間Stop SCN（通過視圖v$datafile的字段last_change#可以查詢）是一個無窮大的數字或者說是NULL
在一個事務提交後（上述第四個步驟）會在redo log中存在一條redo記錄同時系統為其提供一個最新的SCN（通過函數dbms_flashbackget_system_change_number可以知道當前的最新SCN）記錄在該條記錄中如果該條記錄是在redo log被清空（日志滿做切換時或發生checkpoint時所有變化日志已經被寫入數據文件中）則其SCN被記錄為redo log的low SCN以後在日志再次被清空前寫入的redo記錄中SCN則成為Next SCN
當日志切換或發生checkpoint（上述第五個步驟）時從Low SCN到Next SCN之間的所有redo記錄的數據就被DBWn進程寫入數據文件中而CKPT進程則將所有數據文件（無論redo log中的數據是否影響到該數據文件）的文件頭上記錄的Start SCN（通過視圖v$datafile_header的字段checkpoint_change#可以查詢）更新為Next SCN同時將控制文件中的System Checkpoint SCN（通過視圖v$database的字段checkpoint_change#可以查詢）每個數據文件對應的Datafile Checkpoint（通過視圖v$datafile的字段checkpoint_change#可以查詢）也更新為Next SCN但是如果該數據文件所在的表空間被設置為readonly時數據文件的Start SCN和控制文件中Datafile Checkpoint SCN都不會被更新
那系統是如何產生一個最新的SCN的？實際上這個數字是由當時的timestamp轉換過來的每當需要產生一個最新的SCN到redo記錄時系統獲取當時的timestamp將其轉換為數字作為SCN我們可以通過函數SCN_TO_TIMESTAMP（g以後）將其轉換回timestamp
SQL> select dbms_flashbackget_system_change_number SCN_TO_TIMESTAMP(dbms_flashbackget_system_change_number) from dual;
GET_SYSTEM_CHANGE_NUMBER
SCN_TO_TIMESTAMP(DBMS_FLASHBACKGET_SYSTEM_CHANGE_NUMBER)
AUG PM
也可以用函數timestamp_to_scn將一個timestamp轉換為SCN
SQL> select timestamp_to_scn(SYSTIMESTAMP) as scn from dual; SCNSQL> select timestamp_to_scn(SYSTIMESTAMP) as scn from dual;
SCN
最後SCN除了作為反映事務數據變化並保持同步外它還起到系統的心跳作用——每隔秒左右系統會刷新一次系統SCN
下面在簡單介紹一下SCN如何在數據庫恢復中起作用
數據庫在正常關閉（shutdown immediate/normal）時會先做一次checkpoint將log file中的數據寫入數據文件中將控制文件數據文件中的SCN（包括控制文件中的Stop SCN）都更新為最新的SCN
數據庫異常/意外關閉不會或者只更新部分Stop SCN
當數據庫啟動時Oracle先檢查控制文件中的每個Datafile Checkpoint SCN和數據文件中的Start SCN是否相同再檢查每個Datafile Checkpoint SCN和Stop SCN是否相同如果發現有不同就從Redo Log中找到丟失的SCN重新寫入數據文件中進行恢復具體的數據恢復過程這裡就不再贅述
SCN作為Oracle中的一個重要機制在多個重要功能中起著控制器的作用了解SCN的產生和實現方式幫助DBA理解和處理恢復DGStreams復制的問題
最後提一句利用SCN機制在Oraclegg中又增加了一些很實用的功能——數據庫閃回數據庫負載重現等
From:http://tw.wingwit.com/Article/program/Oracle/201311/17975.html
