SCN、ORA-19706錯誤和_external_scn_rejection_threshold_hours參數(shù)是什么

今天就跟大家聊聊有關(guān)SCN、ORA-19706錯誤和_external_scn_rejection_threshold_hours參數(shù)是什么，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

如果數(shù)據(jù)庫alert日志中出現(xiàn)了以下與SCN有關(guān)的信息：  

• 應(yīng)用出現(xiàn)ORA-19706: invalid SCN錯誤。

• 在alert日志中出現(xiàn)類似于：
  
  Wed May 30 15:09:57 2012
  
  Advanced SCN by 68093 minutes worth to 0×0ba9.4111a520, by distributed transaction remote logon, remote DB:xxxx.
  
  Client info : DB logon user xxxx, machine xxxx, program oracle@xxxx (J001), and OS user oracle
  
  這樣的警告。

• 在alert日志中出現(xiàn)類似于：
  
  Wed May 30 12:02:00 2012
  
  Rejected the attempt to advance SCN over limit by 166 hours worth to 0×0ba9.3caec689, by distributed transaction remote logon, remote DB: xxxx.
  
  Client info : DB logon user xxxx, machine xxxx, program oracle@xxxx (J000), and OS user oracle
  
  這樣的錯誤信息。

• 在alert日志中出現(xiàn)類似于：
  
  Sat Mar 17 05:57:45 2012
  
  ALTER DATABASE OPEN
  
  ************************************************************
  
  Warning: The SCN headroom for this database is only 38 days!
  
  ************************************************************
  
  這樣的信息。

• 在MOS文檔《ORA-19706 and Related Alert Log Messages [ID 1393360.1]》中還提到其他會出現(xiàn)在alert中的一些警告信息：
  
  Warning - High Database SCN: Current SCN value is 0×0b7b.0008e40b, threshold SCN value is 0×0b75.055dc000, If you have not previously reported this warning on this database, please notify Oracle Support so that additional diagnosis can be performed.
  
  WARNING: This patch can not take full effect until this RAC database
  has been completely shutdown and restarted again.Oracle recommends that it is done at the earliest convenience.

其原因是：

如果說以上的現(xiàn)象只是警告或應(yīng)用級報錯，影響范圍有限，那么不幸的是如果遇到RECO進(jìn)程在恢復(fù)分布式事務(wù)時遇到SCN問題，則可能使數(shù)據(jù)庫宕掉，例如：

view plaincopy
to clipboardprint?

1. 
   

2. Wed May 30 14:44:02 2012   

3. Errors in file /oracle/admin/miboss/bdump/xxxx_reco_225864.trc:   

4. ORA-19706: invalid SCN   

5. Wed May 30 14:44:02 2012   

6. Errors in file /oracle/admin/miboss/bdump/xxxx_reco_225864.trc:   

7. ORA-00600: internal error code, arguments: [18348], [0x000000000], [485331304561], [], [], [], [], []   

8. .........   

9. RECO: terminating instance due to error 476   

10. Intance terminated by RECO, pid s= 225864  

那么2012年1月發(fā)布的CPU或PSU補(bǔ)丁到底使數(shù)據(jù)庫在SCN處理方面產(chǎn)生了什么樣的變化？這種變化對數(shù)據(jù)庫有什么危害嗎？甚至于說，以上提示的信息是由于這個補(bǔ)丁的BUG引起的嗎？

要回答這些問題，得先從SCN講起。SCN可以說是Oracle中的很基礎(chǔ)，但同時也是很重要的東西，它是一個單向增長的“時鐘”，廣泛應(yīng)用于數(shù)據(jù)庫的恢復(fù)、事務(wù)ACID、一致性讀還有分布式事務(wù)中。那么除了這些，SCN還有以下一些知識點(diǎn)：

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

• Maximum Reasonable SCN：在當(dāng)前時間點(diǎn)，SCN最大允許達(dá)到（或者說最大可能）的SCN值。也稱為Reasonable SCN Limit，簡稱RSL。這個值是一個限制，避免數(shù)據(jù)庫的SCN無限制地增大，甚至達(dá)到了SCN的最大值。這個值大約是這樣一個公式計算出來的：(當(dāng)前時間-1988年1月1日）*24*3600*SCN每秒最大可能增長速率。當(dāng)前時間減1988年1月1日的結(jié)果是天數(shù)，24表示1天24小時，3600表示1小時3600秒。不過這個公式里面“當(dāng)前時間-1988年1月”部分并不是兩個時間直接相減，而是按每月31天進(jìn)行計算的（或許是為了計算簡單，因此在Oracle內(nèi)部可能要頻繁地計算，這個計算方法可以在安裝了13498243這個補(bǔ)丁后得到的scnhealthcheck.sql文件中看到，《Installing,
  Executing and Interpreting output from the “scnhealthcheck.sql” script. [ID 1393363.1]》這篇MOS文檔解釋了這個腳本的使用及對結(jié)果的解釋，實(shí)際上直接看腳本代碼更為清楚）。那么SCN最秒最大可能增長速率是多少呢，這個跟Oracle版本有一定的關(guān)系，在11.2.0.2之前是16384（即16K），在11.2.0.2及之后版本是32768（即32K）。在11.2.0.2的版本中有一個隱含參數(shù)，_max_reasonable_scn_rate，其默認(rèn)值就是32768（不建議調(diào)整這個值）。如果按16K的最大值，SCN要增長到最大，要超過500年。

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

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

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

• 在兩個庫通過db link進(jìn)行分布式事務(wù)時，假設(shè)B庫的SCN值要高于A庫的SCN，因此要將B庫的SCN增同步到A庫，但是如果B庫的SCN過高，這樣同步到A庫之后，使得A庫面臨Headroom過小的風(fēng)險，那么A庫會拒絕同步SCN，這個時候就會報ORA-19706: Invalid SCN錯誤。分布式事務(wù)，或者說是通過db link的操作就會失敗，即使是通過db link的查詢操作。這里顯然有一個閾值，如果遞增SCN使得Headroom過小到什么值時，就會拒絕遞增（同步）SCN？目前來看是這樣：如果打了2012年1月CPU或PSU補(bǔ)丁，11.2.0.2及以后的版本，是1天即24小時，其他版本是31天即744小時，打了補(bǔ)丁之后可以由隱含參數(shù)_external_scn_rejection_threshold_hours來調(diào)整。而沒有打補(bǔ)丁的情況下，視同此參數(shù)設(shè)為0，實(shí)際最小為1小時。由于Oracle
  9.2.0.8沒有了最新的補(bǔ)丁集，顯示也不會有這個參數(shù)，保持默認(rèn)為1小時。注意這是一個靜態(tài)參數(shù)。所以打了2012年1月CPU或PSU補(bǔ)丁的一個重要變化是增加了_external_scn_rejection_threshold_hours參數(shù)，同時使11.2.0.2以下版本的數(shù)據(jù)庫其Headroom的閾值增得較大。這帶來的影響就是ORA-19706的錯誤出現(xiàn)的概率更高。解決的辦法將_external_scn_rejection_threshold_hours這個隱含參數(shù)設(shè)置為較小的值，推薦的值是24，即1天。從_external_scn_rejection_threshold_hours這個參數(shù)名的字面意思結(jié)合它的作用，可以說這個參數(shù)就是”拒絕外部SCN“的閾值。對于數(shù)據(jù)庫自身產(chǎn)生的SCN遞增是沒有影響的。

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

現(xiàn)在是時候來回答以下幾個問題了：

• 2012年1月后發(fā)布的CPU或PSU補(bǔ)丁到底使數(shù)據(jù)庫在SCN處理方面產(chǎn)生了什么樣的變化？答案是：增加了_external_scn_rejection_threshold_hours參數(shù)，11.2.0.2及以上版本的這個參數(shù)默認(rèn)值是24，其他版本默認(rèn)值是744。這樣使11.2.0.2以下版本的數(shù)據(jù)庫其Headroom的閾值增得較大。

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

• alert中的那些提示或警告信息是BUG引起的嗎？答案是：這些提示或警告不是BUG引起的。它只是提醒你注意SCN過高增長，或者是你的Headroom較小（在Headroom小于62天時可能會提醒），引起你的重視。實(shí)際上根據(jù)MOS文檔《System Change Number (SCN), Headroom, Security and Patch Information [ID
  1376995.1]》的說法，這個補(bǔ)丁修復(fù)了SCN相關(guān)的一些BUG。如果非要說BUG，可以勉強(qiáng)認(rèn)為補(bǔ)丁安裝后新增的參數(shù)_external_scn_rejection_threshold_hours其默認(rèn)值過大。Bug 13554409 - Fix for bug 13554409 [ID 13554409.8]就是說的這個問題。不過這個問題已經(jīng)在2012年4月的CPU或PSU補(bǔ)丁中得到修復(fù)。

在最后我們來解讀一下alert日志中的一些信息：

• 信息：
  
  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 transaction remote logon, remote DB:xxxx.
  
  Client info : DB logon user xxxx, machine xxxx, program oracle@xxxx (J001), and OS user oracle
  
  這里是說，SCN向前（跳躍）遞增了68098分鐘，其遞增后的SCN是0×0ba9.4111a520。注意這里的分鐘的計算就是根據(jù)SCN每秒最大可能增長速率為16K來的。我們計算一下：
  
  0×0ba94111a520轉(zhuǎn)換成10進(jìn)制12821569053984。
  
  在alert日志中，這個信息是剛打開數(shù)據(jù)庫的時候，所以 crash recovery完成時的scn可以做為近似的當(dāng)前SCN，其值為12754630269552：
  
  (12821569053984-12754630269552)/16384/60=68093.65278320313
  
  這里16384值的是SCN每秒最大可能增長速率，可以看到計算結(jié)果極為接近。

  
  

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

  view plaincopy
  to clipboardprint?

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

1. SQL>    select

2.   2     ((((   

3.   3      ((to_number(to_char(cur_date,'YYYY'))-1988)*12*31*24*60*60) +   

4.   4      ((to_number(to_char(cur_date,'MM'))-1)*31*24*60*60) +   

5.   5      (((to_number(to_char(cur_date,'DD'))-1))*24*60*60) +   

6.   6      (to_number(to_char(cur_date,'HH24'))*60*60) +   

7.   7      (to_number(to_char(cur_date,'MI'))*60) +   

8.   8      (to_number(to_char(cur_date,'SS')))   

9.   9      ) * (16*1024)) - 12821569053984)   

10.  10     / (16*1024*60*60*24)   

11.  11     ) headroom   

12.  12     from (select to_date('2012-05-30 15:09:57','yyyy-mm-dd hh34:mi:ss') cur_date from dual);
    

13. 
    

14.   HEADROOM   

15. ----------

16. 24.1496113  

• 信息：
  
  Wed May 30 12:02:00 2012
  
  Rejected the attempt to advance SCN over limit by 166 hours worth to 0×0ba9.3caec689, by distributed transaction remote logon, remote DB: xxxx.
  
  Client info : DB logon user xxxx, machine xxxx, program oracle@xxxx (J000), and OS user oracle
  
  在這個信息中，拒絕了db link引起的SCN增加。計算一下這個SCN的headroom：
  
  0×0ba93caec689轉(zhuǎn)換成10進(jìn)制是12821495465609
  
  當(dāng)前時間是2012-05-30 12:02:00，

  view plaincopy
  to clipboardprint?

  由于這個時候_external_scn_rejection_threshold_hours參數(shù)值為744，即31天，計算出的headroom在這個閾值之內(nèi)，因此拒絕增加SCN。
  
  (31-24.0710752)*24=166.2941952，正好是166小時。

1. SQL>    select

2.   2     ((((   

3.   3      ((to_number(to_char(cur_date,'YYYY'))-1988)*12*31*24*60*60) +   

4.   4      ((to_number(to_char(cur_date,'MM'))-1)*31*24*60*60) +   

5.   5      (((to_number(to_char(cur_date,'DD'))-1))*24*60*60) +   

6.   6      (to_number(to_char(cur_date,'HH24'))*60*60) +   

7.   7      (to_number(to_char(cur_date,'MI'))*60) +   

8.   8      (to_number(to_char(cur_date,'SS')))   

9.   9      ) * (16*1024)) - 12821495465609)   

10.  10     / (16*1024*60*60*24)   

11.  11     ) headroom   

12.  12     from (select to_date('2012-05-30 12:02:00','yyyy-mm-dd hh34:mi:ss') cur_date from dual);
    

13. 
    

14.   HEADROOM   

15. ----------

16. 24.0710752  

--update on 2012/6/2--

實(shí)際上2012年1月的CPU或PSU補(bǔ)丁之后還會有下面的變化：

1. _minimum_giga_scn這個隱含沒有了，可惜了這個手工增加SCN的利器。

2. 11.2.0.2及之后的版本，從原來的32K SCN最大速率調(diào)整回了16K速率?？梢杂孟旅娴腟QL來得到結(jié)果： view plaincopy
   to clipboardprint?

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

1. SQL&gt select decode(bitand(DI2FLAG,65536),65536,'Y','N') using16
   

2.   2   from x$kccdi2;   

3. 
   

4. U   

5. -   

6. Y  

本文涉及的一些參數(shù)，和SCN的一些算法，可能會隨著版本或補(bǔ)丁的變化而產(chǎn)生較大的變化。

看完上述內(nèi)容，你們對SCN、ORA-19706錯誤和_external_scn_rejection_threshold_hours參數(shù)是什么有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。