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；