1．SCN 的定義

SCN（System Change Number ），也就是通常所說(shuō)的系統(tǒng)改變號(hào)，是數(shù)據(jù)庫(kù)中非常重要的 一個(gè)數(shù)據(jù)結(jié)構(gòu)。

SCN 用以標(biāo)識(shí)數(shù)據(jù)庫(kù)在某個(gè)確切時(shí)刻提交的版本。在事務(wù)提交時(shí)，它被賦予一個(gè)惟一的 標(biāo)識(shí)事務(wù)的SCN。SCN 同時(shí)被作為 Oracle數(shù)據(jù)庫(kù)的內(nèi)部時(shí)鐘機(jī)制，可被看作邏輯時(shí)鐘，每個(gè) 數(shù)據(jù)庫(kù)都有一個(gè)全局的 SCN 生成器。

作為數(shù)據(jù)庫(kù)內(nèi)部的邏輯時(shí)鐘，數(shù)據(jù)庫(kù)事務(wù)依 SCN 而排序，Oracle 也依據(jù) SCN 來(lái)實(shí)現(xiàn)一致性讀 （Read Consistency ）等重要數(shù)據(jù)庫(kù)功能。另外對(duì)于分布式事務(wù)（Distributed Transactions）， SCN 也極為重要，這里不作更多介紹。

SCN 在數(shù)據(jù)庫(kù)中是惟一的，并隨時(shí)間而增加，但是可能并不連貫。除非重建數(shù)據(jù)庫(kù)，SCN 的值永遠(yuǎn)不會(huì)被重置為 0。

一直以來(lái)，對(duì)于 SCN 有很多爭(zhēng)議，很多人認(rèn)為 SCN 是指 System Commit Number ，而通常 SCN 在提交時(shí)才變化，所以很多時(shí)候，這兩個(gè)名詞經(jīng)常在文檔中反復(fù)出現(xiàn)。即使在Oracle 的 官方文檔中，SCN 也常以 System Change/Commit Number 兩種形式出現(xiàn)。 到底是哪個(gè)詞其實(shí)不是最重要的，重要的是需要知道 SCN 是Oracle內(nèi)部的時(shí)鐘機(jī)制， Oracle通過(guò)SCN 來(lái)維護(hù)數(shù)據(jù)庫(kù)的一致性，并通過(guò) SCN 實(shí)施Oracle至關(guān)重要的恢復(fù)機(jī)制。 SCN 在數(shù)據(jù)庫(kù)中是無(wú)處不在的，常見(jiàn)的事務(wù)表、控制文件、數(shù)據(jù)文件頭、日志文件、數(shù) 據(jù)塊頭等都記錄有 SCN 值。

冠以不同前綴，SCN 也有了不同的名稱，如檢查點(diǎn)SCN（Checkpoint SCN ）、Resetlogs SCN 等。

2．SCN 的獲取方式

可以通過(guò)如下幾種方式獲得數(shù)據(jù)庫(kù)的當(dāng)前或近似 SCN。

SQL> SELECT dbms_flashback.get_system_change_number FROM DUAL; 
GET_SYSTEM_CHANGE_NUMBER
------------------------
      6051905241299
SQL>

3．SCN 的進(jìn)一步說(shuō)明

系統(tǒng)當(dāng)前SCN 并不是在任何的數(shù)據(jù)庫(kù)操作發(fā)生時(shí)都會(huì)改變，SCN 通常在事務(wù)提交或回滾 時(shí)改變。在控制文件、數(shù)據(jù)文件頭、數(shù)據(jù)塊、日志文件頭、日志文件 change vector 中都有 SCN，但其作用各不相同。

（1）數(shù)據(jù)文件頭中包含了該數(shù)據(jù)文件的 Checkpoint SCN，表示該數(shù)據(jù)文件最近一次執(zhí)行 檢查點(diǎn)操作時(shí)的 SCN。

對(duì)于每一個(gè)數(shù)據(jù)文件都包含一個(gè)這樣的條目，記錄該文件的檢查點(diǎn) SCN 的值以及檢查點(diǎn) 發(fā)生的時(shí)間，這里的Checkpoint SCN 、Stop SCN以及 Checkpoint Cnt 都是非常重要的數(shù)據(jù) 結(jié)構(gòu).

4．檢查點(diǎn)

許多文檔把Checkpoint 描述得非常復(fù)雜，為我們正確理解檢查點(diǎn)帶來(lái)了障礙，結(jié)果現(xiàn)在 檢查點(diǎn)變成了一個(gè)非常復(fù)雜的問(wèn)題。實(shí)際上，檢查點(diǎn)只是一個(gè)數(shù)據(jù)庫(kù)事件，它存在的根本意 義在于減少崩潰恢復(fù)（Crash Recovery ）時(shí)間。

當(dāng)修改數(shù)據(jù)時(shí)，需要首先將數(shù)據(jù)讀入內(nèi)存中（Buffer Cache），修改數(shù)據(jù)的同時(shí)，Oracle 會(huì)記錄重做信息（Redo）用于恢復(fù)。因?yàn)橛辛酥刈鲂畔⒌拇嬖冢琌racle 不需要在提交時(shí)立即 將變化的數(shù)據(jù)寫回磁盤（立即寫的效率會(huì)很低），重做（Redo）的存在也正是為了在數(shù)據(jù)庫(kù)崩 潰之后，數(shù)據(jù)可以恢復(fù)。

最常見(jiàn)的情況，數(shù)據(jù)庫(kù)可能因?yàn)閿嚯姸?Crash，那么內(nèi)存中修改過(guò)的、尚未寫入文件的 數(shù)據(jù)將會(huì)丟失。在下一次數(shù)據(jù)庫(kù)啟動(dòng)之后，Oracle 可以通過(guò)重做日志（Redo）進(jìn)行事務(wù)重演 （也就是進(jìn)行前滾），將數(shù)據(jù)庫(kù)恢復(fù)到崩潰之前的狀態(tài)，然后數(shù)據(jù)庫(kù)可以打開提供使用，之后 Oracle可以將未提交的事務(wù)進(jìn)行回滾。

在這個(gè)過(guò)程中，通常大家最關(guān)心的是數(shù)據(jù)庫(kù)要經(jīng)歷多久才能打開。也就是需要讀取多少 重做日志才能完成前滾。當(dāng)然用戶希望這個(gè)時(shí)間越短越好，Oracle 也正是通過(guò)各種手段在不 斷優(yōu)化這個(gè)過(guò)程，縮短恢復(fù)時(shí)間。

檢查點(diǎn)的存在就是為了縮短這個(gè)恢復(fù)時(shí)間。

當(dāng)檢查點(diǎn)發(fā)生時(shí)（此時(shí)的SCN 被稱為Checkpoint SCN ），Oracle會(huì)通知DBWR進(jìn)程，把 修改過(guò)的數(shù)據(jù)，也就是此Checkpoint SCN之前的臟數(shù)據(jù)（Dirty Data）從Buffer Cache 寫入磁盤，當(dāng)寫入完成之后，CKPT進(jìn)程更新控制文件和數(shù)據(jù)文件頭，記錄檢查點(diǎn)信息，標(biāo) 識(shí)變更。

Checkpoint SCN 可以從數(shù)據(jù)庫(kù)中查詢得到：

SQL> select file#,NAME,CHECKPOINT_CHANGE#,to_char(CHECKPOINT_TIME,'yyyy -mm-dd hh24:mi:ss') CPT from v$datafile; 
   FILE# NAME                                       CHECKPOINT_CHANGE# CPT
---------- -------------------------------------------------------------------------------- ------------------ --------------------
     1 /u01/app/oracle/oradata/orcl/system01.dbf                       6051905239995 2016 -05-05 04:14:32
     2 /u01/app/oracle/oradata/orcl/sysaux01.dbf                       6051905239995 2016 -05-05 04:14:32
     3 /u01/app/oracle/oradata/orcl/undotbs01.dbf                      6051905239995 2016 -05-05 04:14:32
     4 /u01/app/oracle/oradata/orcl/users01.dbf                       6051905239995 2016 -05-05 04:14:32
     5 /u01/app/oracle/oradata/orcl/example01.dbf                      6051905239995 2016 -05-05 04:14:32
     6 /u01/app/oracle/oradata/orcl/DEV_odi_user.dbf                     6051905239995 2016 -05-05 04:14:32
     7 /u01/app/oracle/oradata/orcl/apex_01.dbf                       6051905239995 2016 -05-05 04:14:32
     8 /u01/app/oracle/oradata/orcl/APEX_6121090681146232.dbf                6051905239995 2016 -05-05 04:14:32
8 rows selected

在檢查點(diǎn)完成之后，此檢查點(diǎn)之前修改過(guò)的數(shù)據(jù)都已經(jīng)寫回磁盤，重做日志文件中的相 應(yīng)重做記錄對(duì)于崩潰/實(shí)例恢復(fù)不再有用。

檢查點(diǎn)的頻度對(duì)于數(shù)據(jù)庫(kù)的恢復(fù)時(shí)間具有極大的影響， 如果檢查點(diǎn)的頻率高，那么恢復(fù)時(shí)需要應(yīng)用的重做日志就相對(duì)得少，恢復(fù)時(shí)間就可以縮短。 然而，需要注意的是，數(shù)據(jù)庫(kù)內(nèi)部操作的相關(guān)性極強(qiáng)，過(guò)于頻繁的檢查點(diǎn)同樣會(huì)帶來(lái)性能問(wèn) 題，尤其是更新頻繁的數(shù)據(jù)庫(kù)。所以數(shù)據(jù)庫(kù)的優(yōu)化是一個(gè)系統(tǒng)工程，不能草率。

更進(jìn)一步可以知道，如果Oracle 可以在性能允許的情況下，使得檢查點(diǎn)的SCN 逐漸逼近 Redo的最新變更，那么最終可以獲得一個(gè)最佳平衡點(diǎn)，使得 Oracle 可以最大化的減少恢復(fù) 時(shí)間。

為了實(shí)現(xiàn)這個(gè)目標(biāo)，Oracle 在不同版本中一直在改進(jìn)檢查點(diǎn)的算法。

總結(jié)

以上就是本文關(guān)于Oracle SCN與檢查點(diǎn)詳解的全部?jī)?nèi)容，希望對(duì)大家有所幫助。感興趣的朋友可以參考：oracle 數(shù)據(jù)庫(kù)啟動(dòng)階段分析 、 Oracle EBS工具選項(xiàng)：關(guān)閉其他表單修改方法  、 oracle 虛擬專用數(shù)據(jù)庫(kù)詳細(xì)介紹   等。有什么問(wèn)題可以隨時(shí)留言，小編會(huì)及時(shí)回復(fù)大家的。