ORA-19706和_external_scn_rejection_threshold_hours

Oracle SCN headroom、ORA-19706和_external_scn_rejection_threshold_hours參數(shù)說(shuō)明

?

一．SCN 相關(guān)知識(shí)

?

SCN可以說(shuō)是Oracle中的很基礎(chǔ)，但同時(shí)也是很重要的東西，它是一個(gè)單向增長(zhǎng)的“時(shí)鐘”，廣泛應(yīng)用于數(shù)據(jù)庫(kù)的恢復(fù)、事務(wù)ACID、一致性讀還有分布式事務(wù)中。SCN還有以下一些知識(shí)點(diǎn)：

?

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

2） Maximum Reasonable SCN：在當(dāng)前時(shí)間點(diǎn)，SCN最大允許達(dá)到（或者說(shuō)最大可能）的SCN值。也稱為Reasonable SCN Limit，簡(jiǎn)稱RSL。這個(gè)值是一個(gè)限制，避免數(shù)據(jù)庫(kù)的SCN無(wú)限制地增大，甚至達(dá)到了SCN的最大值。

這個(gè)值大約是這樣一個(gè)公式計(jì)算出來(lái)的：(當(dāng)前時(shí)間-1988年1月1日）*24*3600*SCN每秒最大可能增長(zhǎng)速率。

?

當(dāng)前時(shí)間減1988年1月1日的結(jié)果是天數(shù)，24表示1天24小時(shí)，3600表示1小時(shí)3600秒。不過(guò)這個(gè)公式里面“當(dāng)前時(shí)間-1988年1月”部分并不是兩個(gè)時(shí)間直接相減，而是按每月31天進(jìn)行計(jì)算的（或許是為了計(jì)算簡(jiǎn)單，因此在Oracle內(nèi)部可能要頻繁地計(jì)算.

?

該計(jì)算公式可以在MOS文檔：

Installing,Executing and Interpreting output from the “scnhealthcheck.sql” script [ID1393363.1]

中的提到的Patch：13498243中提供的腳本看到。

?

那么SCN每秒最大可能增長(zhǎng)速率是多少呢，這個(gè)跟Oracle版本有一定的關(guān)系，在11.2.0.2之前是16384（即16K），在11.2.0.2版本是32768（即32K）。在11.2.0.2的版本中有一個(gè)隱含參數(shù)，_max_reasonable_scn_rate，其默認(rèn)值就是32768（不建議調(diào)整這個(gè)值）。如果按16K的最大值，SCN要增長(zhǎng)到最大，要超過(guò)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的結(jié)果只有在11.2.0.2及以上版本才有意義，結(jié)果為Y，表示使用的是16K的速率，否則是使用32K速率。

?

這個(gè)是我在11.2.0.3 版本里的一個(gè)測(cè)試，不過(guò)據(jù)老熊blog的說(shuō)明，在11.2.0.2及之后的版本，從原來(lái)的32K SCN最大速率調(diào)整回了16K速率。不清楚老熊是在什么環(huán)境下測(cè)試的。我這的單機(jī)環(huán)境還是32k。

?

3） SCN Headroom： 這個(gè)是指MaximumReasonable SCN與當(dāng)前數(shù)據(jù)庫(kù)SCN的差值。在alert中通常是以“天”為單位，這個(gè)只是為了容易讓人讀而已。天數(shù)=(Maximum Reasonable SCN-Current SCN)/16384/3600/24。 這個(gè)值就的意思就是，如果按SCN的每大增長(zhǎng)速率，多少天會(huì)到達(dá)Maximum Reasonable SCN。但實(shí)際上即使如此，也不會(huì)到達(dá)Maximum Reasonable SCN，因?yàn)榈侥菚r(shí)MaximumReasonable SCN也增大了（越時(shí)間增大），要到達(dá)Maximum Reasonable SCN，得必須以SCN最大可能速率的2倍才行。

?

?

4） SCN的異常增長(zhǎng)： 通常來(lái)說(shuō)，每秒最大允許的16K/32K增長(zhǎng)速率已經(jīng)足夠了，但是不排除由于BUG，或者人為調(diào)整導(dǎo)致SCN異常增長(zhǎng)過(guò)大。特別是后者，比如數(shù)據(jù)庫(kù)通過(guò)特殊手段強(qiáng)制打開(kāi)，手工把SCN遞增得很大。同時(shí)Oracle的SCN會(huì)通過(guò)db link進(jìn)行傳播。如果A庫(kù)通過(guò)db link連接到B庫(kù)，如果A庫(kù)的SCN高于B庫(kù)的SCN，那么B庫(kù)就會(huì)遞增SCN到跟A庫(kù)一樣，反之如果A庫(kù)的SCN低于B庫(kù)的SCN，那么A庫(kù)的SCN會(huì)遞增到跟B庫(kù)的SCN一樣。也就是說(shuō)，涉及到db link進(jìn)行操作的多個(gè)庫(kù)，它們會(huì)將SCN同步到這些庫(kù)中的最大的SCN。

?

5） 那么，如果是數(shù)據(jù)庫(kù)本身操作而不是通過(guò)db link同步使得SCN的增長(zhǎng)，其增長(zhǎng)速率如何判斷呢，這個(gè)可以通過(guò)系統(tǒng)的統(tǒng)計(jì)量(AWR)“calls to kcmgas”和”DEBUG calls to kcmgas”來(lái)得到。kcmgas的意思是get and advance SCN，即獲取并遞增SCN。

?

6) 在兩個(gè)庫(kù)通過(guò)db link進(jìn)行分布式事務(wù)時(shí)，假設(shè)B庫(kù)的SCN值要高于A庫(kù)的SCN，因此要將B庫(kù)的SCN增同步到A庫(kù)，但是如果B庫(kù)的SCN過(guò)高，這樣同步到A庫(kù)之后，使得A庫(kù)面臨Headroom過(guò)小的風(fēng)險(xiǎn)，那么A庫(kù)會(huì)拒絕同步SCN，這個(gè)時(shí)候就會(huì)報(bào)ORA-19706: Invalid SCN錯(cuò)誤。

分布式事務(wù)，或者說(shuō)是通過(guò)dblink的操作就會(huì)失敗，即使是通過(guò)db link的查詢操作。這里顯然有一個(gè)閾值，如果遞增SCN使得Headroom過(guò)小到什么值時(shí)，就會(huì)拒絕遞增（同步）SCN？目前來(lái)看是這樣：

如果打了2012年1月CPU或PSU補(bǔ)丁，11.2.0.2及以后的版本，是1天即24小時(shí)，其他版本是31天即744小時(shí)，打了補(bǔ)丁之后可以由隱含參數(shù)_external_scn_rejection_threshold_hours來(lái)調(diào)整。

而沒(méi)有打補(bǔ)丁的情況下，視同此參數(shù)設(shè)為0，實(shí)際最小為1小時(shí)。由于Oracle9.2.0.8沒(méi)有了最新的補(bǔ)丁集，顯示也不會(huì)有這個(gè)參數(shù)，保持默認(rèn)為1小時(shí)。注意這是一個(gè)靜態(tài)參數(shù)。

?

所以打了2012年1月CPU或PSU補(bǔ)丁的一個(gè)重要變化是增加了_external_scn_rejection_threshold_hours參數(shù)，同時(shí)使11.2.0.2以下版本的數(shù)據(jù)庫(kù)其Headroom的閾值增得較大。這帶來(lái)的影響就是ORA-19706的錯(cuò)誤出現(xiàn)的概率更高。

解決的辦法將_external_scn_rejection_threshold_hours這個(gè)隱含參數(shù)設(shè)置為較小的值，推薦的值是24，即1天。從_external_scn_rejection_threshold_hours這個(gè)參數(shù)名的字面意思結(jié)合它的作用，可以說(shuō)這個(gè)參數(shù)就是”拒絕外部SCN“的閾值。對(duì)于數(shù)據(jù)庫(kù)自身產(chǎn)生的SCN遞增是沒(méi)有影響的。

?

7) 雖然11.2.0.2及之后的版本，其默認(rèn)的每秒最大可能SCN增長(zhǎng)速率為32K，這使得Maximum Reasonable SCN更大，也就是說(shuō)其SCN可以增長(zhǎng)到更大的值。那也就是可能會(huì)使11.2.0.2的庫(kù)與低版本的數(shù)據(jù)庫(kù)之間不能進(jìn)行db link連接。或者是11.2.0.2的庫(kù)不能與16K速率的（比如調(diào)整了_max_reasonable_scn_rate參數(shù)值）的11.2.0.2的庫(kù)進(jìn)行db link連接。

?

二．SCN Headroom 引發(fā)的問(wèn)題

在安裝了2012年1月發(fā)布的CPU或PSU補(bǔ)丁之后，增加了_external_scn_rejection_threshold_hours參數(shù)，同時(shí)使11.2.0.2以下版本的數(shù)據(jù)庫(kù)其Headroom的閾值增得較大。

?

因此可能會(huì)出現(xiàn)如下現(xiàn)象：

?

1.? 應(yīng)用出現(xiàn)ORA-19706: invalid SCN錯(cuò)誤。

?

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

這樣的錯(cuò)誤信息。

?

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]》中還提到其他會(huì)出現(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. 如果說(shuō)以上的現(xiàn)象只是警告或應(yīng)用級(jí)報(bào)錯(cuò)，影響范圍有限，那么不幸的是如果遇到RECO進(jìn)程在恢復(fù)分布式事務(wù)時(shí)遇到SCN問(wèn)題，則可能使數(shù)據(jù)庫(kù)宕掉，例如： 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 帶來(lái)的影響

?

1.2012年1月后發(fā)布的CPU或PSU補(bǔ)丁到底使數(shù)據(jù)庫(kù)在SCN處理方面產(chǎn)生了什么樣的變化？

答案是：增加了_external_scn_rejection_threshold_hours參數(shù)，11.2.0.2及以上版本的這個(gè)參數(shù)默認(rèn)值是24，其他版本默認(rèn)值是744。這樣使11.2.0.2以下版本的數(shù)據(jù)庫(kù)其Headroom的閾值增得較大。

?

2.這種變化對(duì)數(shù)據(jù)庫(kù)有什么危害嗎？

答案是：在一個(gè)具有很多系統(tǒng)的大型企業(yè)環(huán)境里面，db link使用很多，甚至有一些不容易管控到的數(shù)據(jù)庫(kù)也在跟關(guān)鍵系統(tǒng)通過(guò) db link進(jìn)行連接，在這樣的環(huán)境中，過(guò)高的SCN擴(kuò)散到關(guān)鍵系統(tǒng)，而系統(tǒng)如果打了這個(gè)補(bǔ)丁，其Headroom閾值變大，那么就更容易出現(xiàn)ORA-19706錯(cuò)誤，對(duì)db link依賴很嚴(yán)重的系統(tǒng)可能會(huì)導(dǎo)致業(yè)務(wù)系統(tǒng)問(wèn)題，嚴(yán)重情況下甚至?xí)磶?kù)。不過(guò)通過(guò)設(shè)置隱含參數(shù)_external_scn_rejection_threshold_hours可解決這樣的問(wèn)題。所以，如果你安裝了2012年1月的CPU或PSU補(bǔ)丁，請(qǐng)盡快設(shè)置此參數(shù)為建議的值24，極端情況下你可以設(shè)置為1。

?

?

3. alert中的那些提示或警告信息是BUG引起的嗎？

答案是：這些提示或警告不是BUG引起的。它只是提醒你注意SCN過(guò)高增長(zhǎng)，或者是你的Headroom較小（在Headroom小于62天時(shí)可能會(huì)提醒），引起你的重視。實(shí)際上根據(jù)MOS文檔《System Change Number (SCN), Headroom,Security and Patch Information [ID 1376995.1]》的說(shuō)法，這個(gè)補(bǔ)丁修復(fù)了SCN相關(guān)的一些BUG。

如果非要說(shuō)BUG，可以勉強(qiáng)認(rèn)為補(bǔ)丁安裝后新增的參數(shù)_external_scn_rejection_threshold_hours其默認(rèn)值過(guò)大。Bug 13554409 - Fix for bug 13554409 [ID 13554409.8]就是說(shuō)的這個(gè)問(wèn)題。不過(guò)這個(gè)問(wèn)題已經(jīng)在2012年4月的CPU或PSU補(bǔ)丁中得到修復(fù)。

?

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

?

這里是說(shuō)，SCN向前（跳躍）遞增了68098分鐘，其遞增后的SCN是0×0ba9.4111a520。注意這里的分鐘的計(jì)算就是根據(jù)SCN每秒最大可能增長(zhǎng)速率為16K來(lái)的。我們計(jì)算一下：

0×0ba94111a520轉(zhuǎn)換成10進(jìn)制12821569053984。

?

在alert日志中，這個(gè)信息是剛打開(kāi)數(shù)據(jù)庫(kù)的時(shí)候，所以 crash recovery完成時(shí)的scn可以做為近似的當(dāng)前SCN，其值為12754630269552：

(12821569053984-12754630269552)/16384/60=68093.65278320313

這里16384值的是SCN每秒最大可能增長(zhǎng)速率，可以看到計(jì)算結(jié)果極為接近。

?

我們?cè)賮?lái)計(jì)算一下這個(gè)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?

?

可以看到結(jié)果為24天，由于這個(gè)時(shí)候_external_scn_rejection_threshold_hours參數(shù)值為24，即1天，所以雖然有這么大的跳躍，但SCN仍然增長(zhǎng)成功。

?

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

?

在這個(gè)信息中，拒絕了db link引起的SCN增加。計(jì)算一下這個(gè)SCN的headroom：

0×0ba93caec689轉(zhuǎn)換成10進(jìn)制是12821495465609

當(dāng)前時(shí)間是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?

由于這個(gè)時(shí)候_external_scn_rejection_threshold_hours參數(shù)值為744，即31天，計(jì)算出的headroom在這個(gè)閾值之內(nèi)，因此拒絕增加SCN。

(31-24.0710752)*24=166.2941952，正好是166小時(shí)。

?
四．為什么是1988年

??? 在MOS的文檔里提供了一個(gè)檢查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

來(lái)自 “ ITPUB博客 ” ，鏈接：http://blog.itpub.net/22193071/viewspace-1174774/，如需轉(zhuǎn)載，請(qǐng)注明出處，否則將追究法律責(zé)任。

轉(zhuǎn)載于:http://blog.itpub.net/22193071/viewspace-1174774/

總結(jié)

以上是生活随笔為你收集整理的oracle-SCN headroom的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。