客戶的db報scn生成頻率高，因此百度了一下，來自互聯(lián)網，供學習使用，原文url:http://www.cnblogs.com/daduxiong/archive/2010/08/19/1803764.html

了解oracle中的SCN

從接觸oracle到使用過程中，始終能看到SCN的身影，在oracle的備份恢復原理中更是如此。由此看來SCN的重要性不言而喻呀，對其有個綜合的了解能夠有對其功能有清晰地認識，在oracle中SCN的種類不一中，對SCN理解的時候常常犯暈，偶爾這樣，偶爾那樣。說白了就是把多種SCN混淆在一起了。

如果結合控制文件，數(shù)據文件，redo等文件的dump內容來了解那幾種重要的SCN，將會對其有更深的認識。

直接入題：

SCN:?System?Change?Number
SCN是順序遞增的一個數(shù)字，在Oracle?中用來標識數(shù)據庫的每一次改動，及其先后順序。SCN的最大值是0xffff.ffffffff。

Oracle對SCN的管理
單節(jié)點的instance中，SCN值存在SGA區(qū)，由system?commit?number?latch保護。任何進程要得到當前的SCN值，都要先得到這個latch。

RAC/OPS環(huán)境中
Oracle通過排隊機制(Enqueue)實現(xiàn)SCN在各并行節(jié)點之間的順序增長。具體有兩種方法：

Lamport算法：又稱面包房算法，先來先服務算法。跟很多銀行采用的排隊機制一樣。客戶到了銀行，先領取一個服務號。一旦某個窗口出現(xiàn)空閑，擁有最小服務號的客戶就可以去空閑窗口辦理業(yè)務。

Commit廣播算法：一有commit完成，最新的SCN就廣播到所有節(jié)點中。

上述兩種算法可以通過調整初始化參數(shù)max_commit_propagation_delay來切換。在多數(shù)系統(tǒng)?(除了Compaq?Tur64?Unix)中，該參數(shù)的默認值都是700厘秒(centisecond)，采用Lamport算法。如果該值小于100厘秒，Oracle就采用廣播算法，并且記錄在alert.log文件中。

幾種重要的SCN
Commit?SCN
當用戶提交commit命令后，系統(tǒng)將當前scn賦給該transaction。這些信息都反映在redo?buffer中，并馬上更新到redo?log?文件里。

Offline?SCN
除了System?tablespace以外的任何表空間，當我們執(zhí)行SQL>alter?tablespace?…?offline?normal命令時，就會觸發(fā)一個checkpoint，將內存中的dirty?buffer寫入磁盤文件中。Checkpoint完成后，數(shù)據文件頭會更新checkpoint?scn和offline?normal?scn值。其中數(shù)據庫文件頭的checkpoint?scn值可通過查詢列x$kccfe.fecps得到。

如果執(zhí)行SQL>alter?tablespace?…offline命令時采用temporary或?immediate選項，而不用normal選項時，offline?normal?scn會被設成0。這樣當數(shù)據庫重啟后通過resetlog方式打開時，該表空間就無法再改回在線狀態(tài)。

Checkpoint?SCN
當數(shù)據庫內存的臟數(shù)據塊(dirty?blocks)寫到各數(shù)據文件中時，就發(fā)生一次checkpoint。數(shù)據庫的當前checkpoint?scn值存在x$kccdi.discn中。Checkpoint?scn在數(shù)據庫恢復中起著至關重要的作用。無論你用何種辦法恢復數(shù)據庫，只有當各個數(shù)據庫文件的checkpoint?scn都相同時，數(shù)據庫才能打開。

雖然參數(shù)“_allow_resetlogs_corruption”可以在checkpoint?scn不一致時強制打開數(shù)據庫，但是這樣的數(shù)據庫在open后必須馬上作全庫的export，然后重建數(shù)據庫并import數(shù)據。

Resetlog?SCN
數(shù)據庫不完全恢復時，在指定時間點后的scn都無法再應用到數(shù)據庫中。Resetlog時的scn就被設成當前數(shù)據庫scn，redo?log也會被重新設置。

Stop?SCN
Stop?scn記錄在數(shù)據文件頭上。當數(shù)據庫處在打開狀態(tài)時，stop?scn被設成最大值0xffff.ffffffff。在數(shù)據庫正常關閉過程中，stop?scn被設置成當前系統(tǒng)的最大scn值。在數(shù)據庫打開過程中，Oracle會比較各文件的stop?scn和checkpoint?scn，如果值不一致，表明數(shù)據庫先前沒有正常關閉，需要做恢復。

High?and?Low?SCN
Oracle的Redo?log會順序紀錄數(shù)據庫的各個變化。一組redo?log文件寫滿后，會自動切換到下一組redo?log文件。則上一組redo?log的high?scn就是下一組redo?log的low?scn。
在視圖v$log_history中，sequence#代表redo?log的序列號，first_change#表示當前redo?log的low?scn，列next_change#表示當前redo?log的high?scn。

代碼 SQL> col recid format 9999 SQL> col requence# format 9999 SQL> col first_change# format 9,999,999,999,999 SQL> col next_change# format 9,999,999,999,999 SQL> select recid,sequence#,first_change#,next_change# from v$log_historywhere rownum<6;RECID SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# ----- ---------- ------------------ ------------------ 484 484 1,928,645,840,091 1,928,645,840,436 485 485 1,928,645,840,436 1,928,645,840,636 486 486 1,928,645,840,636 1,928,778,045,209 487 487 1,928,778,045,209 1,929,255,480,725 488 488 1,929,255,480,725 1,930,752,214,033

?

關于如何使用參數(shù)_allow_resetlogs_corruption，可參見文檔http://www.sidibe.net/allow_resetlog.html

點滴總結：

1，在control?file,redo?log,data?file中都存在SCN值；
2，數(shù)據庫open時，檢查control?file中記錄的SCN值與數(shù)據文件，redo?log文件是否一致，如果是，數(shù)據庫打開，否則，提示錯誤；假如數(shù)據文件SCN值小于control?file中的SCN值則提示該數(shù)據文件需要介質恢復；
3，redo?log?中存在低SCN，高SCN值兩種，當前的redo?log文件的高SCN值為無窮大；日志發(fā)生切換時，高SCN值更新為系統(tǒng)當前SCN值，新日志文件低SCN值為前日志文件高SCN值加1，高SCN值仍然為去窮大；數(shù)據庫發(fā)生變化，則寫redo?log文件，同時SCN值會加1。
4，檢查點發(fā)生時，CKPT更新數(shù)據文件頭。

原文url:http://www.2cto.com/database/201308/237373.html

一．SCN 相關知識 SCN可以說是Oracle中的很基礎，但同時也是很重要的東西，它是一個單向增長的“時鐘”，廣泛應用于數(shù)據庫的恢復、事務ACID、一致性讀還有分布式事務中。SCN還有以下一些知識點： 1）.SCN的內部存儲方式：在Oracle內部，SCN分為兩部分存儲，分別稱之為scn wrap和scn base。實際上SCN長度為48位，即它其實就是一個48位的整數(shù)。只不過可能是由于在早些年通常只能處理32位甚至是16位的數(shù)據，所以人為地分成了低32位（scnbase）和高16位（scn wrap）。為什么不設計成64位，這個或許是覺得48位已經足夠長了并且為了節(jié)省兩個字節(jié)的空間：）。那么SCN這個48位長的整數(shù)，最大就是2^48（2的48次方, 281萬億，281474976710656），很大的一個數(shù)字了。 2） Maximum Reasonable SCN：在當前時間點，SCN最大允許達到（或者說最大可能）的SCN值。也稱為Reasonable SCN Limit，簡稱RSL。這個值是一個限制，避免數(shù)據庫的SCN無限制地增大，甚至達到了SCN的最大值。 這個值大約是這樣一個公式計算出來的：(當前時間-1988年1月1日）*24*3600*SCN每秒最大可能增長速率。 當前時間減1988年1月1日的結果是天數(shù)，24表示1天24小時，3600表示1小時3600秒。不過這個公式里面“當前時間-1988年1月”部分并不是兩個時間直接相減，而是按每月31天進行計算的（或許是為了計算簡單，因此在Oracle內部可能要頻繁地計算. 該計算公式可以在MOS文檔： Installing,Executing and Interpreting output from the “scnhealthcheck.sql” script [ID1393363.1] 中的提到的Patch：13498243中提供的腳本看到。 那么SCN每秒最大可能增長速率是多少呢，這個跟Oracle版本有一定的關系，在11.2.0.2之前是16384（即16K），在11.2.0.2版本是32768（即32K）。在11.2.0.2的版本中有一個隱含參數(shù)，_max_reasonable_scn_rate，其默認值就是32768（不建議調整這個值）。如果按16K的最大值，SCN要增長到最大，要超過500年。 [oracle@dave ~]$ ora _param ?_max_reasonable_scn_rate NAME ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? VALUE -------------------------------------------------------------------------------- _max_reasonable_scn_rate ? ? ? ? ? ? ? ? 32768 [oracle@dave ~]$ ora si SQL*Plus: Release11.2.0.3.0 Production on Sat Oct 20 19:39:48 2012 Copyright (c) 1982, 2011, Oracle. ?All rights reserved. Connected to: Oracle Database 11g Enterprise EditionRelease 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Miningand Real Application Testing options SQL> selectdecode(bitand(DI2FLAG,65536),65536,'Y','N') using16 from x$kccdi2;? US -- N 上面的SQL的結果只有在11.2.0.2及以上版本才有意義，結果為Y，表示使用的是16K的速率，否則是使用32K速率。 這個是我在11.2.0.3 版本里的一個測試，不過據老熊blog的說明，在11.2.0.2及之后的版本，從原來的32K SCN最大速率調整回了16K速率。不清楚老熊是在什么環(huán)境下測試的。我這的單機環(huán)境還是32k。 3） SCN Headroom： 這個是指MaximumReasonable SCN與當前數(shù)據庫SCN的差值。在alert中通常是以“天”為單位，這個只是為了容易讓人讀而已。天數(shù)=(Maximum Reasonable SCN-Current SCN)/16384/3600/24。 這個值就的意思就是，如果按SCN的每大增長速率，多少天會到達Maximum Reasonable SCN。但實際上即使如此，也不會到達Maximum Reasonable SCN，因為到那時MaximumReasonable SCN也增大了（越時間增大），要到達Maximum Reasonable SCN，得必須以SCN最大可能速率的2倍才行。 4） SCN的異常增長： 通常來說，每秒最大允許的16K/32K增長速率已經足夠了，但是不排除由于BUG，或者人為調整導致SCN異常增長過大。特別是后者，比如數(shù)據庫通過特殊手段強制打開，手工把SCN遞增得很大。同時Oracle的SCN會通過db link進行傳播。如果A庫通過db link連接到B庫，如果A庫的SCN高于B庫的SCN，那么B庫就會遞增SCN到跟A庫一樣，反之如果A庫的SCN低于B庫的SCN，那么A庫的SCN會遞增到跟B庫的SCN一樣。也就是說，涉及到db link進行操作的多個庫，它們會將SCN同步到這些庫中的最大的SCN。 5） 那么，如果是數(shù)據庫本身操作而不是通過db link同步使得SCN的增長，其增長速率如何判斷呢，這個可以通過系統(tǒng)的統(tǒng)計量(AWR)“calls to kcmgas”和”DEBUG calls to kcmgas”來得到。kcmgas的意思是get and advance SCN，即獲取并遞增SCN。 6) 在兩個庫通過db link進行分布式事務時，假設B庫的SCN值要高于A庫的SCN，因此要將B庫的SCN增同步到A庫，但是如果B庫的SCN過高，這樣同步到A庫之后，使得A庫面臨Headroom過小的風險，那么A庫會拒絕同步SCN，這個時候就會報ORA-19706: Invalid SCN錯誤。 分布式事務，或者說是通過dblink的操作就會失敗，即使是通過db link的查詢操作。這里顯然有一個閾值，如果遞增SCN使得Headroom過小到什么值時，就會拒絕遞增（同步）SCN？目前來看是這樣： 如果打了2012年1月CPU或PSU補丁，11.2.0.2及以后的版本，是1天即24小時，其他版本是31天即744小時，打了補丁之后可以由隱含參數(shù)_external_scn_rejection_threshold_hours來調整。 而沒有打補丁的情況下，視同此參數(shù)設為0，實際最小為1小時。由于Oracle9.2.0.8沒有了最新的補丁集，顯示也不會有這個參數(shù)，保持默認為1小時。注意這是一個靜態(tài)參數(shù)。 所以打了2012年1月CPU或PSU補丁的一個重要變化是增加了_external_scn_rejection_threshold_hours參數(shù)，同時使11.2.0.2以下版本的數(shù)據庫其Headroom的閾值增得較大。這帶來的影響就是ORA-19706的錯誤出現(xiàn)的概率更高。 解決的辦法將_external_scn_rejection_threshold_hours這個隱含參數(shù)設置為較小的值，推薦的值是24，即1天。從_external_scn_rejection_threshold_hours這個參數(shù)名的字面意思結合它的作用，可以說這個參數(shù)就是”拒絕外部SCN“的閾值。對于數(shù)據庫自身產生的SCN遞增是沒有影響的。 7) 雖然11.2.0.2及之后的版本，其默認的每秒最大可能SCN增長速率為32K，這使得Maximum Reasonable SCN更大，也就是說其SCN可以增長到更大的值。那也就是可能會使11.2.0.2的庫與低版本的數(shù)據庫之間不能進行db link連接。或者是11.2.0.2的庫不能與16K速率的（比如調整了_max_reasonable_scn_rate參數(shù)值）的11.2.0.2的庫進行db link連接。 二．SCN Headroom 引發(fā)的問題 在安裝了2012年1月發(fā)布的CPU或PSU補丁之后，增加了_external_scn_rejection_threshold_hours參數(shù)，同時使11.2.0.2以下版本的數(shù)據庫其Headroom的閾值增得較大。 因此可能會出現(xiàn)如下現(xiàn)象： 1. ?應用出現(xiàn)ORA-19706: invalid SCN錯誤。 2. ?在alert日志中出現(xiàn)類似于： Wed May 30 15:09:57 2012 Advanced SCN by 68093 minutes worth to 0×0ba9.4111a520, by distributedtransaction remote logon, remote DB:xxxx. Client info : DB logon user xxxx, machine xxxx, program oracle@xxxx (J001), andOS user oracle 這樣的警告。 3. ?在alert日志中出現(xiàn)類似于： Wed May 30 12:02:00 2012 Rejected the attempt to advance SCN over limit by 166 hours worth to0×0ba9.3caec689, by distributed transaction remote logon, remote DB: xxxx. Client info : DB logon user xxxx, machine xxxx, program oracle@xxxx (J000), andOS user oracle 這樣的錯誤信息。 4. ?在alert日志中出現(xiàn)類似于： Sat Mar 17 05:57:45 2012 ALTER DATABASE OPEN ************************************************************ Warning: The SCN headroom for this database is only 38 days! ************************************************************ 這樣的信息。 5. ?在MOS文檔《ORA-19706 and Related Alert LogMessages [ID 1393360.1]》中還提到其他會出現(xiàn)在alert中的一些警告信息： Warning - High Database SCN: Current SCN value is 0×0b7b.0008e40b, thresholdSCN value is 0×0b75.055dc000, If you have not previously reported this warningon this database, please notify Oracle Support so that additional diagnosis canbe performed. WARNING: This patch can not take full effect until this RAC database has beencompletely shutdown and restarted again.Oracle recommends that it is done atthe earliest convenience. 6. 如果說以上的現(xiàn)象只是警告或應用級報錯，影響范圍有限，那么不幸的是如果遇到RECO進程在恢復分布式事務時遇到SCN問題，則可能使數(shù)據庫宕掉，例如： Wed May 30 14:44:02 2012 ? Errors in file /oracle/admin/miboss/bdump/xxxx_reco_225864.trc: ? ORA-19706: invalid SCN ? Wed May 30 14:44:02 2012 ? Errors in file /oracle/admin/miboss/bdump/xxxx_reco_225864.trc: ? ORA-00600: internal error code, arguments: [18348], [0x000000000], [485331304561], [], [], [], [], [] ? ......... ? RECO: terminating instance due to error 476 ? Intance terminated by RECO, pid s= 225864 ? 三．2012年1月發(fā)布的CPU或PSU 帶來的影響 1.2012年1月后發(fā)布的CPU或PSU補丁到底使數(shù)據庫在SCN處理方面產生了什么樣的變化？ 答案是：增加了_external_scn_rejection_threshold_hours參數(shù)，11.2.0.2及以上版本的這個參數(shù)默認值是24，其他版本默認值是744。這樣使11.2.0.2以下版本的數(shù)據庫其Headroom的閾值增得較大。 2.這種變化對數(shù)據庫有什么危害嗎？ 答案是：在一個具有很多系統(tǒng)的大型企業(yè)環(huán)境里面，db link使用很多，甚至有一些不容易管控到的數(shù)據庫也在跟關鍵系統(tǒng)通過 db link進行連接，在這樣的環(huán)境中，過高的SCN擴散到關鍵系統(tǒng)，而系統(tǒng)如果打了這個補丁，其Headroom閾值變大，那么就更容易出現(xiàn)ORA-19706錯誤，對db link依賴很嚴重的系統(tǒng)可能會導致業(yè)務系統(tǒng)問題，嚴重情況下甚至會宕庫。不過通過設置隱含參數(shù)_external_scn_rejection_threshold_hours可解決這樣的問題。所以，如果你安裝了2012年1月的CPU或PSU補丁，請盡快設置此參數(shù)為建議的值24，極端情況下你可以設置為1。 3. alert中的那些提示或警告信息是BUG引起的嗎？ 答案是：這些提示或警告不是BUG引起的。它只是提醒你注意SCN過高增長，或者是你的Headroom較小（在Headroom小于62天時可能會提醒），引起你的重視。實際上根據MOS文檔《System Change Number (SCN), Headroom,Security and Patch Information [ID 1376995.1]》的說法，這個補丁修復了SCN相關的一些BUG。 如果非要說BUG，可以勉強認為補丁安裝后新增的參數(shù)_external_scn_rejection_threshold_hours其默認值過大。Bug 13554409 - Fix for bug 13554409 [ID 13554409.8]就是說的這個問題。不過這個問題已經在2012年4月的CPU或PSU補丁中得到修復。 4.解讀一下alert日志中的一些信息 4.1 信息： Wed May 30 15:09:53 2012 Completed crash recovery at Thread 1: logseq 3059, block 19516, scn 12754630269552 2120 data blocks read, 2120 data blocks written, 19513 redo blocks read ….. Wed May 30 15:09:57 2012 Advanced SCN by 68093 minutes worth to 0×0ba9.4111a520, by distributed transactionremote logon, remote DB:xxxx. Client info : DB logon user xxxx, machine xxxx, program oracle@xxxx (J001), andOS user oracle 這里是說，SCN向前（跳躍）遞增了68098分鐘，其遞增后的SCN是0×0ba9.4111a520。注意這里的分鐘的計算就是根據SCN每秒最大可能增長速率為16K來的。我們計算一下： 0×0ba94111a520轉換成10進制12821569053984。 在alert日志中，這個信息是剛打開數(shù)據庫的時候，所以 crash recovery完成時的scn可以做為近似的當前SCN，其值為12754630269552： (12821569053984-12754630269552)/16384/60=68093.65278320313 這里16384值的是SCN每秒最大可能增長速率，可以看到計算結果極為接近。 我們再來計算一下這個SCN的headroom是多少: SQL> ? ?select ? 2 ? ? (((( ? 3 ? ? ?((to_number(to_char(cur_date,'YYYY'))-1988)*12*31*24*60*60) + ? 4 ? ? ?((to_number(to_char(cur_date,'MM'))-1)*31*24*60*60) + ? 5 ? ? ?(((to_number(to_char(cur_date,'DD'))-1))*24*60*60) + ? 6 ? ? ?(to_number(to_char(cur_date,'HH24'))*60*60) + ? 7 ? ? ?(to_number(to_char(cur_date,'MI'))*60) + ? 8 ? ? ?(to_number(to_char(cur_date,'SS'))) ? 9 ? ? ?) * (16*1024)) - 12821569053984) ? 10 ? ? / (16*1024*60*60*24) ? 11 ? ? ) headroom ? 12 ? ? from (select to_date('2012-05-30 15:09:57','yyyy-mm-dd hh24:mi:ss') cur_date from dual); ? HEADROOM ? ---------- ? 24.1496113 ? 可以看到結果為24天，由于這個時候_external_scn_rejection_threshold_hours參數(shù)值為24，即1天，所以雖然有這么大的跳躍，但SCN仍然增長成功。 4.2 信息： Wed May 30 12:02:00 2012 Rejected the attempt to advance SCN over limit by 166 hours worth to0×0ba9.3caec689, by distributed transaction remote logon, remote DB: xxxx. Client info : DB logon user xxxx, machine xxxx, program oracle@xxxx (J000), andOS user oracle 在這個信息中，拒絕了db link引起的SCN增加。計算一下這個SCN的headroom： 0×0ba93caec689轉換成10進制是12821495465609 當前時間是2012-05-30 12:02:00， SQL> ? ?select ? 2 ? ? (((( ? 3 ? ? ?((to_number(to_char(cur_date,'YYYY'))-1988)*12*31*24*60*60) + ? 4 ? ? ?((to_number(to_char(cur_date,'MM'))-1)*31*24*60*60) + ? 5 ? ? ?(((to_number(to_char(cur_date,'DD'))-1))*24*60*60) + ? 6 ? ? ?(to_number(to_char(cur_date,'HH24'))*60*60) + ? 7 ? ? ?(to_number(to_char(cur_date,'MI'))*60) + ? 8 ? ? ?(to_number(to_char(cur_date,'SS'))) ? 9 ? ? ?) * (16*1024)) - 12821495465609) ? 10 ? ? / (16*1024*60*60*24) ? 11 ? ? ) headroom ? 12 ? ? from (select to_date('2012-05-30 12:02:00','yyyy-mm-dd hh24:mi:ss') cur_date from dual); ? HEADROOM ? ---------- ? 24.0710752 ? 由于這個時候_external_scn_rejection_threshold_hours參數(shù)值為744，即31天，計算出的headroom在這個閾值之內，因此拒絕增加SCN。 (31-24.0710752)*24=166.2941952，正好是166小時。 四．為什么是1988年 在MOS的文檔里提供了一個檢查SCN 的腳本。 Installing,Executing and Interpreting output from the “scnhealthcheck.sql” script [ID1393363.1] select version, to_char(SYSDATE,'YYYY/MM/DD HH24:MI:SS') DATE_TIME, (((( ((to_number(to_char(sysdate,'YYYY'))-1988)*12*31*24*60*60) + ((to_number(to_char(sysdate,'MM'))-1)*31*24*60*60) + (((to_number(to_char(sysdate,'DD'))-1))*24*60*60) + (to_number(to_char(sysdate,'HH24'))*60*60) + (to_number(to_char(sysdate,'MI'))*60) + (to_number(to_char(sysdate,'SS'))) )* (16*1024)) - dbms_flashback.get_system_change_number) /(16*1024*60*60*24) )indicator from v$instance 這里為什么是1988. Maclean 的blog 上有一段說明，直接引用過來： 在1988年發(fā)布了Oracle V6，首次實現(xiàn)了行級鎖定，首次實現(xiàn)了數(shù)據庫熱備份，Oracle公司從Belmont移到加利福尼亞的redwood shores，并引入了PL/SQL。 能否在1988年之前運行Oracle V6以后的程序？ Maclean 的測試如下，將Oracle 10.2.0.5 數(shù)據的OS時間改到1988年之前，測試結果如下： [root@vrh8 ~]# date -s "1985-07-2500:00:00" Thu Jul 25 00:00:00 EDT 1985 SQL> startup; ORA-01513: invalid current time returned byoperating system [oracle@vrh8 ~]$ strace -ostartup.log ?-p 9935 Process 9935 attached - interrupt to quit SQL> startup; ORA-01513: invalid current time returned byoperating system [oracle@vrh8 ~]$ oerr ora 01513 01513, 00000, "invalid current timereturned by operating system" // *Cause: ?Theoperating system returned a time that was not between // ? ? ? ? 1988 and 2121. // *Action: Correct the time kept by theoperating system. 這里可以看到Oracle數(shù)據庫可運行的時間區(qū)間其實是 1988-2121年，但是前面的說明也提高，SCN headroom 可以使用500年。這個作用就不那么明顯了。

總結

以上是生活随笔為你收集整理的oracle scn和headroom的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。