How to resolve ORA-19706 error when select from dblink

　　由於透過database link進行遠端資料庫的資料讀取時，會自動同步當前庫和遠端庫的SCN，老楊在中做過描述，並且提到：

　　而對於實際環境中，SCN的增加可能是幾倍、幾十倍甚至是上百倍，從而引發一些其他的bug。

　　下面就來看一個問題。該錯誤會在應用了2012年1月份CPU的Oracle資料庫中出現，而在原始版本中，比如10.2.0.5.0之中不會出現此錯誤。

--透過dblink進行簡單的查詢報ORA-19706錯誤
SQL> SELECT sysdate FROM dual@AIX12;
 
SELECT sysdate FROM dual@AIX12
 
ORA-19706: invalid SCN
 
--登入遠端庫，檢查SCN，很大的一個數字
SQL> SELECT current_scn FROM v$database; 
 
CURRENT_SCN
-----------
12763142641
 
--而當前庫，由於新建立，所以SCN並不大，與遠端庫想比相差幾個數量級
SQL> SELECT current_scn FROM v$database;
 
CURRENT_SCN
-----------
    5017684

　　看一下ORA-19706錯誤的解釋。可以看到too large是產生該問題的原因之一。

$oerr ora 19706
19706, 00000, "invalid SCN"
// *Cause:  The input SCN is either not a positive integer or too large.
// *Action: Check the input SCN and make sure it is a valid SCN.

　　SCN是一個可以容納很長時間的數字，為什麼會出現too large的情況呢？這是由於SCN有headroom限制的原因，headroom是一個固定值，從1988年開始計算，以每秒16K的速度遞增。當突然請求的SCN超過跟SCN headroom之間允許的差值時，則會出現ORA-19706錯誤。

　　詳細的解釋可以參看MOS Note – System Change Number (SCN), Headroom, Security and Patch Information [ID 1376995.1]。

解決方法：
1. 設定隱含引數_external_scn_rejection_threshold_hours，具體解釋可以參看：
MOS Note – Installing, Executing and Interpreting output from the “scnhealthcheck.sql” script [ID 1393363.1]。

該引數在10.2.0.5中預設是744，設定為24通常可以解決問題（表示允許跟headroom之間的差距相差24小時）。

SQL> ALTER system SET "_external_scn_rejection_threshold_hours"=24 scope=spfile;

也就是如果遠端資料庫的SCN由於某些bug導致異常增長，那麼這個SCN跟headroom之間的差距將會低於預設值744小時（31天），當本地資料庫（打了2012年1月份CPU補丁後的）透過dblink查詢遠端資料，由於SCN同步機制，本地資料庫嘗試將SCN同步為跟遠端一樣大小，但是這個值超過了跟SCN headroom之間允許的差值，因此報錯。

實際上具體設定的值應該根據上面MOS文件中scnhealthcheck.sql的結果，該SQL應該在遠端資料庫中執行（或者說在具有最大的SCN的資料庫中執行），假設執行結果顯示：

SCN Headroom: 14.55

那麼則表示目前SCN距離headroom只有14.55天的空間，此時我們將_external_scn_rejection_threshold_hours引數設定為13*24=312，即可解決問題。但是要注意，遠端資料庫SCN仍在不停異常增長，等到某一天遠端資料庫的SCN Headroom降低為小於13天的時候，ORA-19706錯誤又會再次出現。

2. 回滾打上的2012年1月份CPU。當然這並不是推薦的方法。

3. 最終極的解決方案，將環境中所有透過dblink互相連線的資料庫全部打上最新的PSU，比如目前10205的最新PSU是10.2.0.5.7，這將會解決所有SCN異常增長的問題，只要資料庫每秒增長的SCN不會超過16K，那麼就會離headroom越來越遠。