在理解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
最後，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、中又增加了一些很實用的功能——資料庫閃回、資料庫負載重現等。