SCN可以說(shuō)是Oracle中一個(gè)很基礎(chǔ)的部分，但同時(shí)它也是一個(gè)很重要的。它是系統(tǒng)中維持?jǐn)?shù)據(jù)的一致性和順序恢復(fù)的重要標(biāo)志，是數(shù)據(jù)庫(kù)非常重要的一種數(shù)據(jù)結(jié)構(gòu)。

轉(zhuǎn)載：深入剖析 - Oracle SCN機(jī)制詳細(xì)解讀 - 知乎 (zhihu.com)https://zhuanlan.zhihu.com/p/31446957

SCN介紹

SCN即系統(tǒng)改變號(hào)（System Change Number），是在某個(gè)時(shí)間點(diǎn)定義數(shù)據(jù)庫(kù)已提交版本的時(shí)間戳標(biāo)記。 Oracle為每個(gè)已提交的事務(wù)分配一個(gè)唯一的SCN。 SCN的值是對(duì)數(shù)據(jù)庫(kù)進(jìn)行更改的邏輯時(shí)間點(diǎn)。 Oracle使用此編號(hào)記錄對(duì)數(shù)據(jù)庫(kù)所做的更改。在數(shù)據(jù)庫(kù)中，SCN也可以說(shuō)是無(wú)處不在，數(shù)據(jù)文件頭，控制文件，數(shù)據(jù)塊頭，日志文件等等都標(biāo)記著SCN。也正是這樣，數(shù)據(jù)庫(kù)的一致性維護(hù)和SCN密切相關(guān)。不管是數(shù)據(jù)的備份，恢復(fù)都是離不開SCN的。

SCN是一個(gè)6字節(jié)（48bit）的數(shù)字，其值為281,474,976,710,656（2^48），分為2個(gè)部分：

SCN_BASE是一個(gè)4字節(jié)（32bit）的數(shù)字
SCN_WRAP是一個(gè)2字節(jié)（16bit）的數(shù)字

每當(dāng)SCN_BASE達(dá)到其最大值（2^32 = 4294967296）時(shí)，SCN_WRAP增加1，SCN_BASE將被重置為0,一直持續(xù)到SCN_WRAP達(dá)到其最大值，即2^16 = 65536。

SCN?=（SCN_WRAP * 4294967296）+ SCN_BASE

SCN隨著每個(gè)事務(wù)的完成而增加。提交不會(huì)寫入數(shù)據(jù)文件，也不更新控制文件。當(dāng)發(fā)生checkpoint時(shí)，控制文件更新，SCN被寫入到控制文件。

當(dāng)前的SCN可以通過(guò)以下查詢獲得：

select dbms_flashback.get_system_change_number scn from dual;

select current_scn from v$database;

四種重要的SCN

在理解這幾種SCN之前，我們先看下oracle事務(wù)中的數(shù)據(jù)變化是如何寫入數(shù)據(jù)文件的：

第一步：事務(wù)開始；
第二步：在buffer cache中找到需要的數(shù)據(jù)塊，如果沒(méi)找到，從數(shù)據(jù)文件中載入buffer cache中；
第三步：事務(wù)修改buffer cache的數(shù)據(jù)塊，該數(shù)據(jù)被標(biāo)識(shí)為“臟數(shù)據(jù)”，并被寫入log buffer中；
第四步：事務(wù)提交，LGWR進(jìn)程將log buffer中的“臟數(shù)據(jù)”的日志條目寫入redo log file中；
第五步：當(dāng)發(fā)生checkpoint，CKPT進(jìn)程更新所有數(shù)據(jù)文件的文件頭中的信息，DBWn進(jìn)程則負(fù)責(zé)將Buffer Cache中的臟數(shù)據(jù)寫入到數(shù)據(jù)文件中。

經(jīng)過(guò)上述5個(gè)步驟，事務(wù)中的數(shù)據(jù)變化最終被寫入到數(shù)據(jù)文件中。但是，一旦在上述中間環(huán)節(jié)數(shù)據(jù)庫(kù)意外宕機(jī)了，在重新啟動(dòng)時(shí)如何知道哪些數(shù)據(jù)已經(jīng)寫入數(shù)據(jù)文件、哪些沒(méi)有寫呢？（同樣，在DG、streams中也存在類似疑問(wèn)：redolog中哪些是上一次同步已經(jīng)復(fù)制過(guò)的數(shù)據(jù)、哪些沒(méi)有）

SCN機(jī)制就能比較完善的解決上述問(wèn)題。 SCN是一個(gè)數(shù)字，確切的說(shuō)是一個(gè)只會(huì)增加、不會(huì)減少的數(shù)字。正是它這種只會(huì)增加的特性確保了 Oracle知道哪些應(yīng)該被恢復(fù)、哪些應(yīng)該被復(fù)制。

總共有4種SCN：

系統(tǒng)檢查點(diǎn)（System Checkpoint）SCN
數(shù)據(jù)文件檢查點(diǎn)（Datafile Checkpoint）SCN
結(jié)束SCN（Stop SCN）
開始SCN（Start SCN）

（1）System Checkpoint SCN

當(dāng)checkpoint完成后，ORACLE將System Checkpoint SCN號(hào)存放在控制文件中。我們可以通過(guò)下面SQL語(yǔ)句查詢：

select checkpoint_change# from v$database;

（2）Datafile Checkpoint SCN

當(dāng)checkpoint完成后，Oracle將Datafile Checkpoint SCN存放在控制文件中。我們可以通過(guò)下面SQL語(yǔ)句查詢所有數(shù)據(jù)文件的Datafile Checkpoinnt SCN。

select name,checkpoint_change# from v$datafile;

（3）Start SCN

Oracle將StartSCN存放在數(shù)據(jù)文件頭中。這個(gè)SCN用于檢查數(shù)據(jù)庫(kù)啟動(dòng)過(guò)程是否需要做media recovery。我們可以通過(guò)以下SQL語(yǔ)句查詢：

select name,checkpoint_change# from v$datafile_header;

（4）Stop SCN

ORACLE將StopSCN存放在控制文件中。這個(gè)SCN號(hào)用于檢查數(shù)據(jù)庫(kù)啟動(dòng)過(guò)程是否需要做instance recovery。我們可以通過(guò)以下SQL語(yǔ)句查詢：

select name,last_change# from v$datafile;

在數(shù)據(jù)庫(kù)正常運(yùn)行的情況下，對(duì)可讀寫的online數(shù)據(jù)文件，該SCN號(hào)為NULL。

SCN與數(shù)據(jù)庫(kù)啟動(dòng)：

在數(shù)據(jù)庫(kù)啟動(dòng)過(guò)程中，當(dāng)System Checkpoint SCN、Datafile Checkpoint SCN和Start SCN都相同時(shí)，數(shù)據(jù)庫(kù)可以正常啟動(dòng)，不需要做media recovery。三者當(dāng)中有一個(gè)不同時(shí)，則需要做media recovery.如果在啟動(dòng)的過(guò)程中，End SCN為NULL，則需要做instance recovery。Oracle在啟動(dòng)過(guò)程中首先檢查是否需要media recovery，然后再檢查是否需要instance recovery。

SCN與數(shù)據(jù)庫(kù)關(guān)閉：

如果數(shù)據(jù)庫(kù)的正常關(guān)閉的話，將會(huì)觸發(fā)一個(gè)checkpoint，同時(shí)將數(shù)據(jù)文件的END SCN設(shè)置為相應(yīng)數(shù)據(jù)文件的Start SCN。當(dāng)數(shù)據(jù)庫(kù)啟動(dòng)時(shí)，發(fā)現(xiàn)它們是一致的，則不需要做instance recovery。在數(shù)據(jù)庫(kù)正常啟動(dòng)后，ORACLE會(huì)將END SCN設(shè)置為NULL.如果數(shù)據(jù)庫(kù)異常關(guān)閉的話，則END SCN將為NULL。

Q&A

Q

為什么ORACLE在控制文件中記錄System checkpoint SCN 號(hào)的同時(shí)，還需要為每個(gè)數(shù)據(jù)文件記錄DatafileCheckpoint SCN？

A

如果有表空間read only，那么該表空間的所有datafile的start SCN和stop SCN將被凍結(jié)，這個(gè)時(shí)候就跟System Checkpoint SCN不一致，但在庫(kù)open的時(shí)候是不需要做media recovery的，如果沒(méi)有DatafileCheckpoint SCN就無(wú)法判斷這些datafile是否是最新的。

可能遇到的SCN問(wèn)題

首選我們看幾個(gè)跟SCN有關(guān)的概念：

Reasonable SCNLimit（RSL）

RSL = (當(dāng)前時(shí)間 - 1988年1月1日)*24*3600*SCN每秒最大可能增長(zhǎng)速率

也就是從1988年1月1日開始，假如SCN按最大速率增長(zhǎng)，當(dāng)天理論上的最大值。

最大增長(zhǎng)速率：在11.2.0.2之前是16384，在11.2.0.2及之后版本是32768

在11.2.0.2版本之后由_max_reasonable_scn_rate參數(shù)控制

該參數(shù)不建議修改。

SCN Headroom

Headroom（天） = (Reasonable SCN Limit -CurrentSCN)/ SCN每秒最大可能增長(zhǎng)速率/3600/24

也就是如果SCN按最大速率增長(zhǎng)，達(dá)到當(dāng)前理論最大值需要的天數(shù)。這個(gè)值可以用來(lái)判斷SCN增長(zhǎng)速率是否過(guò)快。

那么，SCN Headroom如果獲取呢？

參考MOS： Bug 13498243 -"scnhealthcheck.sql" script (文檔 ID 13498243.8)，打上該BUG的patch之后，將在$ORACLE_HOME/rdbms/admin中增加scnhealthcheck.sql文件，該文件就是用來(lái)檢查SCN是否正常。

另外還有一篇MOS文檔，專門對(duì)該腳本的輸出做了解釋。即Installing, Executing and Interpreting output from the"scnhealthcheck.sql" script (文檔 ID 1393363.1)。

執(zhí)行該腳本，結(jié)果如下：

這個(gè)結(jié)果我們?nèi)匀粺o(wú)法得到該數(shù)據(jù)庫(kù)的具體SCN Headroom，下面這個(gè)SQL是從scnhealthcheck.sql中找到的，可以直接查到SCN Headroom的值（indicator字段）。

Q&A

Q

針對(duì)上面的查詢結(jié)果，是不是意味著過(guò)1647天之后，SCN就將達(dá)到最大值？

A

不會(huì)，因?yàn)?647天之后，Current SCN會(huì)變大，Reasonable SCN Limit同樣也會(huì)變大，正常情況下，SCNHeadroon只會(huì)變大不會(huì)變小。

SCN headroom過(guò)小的問(wèn)題

如果SCN正常增長(zhǎng)，達(dá)到最大值大約可以用500年，SCN headroom的值也會(huì)隨著時(shí)間的推移慢慢變大，但是可能由于BUG、用特殊手段人為調(diào)整、dblink傳播導(dǎo)致SCN增長(zhǎng)出現(xiàn)異常。但如果出現(xiàn)SCN headroom過(guò)小，alert log會(huì)出現(xiàn)警告：Warning: The SCN headroom for this database is only NN days!

原因定位：

1. 通過(guò)下面這篇文檔里提供的腳本，該腳本類似于創(chuàng)建AWR，可以按snap_id對(duì)dba_hist_sysstat里的某個(gè)stat_name做統(tǒng)計(jì)，我們這里的Stat_name選擇calls to kcmgas。
How to Extract the Historical Values of aStatistic from the AWR Repository (文檔 ID 948272.1)

2. 通過(guò)查詢V$ARCHIVED_LOG單位時(shí)間內(nèi)scn變化

3. 通過(guò)上面兩個(gè)方式得出的結(jié)果分析，如果是非持續(xù)突發(fā)增長(zhǎng)，認(rèn)為很可能是通過(guò)dblink引起；

4. 同時(shí)比較awr報(bào)告中“callsto kcmgas” 和“user commits”，如果user commits也是高速增長(zhǎng)，很可能是自身引起；

kcmgas是Oracle分配scn的函數(shù)，在一個(gè)空庫(kù)上做測(cè)試，可以看出每分配一次scn，calls to kcmgas的統(tǒng)計(jì)增加1，所以calls to kcmgas的量可以作為scn的增長(zhǎng)量來(lái)分析。

ORA-19706: Invalid SCN錯(cuò)誤

[1376995.1]里的介紹，在2012年1月CPU或PSU里增加_external_scn_rejection_threshold_hours參數(shù)，11.2.0.2及以后的版本，默認(rèn)為1天即24小時(shí)，其他版本默認(rèn)為31天即744小時(shí)，相當(dāng)于把拒絕外部SCN連接的閾值調(diào)大了，因而更加容易引發(fā)ORA-19706錯(cuò)誤。該參數(shù)對(duì)數(shù)據(jù)庫(kù)自身產(chǎn)生的SCN遞增沒(méi)有影響。Bug 13554409 - Fix for bug13554409 [ID 13554409.8]的里對(duì)該問(wèn)題也有介紹。

ORA-19706錯(cuò)誤：最常見的就是拒絕dblink連接的時(shí)候，如A庫(kù)跟B庫(kù)通過(guò)dblink連接，A的SCN有通過(guò)人為調(diào)整增大許多，連接B庫(kù)的時(shí)候，Oracle會(huì)判斷該SCN傳播過(guò)來(lái)之后，如果會(huì)導(dǎo)致SCN headroom小于_external_scn_rejection_threshold_hours設(shè)置的閾值，則拒絕連接

相關(guān)參考：SCN、ORA-19706錯(cuò)誤和_external_scn_rejection_threshold_hours參數(shù)

如果打完2012年1月CPU或PSU后遇到ORA-19706錯(cuò)誤，對(duì)于以下這些版本的數(shù)據(jù)庫(kù)：

Oracle 10.2.0.5
Oracle 11.1.0.7
Oracle 11.2.0.2
Oracle 11.2.0.3

oracle建議給數(shù)據(jù)庫(kù)安裝2012年4月發(fā)布的PSU，并在安裝該P(yáng)SU的基礎(chǔ)上，安裝補(bǔ)丁13916709。如果是集群架構(gòu)，同時(shí)給集群軟件最新安裝PSU。參數(shù)_external_scn_rejection_threshold_hours在2012年4月（包含2012年4月）以后發(fā)布的PSU/CPU中，11.2.0.2及以后的版本，是1天即24小時(shí)，其他版本是31天即744小時(shí)。其他版本：先升級(jí)到高版本，再按照上面的方法處理。

總結(jié)

如果發(fā)現(xiàn)SCN有異常，需要及時(shí)通過(guò)上述方法來(lái)打上最新的PSU，同時(shí)盡量少用DBLINK，從系統(tǒng)設(shè)計(jì)角度來(lái)講也是不推薦這種系統(tǒng)間強(qiáng)耦合的設(shè)計(jì)。