當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

oracle-SCN headroom

發布時間：2024/3/24 编程问答 30 豆豆

生活随笔收集整理的這篇文章主要介紹了 oracle-SCN headroom 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

ORA-19706和_external_scn_rejection_threshold_hours

Oracle SCN headroom、ORA-19706和_external_scn_rejection_threshold_hours參數說明

一．SCN 相關知識

SCN可以說是Oracle中的很基礎，但同時也是很重要的東西，它是一個單向增長的“時鐘”，廣泛應用于數據庫的恢復、事務ACID、一致性讀還有分布式事務中。SCN還有以下一些知識點：

1）.SCN的內部存儲方式：在Oracle內部，SCN分為兩部分存儲，分別稱之為scn wrap和scn base。實際上SCN長度為48位，即它其實就是一個48位的整數。只不過可能是由于在早些年通常只能處理32位甚至是16位的數據，所以人為地分成了低32位（scnbase）和高16位（scn wrap）。為什么不設計成64位，這個或許是覺得48位已經足夠長了并且為了節省兩個字節的空間：）。那么SCN這個48位長的整數，最大就是2^48（2的48次方, 281萬億，281474976710656），很大的一個數字了。

2） Maximum Reasonable SCN：在當前時間點，SCN最大允許達到（或者說最大可能）的SCN值。也稱為Reasonable SCN Limit，簡稱RSL。這個值是一個限制，避免數據庫的SCN無限制地增大，甚至達到了SCN的最大值。

這個值大約是這樣一個公式計算出來的：(當前時間-1988年1月1日）*24*3600*SCN每秒最大可能增長速率。

當前時間減1988年1月1日的結果是天數，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的版本中有一個隱含參數，_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

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;

上面的SQL的結果只有在11.2.0.2及以上版本才有意義，結果為Y，表示使用的是16K的速率，否則是使用32K速率。

這個是我在11.2.0.3 版本里的一個測試，不過據老熊blog的說明，在11.2.0.2及之后的版本，從原來的32K SCN最大速率調整回了16K速率。不清楚老熊是在什么環境下測試的。我這的單機環境還是32k。

3） SCN Headroom：這個是指MaximumReasonable SCN與當前數據庫SCN的差值。在alert中通常是以“天”為單位，這個只是為了容易讓人讀而已。天數=(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異常增長過大。特別是后者，比如數據庫通過特殊手段強制打開，手工把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）那么，如果是數據庫本身操作而不是通過db link同步使得SCN的增長，其增長速率如何判斷呢，這個可以通過系統的統計量(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小時，打了補丁之后可以由隱含參數_external_scn_rejection_threshold_hours來調整。

而沒有打補丁的情況下，視同此參數設為0，實際最小為1小時。由于Oracle9.2.0.8沒有了最新的補丁集，顯示也不會有這個參數，保持默認為1小時。注意這是一個靜態參數。

所以打了2012年1月CPU或PSU補丁的一個重要變化是增加了_external_scn_rejection_threshold_hours參數，同時使11.2.0.2以下版本的數據庫其Headroom的閾值增得較大。這帶來的影響就是ORA-19706的錯誤出現的概率更高。

解決的辦法將_external_scn_rejection_threshold_hours這個隱含參數設置為較小的值，推薦的值是24，即1天。從_external_scn_rejection_threshold_hours這個參數名的字面意思結合它的作用，可以說這個參數就是”拒絕外部SCN“的閾值。對于數據庫自身產生的SCN遞增是沒有影響的。

7) 雖然11.2.0.2及之后的版本，其默認的每秒最大可能SCN增長速率為32K，這使得Maximum Reasonable SCN更大，也就是說其SCN可以增長到更大的值。那也就是可能會使11.2.0.2的庫與低版本的數據庫之間不能進行db link連接。或者是11.2.0.2的庫不能與16K速率的（比如調整了_max_reasonable_scn_rate參數值）的11.2.0.2的庫進行db link連接。

二．SCN Headroom 引發的問題

在安裝了2012年1月發布的CPU或PSU補丁之后，增加了_external_scn_rejection_threshold_hours參數，同時使11.2.0.2以下版本的數據庫其Headroom的閾值增得較大。

因此可能會出現如下現象：

1.? 應用出現ORA-19706: invalid SCN錯誤。

2.? 在alert日志中出現類似于：

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日志中出現類似于：

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日志中出現類似于：

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]》中還提到其他會出現在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. 如果說以上的現象只是警告或應用級報錯，影響范圍有限，那么不幸的是如果遇到RECO進程在恢復分布式事務時遇到SCN問題，則可能使數據庫宕掉，例如： 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月發布的CPU或PSU 帶來的影響

1.2012年1月后發布的CPU或PSU補丁到底使數據庫在SCN處理方面產生了什么樣的變化？

答案是：增加了_external_scn_rejection_threshold_hours參數，11.2.0.2及以上版本的這個參數默認值是24，其他版本默認值是744。這樣使11.2.0.2以下版本的數據庫其Headroom的閾值增得較大。

2.這種變化對數據庫有什么危害嗎？

答案是：在一個具有很多系統的大型企業環境里面，db link使用很多，甚至有一些不容易管控到的數據庫也在跟關鍵系統通過 db link進行連接，在這樣的環境中，過高的SCN擴散到關鍵系統，而系統如果打了這個補丁，其Headroom閾值變大，那么就更容易出現ORA-19706錯誤，對db link依賴很嚴重的系統可能會導致業務系統問題，嚴重情況下甚至會宕庫。不過通過設置隱含參數_external_scn_rejection_threshold_hours可解決這樣的問題。所以，如果你安裝了2012年1月的CPU或PSU補丁，請盡快設置此參數為建議的值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，可以勉強認為補丁安裝后新增的參數_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日志中，這個信息是剛打開數據庫的時候，所以 crash recovery完成時的scn可以做為近似的當前SCN，其值為12754630269552：

(12821569053984-12754630269552)/16384/60=68093.65278320313

這里16384值的是SCN每秒最大可能增長速率，可以看到計算結果極為接近。

我們再來計算一下這個SCN的headroom是多少:

SQL>??? select?
???? ((((?
????? ((to_number(to_char(cur_date,'YYYY'))-1988)*12*31*24*60*60) +?
????? ((to_number(to_char(cur_date,'MM'))-1)*31*24*60*60) +?
????? (((to_number(to_char(cur_date,'DD'))-1))*24*60*60) +?
????? (to_number(to_char(cur_date,'HH24'))*60*60) +?
????? (to_number(to_char(cur_date,'MI'))*60) +?
????? (to_number(to_char(cur_date,'SS')))?
????? ) * (16*1024)) - 12821569053984)?
???? / (16*1024*60*60*24)?
???? ) headroom?
???? 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參數值為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?
???? ((((?
????? ((to_number(to_char(cur_date,'YYYY'))-1988)*12*31*24*60*60) +?
????? ((to_number(to_char(cur_date,'MM'))-1)*31*24*60*60) +?
????? (((to_number(to_char(cur_date,'DD'))-1))*24*60*60) +?
????? (to_number(to_char(cur_date,'HH24'))*60*60) +?
????? (to_number(to_char(cur_date,'MI'))*60) +?
????? (to_number(to_char(cur_date,'SS')))?
????? ) * (16*1024)) - 12821495465609)?
???? / (16*1024*60*60*24)?
???? ) headroom?
???? 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參數值為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
?
??SELECT?? ksppinm, ksppstvl, ksppdesc FROM?? x$ksppi x, x$ksppcv y WHERE?? x.indx = y.indx AND? ksppinm = '_external_scn_rejection_threshold_hours';
?
?SELECT ksppinm, ksppstvl/1024, ksppdesc FROM x$ksppi x, x$ksppcv y WHERE x.indx = y.indx AND? ksppinm = '_max_reasonable_scn_rate';
?
?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')))
??? )* (32*1024)) - dbms_flashback.get_system_change_number)
?? /(32*1024*60*60*24)
?? )indicator
? from v$instance

來自 “ ITPUB博客 ” ，鏈接：http://blog.itpub.net/22193071/viewspace-1174774/，如需轉載，請注明出處，否則將追究法律責任。

轉載于:http://blog.itpub.net/22193071/viewspace-1174774/

總結

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

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

上一篇： Java 设计模式——组合模式
下一篇： WIN10远程桌面连接发生身份验证错误(