Oracle SCN機制詳細解讀

深入剖析 - Oracle SCN機制詳細解讀

https://mp.weixin.qq.com/s?__biz=MjM5MDAxOTk2MQ==&mid=2650276971&idx=1&sn=b5fb89b351d5b5bedd6353ff9c0b2157&chksm=be479c7d8930156bf73bd87f0bac869029f7341b3fdb4ed26a838b4e401c811116669acd5499&mpshare=1&scene=24&srcid=0927zxmXBLuBo3yxm7qsFYOy#rd

http://blog.chinaunix.net/uid-20274021-id-1969571.html

SCN即系統改變號（System Change Number），是在某個時間點定義資料庫已提交版本的時間戳標記。 Oracle為每個已提交的事務分配一個唯一的SCN。 SCN的值是對資料庫進行更改的邏輯時間點。 Oracle使用此編號記錄對資料庫所做的更改。 在資料庫中，SCN也可以說是無處不在，資料檔案頭，控制檔案，資料塊頭，日誌檔案等等都標記著SCN。也正是這樣，資料庫的一致性維護和SCN密切相關。不管是資料的備份，恢復都是離不開SCN的。

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

第一步：事務開始；

第二步：在buffer cache中找到需要的資料塊，如果沒找到，從資料檔案中載入buffer cache中；

第三步：事務修改buffer cache的資料塊，該資料被標識為“髒資料”，並被寫入log buffer中；

第四步：事務提交，LGWR程式將log buffer中的“髒資料”的日誌條目寫入redo log file中；

第五步：當發生checkpoint，CKPT程式更新所有資料檔案的檔案頭中的資訊，DBWn程式則負責將Buffer Cache中的髒資料

寫入到資料檔案中。

經過上述5個步驟，事務中的資料變化最終被寫入到資料檔案中。但是，一旦在上述中間環節資料庫意外當機了，在重新啟 動時

如何知道哪些資料已經寫入資料檔案、哪些沒有寫呢？（同樣，在DG、streams中也存在

類似疑問：redolog中哪些是上一次同步已經複製過的資料、哪些沒有）

SCN機制就能比較完善的解決上述問題。 SCN是一個數字，確切的說是一個只會增加、不會減少的數字。正是它這種只會增

加的特性確保了 Oracle知道哪些應該被恢復、哪些應該被複制。

首先這裡我們先介紹四個SCN概念。

1、系統檢查點scn (System Checkpoint SCN)

當一個checkpoint檢查點動作完成後，Oracle就把系統檢查點的SCN儲存到 控制檔案中。

select checkpoint_change# from v$database;

2，資料檔案檢查點scn (Datafile Checkpoint SCN)

當一個checkpoint動作完成後，Oracle就把每個資料檔案的Datafile Checkpoint SCN 單獨存放在控制檔案中。

select name,checkpoint_change# from v$datafile;

3，啟動scn (Start SCN)

Oracle把這個檢查點的scn 儲存在每個資料檔案的檔案頭中，這個值稱為啟動scn，這個SCN用於用於在資料庫例項啟動時，檢查是否需要執行資料庫恢復media recovery。

select name,checkpoint_change# from v$datafile_header;

4、終止scn (Stop SCN)

每個資料檔案的終止scn都 儲存在控制檔案中。這個SCN號用於檢查資料庫啟動過程是否需要做instance recovery。

select name,last_change# from v$datafile;

5.media recovery和instance recovery

1).media recovery是需要利用以前的備份來進行恢復的，而INSTANCE RECOVERY是不需要的。

2).media recovery通常發生在資料庫的資料檔案之類發生損壞，需要利用以前的備份來進行的恢復，需要人工處理。

3).instance recovery則是發生在例項不正常關閉情況下的恢復，是INSTANCE自己來的，不需要人工干預的。

6、在資料庫執行期間的scn值

1).在資料庫開啟並執行之後，控制檔案中的 系統檢查點、控制檔案中的 資料檔案檢查點scn和每個資料檔案頭中的 啟動scn都是相同的。控制檔案中的每個資料檔案的 終止scn都為null.

2).在安全關閉資料庫的過程中，系統會執行一個檢查點動作，這時所有資料檔案的 終止scn都會設定成資料檔案頭中的那個 啟動scn的值。

3).在資料庫重新啟動的時候，Oracle將檔案頭中的那個 啟動scn與 資料檔案檢查點scn進行比較，如果這兩個值相互匹配，oracle接下來還要比較資料檔案頭中的 啟動scn和控制檔案中資料檔案的 終止scn。如果這兩個值也一致，就意味著所有資料塊多已經提交，所有對資料庫的修改都沒有在關閉資料庫的過程中丟失，因此這次啟動資料庫的過程也不需要任何恢復操作，此時資料庫就可以開啟了。當所有的資料庫都開啟之後，儲存在控制檔案中的資料檔案 終止scn的值再次被更改為null，這表示資料檔案已經開啟並能夠正常使用了。   

7.SCN與資料庫啟動

在資料庫啟動過程中，當 System Checkpoint SCN、Datafile Checkpoint SCN和Start SCN都相同時，資料庫可以正常啟動，不需要做media recovery。三者當中有一個不同時，則需要做media recovery.如果在啟動的過程中， End SCN為NULL，則需要做instance recovery。Oracle在啟動過程中首先檢查是否需要media recovery，然後再檢查是否需要instance recovery。

8.SCN與資料庫關閉

如果資料庫的正常關閉的話，將 會觸發一個checkpoint， 同時將資料檔案的 END SCN設定為相應資料檔案的 Start SCN。當資料庫啟動時，發現它們是一致的，則不需要做instance recovery。在資料庫正常啟動後，ORACLE會將END SCN設定為NULL.如果資料庫異常關閉的話，則END SCN將為NULL。

9.恢復資料庫時什麼時候需要using backup controlfile

資料檔案檢查點scn(Datafile Checkpoint SCN)

select checkpoint_change# from v$datafile;

啟動scn(Start SCN)

select checkpoint_change# from v$datafile_header;

如果查詢結果 資料檔案檢查點scn >= 啟動scn,則不需要使用using backup controlfile；

如果查詢結果 資料檔案檢查點scn < 啟動scn,則需要使用using backup controlfile；