原文轉載自：https://blog.csdn.net/JackieLiuLixi/article/details/17140659

1.SCN（System Change Number）作為oracle中的一個重要機制，在資料恢復、Data Guard、Streams複製、RAC節點間的同步等各個功能中起著重要作用。

2. 在理解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中的髒資料寫入到資料檔案中。

3. SCN是一個只會增加、不會減少的數字，它是由當時的timestamp轉換過來的。每當需要產生一個新的SCN到redo記錄時，系統獲取當時的timestamp，並將其轉換未數字作為SCN。

4. 一共有4種SCN。系統檢查點（System Checkpoint）SCN、資料檔案檢查點（Datafile Checkpoint）SCN、結束SCN（Stop SCN）以及開始SCN（Start SCN）。其中前面三個存在於控制檔案中，最後一個存在於資料檔案中。

5. 在控制檔案中，System Checkpoint SCN是針對整個資料庫全域性的，因此該SCN只有一個。而Datafile Checkpoint SCN以及Stop SCN是對於每個資料檔案的，因此存在多個。在資料庫正常執行期間，Stop SCN是一個無窮大或者說是NULL，當資料庫正常結束時，系統會自動進行一次checkpoint，保持Stop SCN與其他三個SCN保持一致（即都為最新的Next SCN）。但是如果是宕機等異常情況，則Stop SCN與Start SCN不一致，這樣就可以判斷資料庫是否需要修復。

6. 在一個事務提交後（上述第四個步驟）會在redo log中存在一條redo記錄，同時，系統為其提供一個最新的SCN記錄在該條記錄中，如果該條記錄再redo log被清空（日誌滿做切換時或發生checkpoint時，所有變化日誌已經被寫入資料檔案中），則其SCN被記錄為redo log的low SCN，以後在日誌再次被清空前寫入的redo記錄中的SCN則成為Next SCN。

7. 當日志切換或者發生checkpoint（上述第五個步驟）時，從Low SCN到Next SCN之間所有redo記錄的資料就被DBWn程序寫入資料檔案中，而CKPT程序則將所有資料檔案（無論redo log中的資料是否影響該資料檔案）的檔案頭上記錄的Start SCN更新為Next SCN，同時將控制檔案中的System Checkpoint SCN、每個資料檔案對應的Datafile Checkpoint更新為Next SCN。但是如果該資料檔案被設定成了read-only時，資料檔案的Start SCN和控制檔案中Datafile Checkpoint SCN都不更新。

8. 當資料庫啟動時，Oracle先檢查控制檔案中的每個Datafile Checkpoint SCN和資料檔案中的Start SCN是否相同，再檢查每個Datafile Checkpoint SCN和Stop SCN是否相同。如果發現不同，就從Redo log中找到丟失的SCN，重新寫入資料檔案中進行恢復。

9.    如果開啟資料庫時發現 system scn>datafile scn，那麼以為著使用舊的備份資料檔案，也就是需要介質恢復 
　　如果是 system scn<datafile scn，及控制檔案 scn 是舊的，代表使用了老的控制檔案，需要 recover using backup controlfile 進行恢復。