SCN、ORA-19706錯誤和_external_scn_rejection_threshold_hours參數是什么

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

如果數據庫alert日志中出現了以下與SCN有關的信息：  

• 應用出現ORA-19706: invalid SCN錯誤。

• 在alert日志中出現類似于：
  
  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日志中出現類似于：
  
  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日志中出現類似于：
  
  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]》中還提到其他會出現在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.

其原因是：

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

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月發布的CPU或PSU補丁到底使數據庫在SCN處理方面產生了什么樣的變化？這種變化對數據庫有什么危害嗎？甚至于說，以上提示的信息是由于這個補丁的BUG引起的嗎？

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

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

• 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內部可能要頻繁地計算，這個計算方法可以在安裝了13498243這個補丁后得到的scnhealthcheck.sql文件中看到，《Installing,
  Executing and Interpreting output from the “scnhealthcheck.sql” script. [ID 1393363.1]》這篇MOS文檔解釋了這個腳本的使用及對結果的解釋，實際上直接看腳本代碼更為清楚）。那么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年。

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

• 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。

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

• 在兩個庫通過db link進行分布式事務時，假設B庫的SCN值要高于A庫的SCN，因此要將B庫的SCN增同步到A庫，但是如果B庫的SCN過高，這樣同步到A庫之后，使得A庫面臨Headroom過小的風險，那么A庫會拒絕同步SCN，這個時候就會報ORA-19706: Invalid SCN錯誤。分布式事務，或者說是通過db link的操作就會失敗，即使是通過db link的查詢操作。這里顯然有一個閾值，如果遞增SCN使得Headroom過小到什么值時，就會拒絕遞增（同步）SCN？目前來看是這樣：如果打了2012年1月CPU或PSU補丁，11.2.0.2及以后的版本，是1天即24小時，其他版本是31天即744小時，打了補丁之后可以由隱含參數_external_scn_rejection_threshold_hours來調整。而沒有打補丁的情況下，視同此參數設為0，實際最小為1小時。由于Oracle
  9.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遞增是沒有影響的。

• 雖然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連接。

現在是時候來回答以下幾個問題了：

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

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

• 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補丁中得到修復。

在最后我們來解讀一下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。注意這里的分鐘的計算就是根據SCN每秒最大可能增長速率為16K來的。我們計算一下：
  
  0×0ba94111a520轉換成10進制12821569053984。
  
  在alert日志中，這個信息是剛打開數據庫的時候，所以 crash recovery完成時的scn可以做為近似的當前SCN，其值為12754630269552：
  
  (12821569053984-12754630269552)/16384/60=68093.65278320313
  
  這里16384值的是SCN每秒最大可能增長速率，可以看到計算結果極為接近。

  
  

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

  view plaincopy
  to clipboardprint?

  可以看到結果為24天，由于這個時候_external_scn_rejection_threshold_hours參數值為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轉換成10進制是12821495465609
  
  當前時間是2012-05-30 12:02:00，

  view plaincopy
  to clipboardprint?

  由于這個時候_external_scn_rejection_threshold_hours參數值為744，即31天，計算出的headroom在這個閾值之內，因此拒絕增加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--

實際上2012年1月的CPU或PSU補丁之后還會有下面的變化：

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

2. 11.2.0.2及之后的版本，從原來的32K SCN最大速率調整回了16K速率。可以用下面的SQL來得到結果： view plaincopy
   to clipboardprint?

   上面的SQL的結果只有在11.2.0.2及以上版本才有意義，結果為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  

本文涉及的一些參數，和SCN的一些算法，可能會隨著版本或補丁的變化而產生較大的變化。

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