Oracle重要機制：SCN機制解析

SCN（System Chang Number）作為oracle中的一個重要機制，在資料恢複、Data Guard、Streams複製、RAC節點間的同步等各個功能中起著重要作用。理解SCN的運作機制，可以協助你更加深入地瞭解上述功能。

    在理解SCN之前，我們先看下oracle事務中的資料變化是如何寫入資料檔案的：

    1、事務開始；

    2、在buffer cache中找到需要的資料區塊，如果沒有找到，則從資料檔案中載入buffer cache中；

    3、事務修改buffer cache的資料區塊，該資料被標識為“髒資料”，並被寫入log buffer中；

    4、事務提交，LGWR進程將log buffer中的“髒資料”寫入redo log file中；

    5、當發生checkpoint，CKPT進程更新所有資料檔案的檔案頭中的資訊，DBWn進程則負責將Buffer Cache中的髒資料寫入到資料檔案中。

    經過上述5個步驟，事務中的資料變化最終被寫入到資料檔案中。但是，一旦在上述中間環節時，資料庫 意外宕機了，在重新啟動時如何知道哪些資料已經寫入資料檔案、哪些沒有寫呢（同樣，在DG、streams中也存在類似疑問：redo log中哪些是上一次同步已經複製過的資料、哪些沒有）？SCN機制就能比較完善的解決上述問題。

    SCN是一個數字，確切的說是一個只會增加、不會減少的數字。正是它這種只會增加的特性確保了Oracle 知道哪些應該被恢複、哪些應該被複製。

    總共有4中SCN：系統檢查點（System Checkpoint）SCN、資料檔案檢查點（Datafile Checkpoint）SCN、結束SCN（Stop SCN）、開始SCN（Start SCN）。其中其面3中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_flashback.get_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.但是，如果該資料檔案所在的資料表空間被設定為read-only時，資料檔案的Start SCN和控制檔案中Datafile Checkpoint SCN都不會被更新。

    那系統是如何產生一個最新的SCN的？實際上，這個數字是由當時的timestamp轉換過來的。每當需要產生一個最新的SCN到redo記錄時，系統獲 取當時的timestamp，將其轉換為數字作為SCN.我們可以通過函數SCN_TO_TIMESTAMP（10g以後）將其轉換回 timestamp：

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) ---------------------------------------------------------------------------               2877076756 17-AUG-07 02.15.26.000000000 PM

    也可以用函數timestamp_to_scn將一個timestamp轉換為SCN：

 

SQL> select timestamp_to_scn(SYSTIMESTAMP) as scn from dual;        SCN----------2877078439 SQL> select timestamp_to_scn(SYSTIMESTAMP) as scn from dual;        SCN ---------- 2877078439

    最後，SCN除了作為反映交易資料變化並保持同步外，它還起到系統的“心跳”作用——每隔3秒左右系統會重新整理一次系統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理解和處理恢複、DG、Streams複製的問題。

    最後提一句，利用SCN機制，在Oracle10g、11g中又增加了一些很實用的功能——資料庫閃回、資料庫負載重現等。