實戰演練丨SCN太大引發ORA-600[2252]

作者 | 張維照，云和恩墨技術專家，Oracle ACEA，2006年起從事數據庫管理工作，2009年轉Oracle，從事過多套TB級省級工商、醫療、交通、人社、電信運營等數據庫維護優化工作，擅長Oracle數據庫性能問題的分析與解決、故障分析、升級遷移。個人博客：www.anbob.com

前段時間有個朋友遇到的問題，讓我協助分析，現象是一個地市的數據庫與省級數據庫通過DBLINK連接時提示ORA-600 2252，但是其它地市與省級的DBLINK正常。

具體分析，錯誤如下：

---------------------------SCN----------15756464714
sys@ANBOB>select current_scn,dbms_flashback.get_system_change_number scn from v$database;
CURRENT_SCN                  SCN-------------------- --------------------15756464716          15756464716
-- 確認時間,時區select CURRENT_TIMESTAMP, LOCALTIMESTAMP FROM DUAL;
-- 現場的人整理了本地(DBa)、遠程(DBb)庫的系統時間和SCN.

DBa          DBb
--------      ----------
OS date: 20171204 15:50        20171204 15:48

sysdate: 20171204 ..        20171204 ..

scn: 15756464722        17117005290806

DB ver: 11.2.0.1            11.2.0.3
OS Plat: Windows            Aix

注意：
本地庫和遠程庫的SCN不在一個數量級，相差1000倍，其實我們可以根據當前的時間計算一下SCN 的最大允許值，遠程庫的SCN 遠大于本地庫的最大允許SCN（簡稱RSL，下面會補充相關知識）。關于SCN可以查閱MOS note <<System Change Number（SCN）, Headroom, Security and Patch Information（文檔 ID 1376995.1）>>

— 查詢遠程庫的SCN Headroom

SQL> select
2   version,
3   to_char(SYSDATE, 'YYYY/MM/DD HH24:MI:SS') DATE_TIME,
4   ((((
5    ((to_number(to_char(sysdate, 'YYYY')) - 1988) * 12 * 31 * 24 * 60 * 60) +
6    ((to_number(to_char(sysdate, 'MM')) - 1) * 31 * 24 * 60 * 60) +
7    (((to_number(to_char(sysdate, 'DD')) - 1)) * 24 * 60 * 60) +
8    (to_number(to_char(sysdate, 'HH24')) * 60 * 60) +
9    (to_number(to_char(sysdate, 'MI')) * 60) +
10    (to_number(to_char(sysdate, 'SS')))
11   ) * (16 * 1024)) - dbms_flashback.get_system_change_number)
12   / (16 * 1024 * 60 * 60 * 24)
13   ) indicator
14    from v$instance
15  ;
VERSION           DATE_TIME            INDICATOR
----------------- ------------------- ----------
11.2.0.3.0        2017/12/04 17:15:26 -959.18726

注意：

Oops!!!  上面的腳本也較常見來自官方的scnhealthcheck.sql， INDICATOR是距離SCN Headroom（天花板）的天數，是負數說明已經超過天花板上天了。當然SCN限制是決定不會也不允許超過天花板的。 那會不會是遠程庫有問題？為什么其它地市的庫可以跟這個遠程庫查詢？負數的原因是什么？

基實上面的腳本對于11.2.0.2以后的數據庫還需要確認另一處，就是每秒16K的限制從11G R2（11.2.0.2）起已經改變為32K（我查了11.2.0.3 11.2.0.4 12.2.0.1默認都是32K）, 有隱藏參數”_max_reasonable_scn_rate”控制，同時需要使用下面的SQL語句實際確認是16K還是32K（只對11.2.0.2以后的版本有意義），因為我發現有些11.2的數據庫仍然使用的是16K（也許是低版本直接升級原因，也許是某個PSU臨時回歸了16K的增速）：

sys@ANBOB_RMT>@pd _max_reasonable_scn_rate
Show all parameters and session values from x$ksppi/x$ksppcv...
INDX I_HEX NAME                         VALUE      DESCRIPTION
-------------------- ----- ---------------------------- ---------- ---------------------------
978   3D2 _max_reasonable_scn_rate     32768      Max reasonable SCN rate
sys@ANBOB_RMT>select decode(bitand(DI2FLAG,65536),65536,'Y','N') using16 from x$kccdi2;
U
-
N
sys@ANBOB_RMT>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)) indicatorfrom v$instance;
VERSION           DATE_TIME            INDICATOR
----------------- ------------------- ----------
11.2.0.3.0        2017/12/04 17:35:26 5087.41908

現在總結一下這個問題：

• 本地庫是11.2.0.1 scn 的頻率限制還是16K；

• 遠程庫是11.2.0.3，并且從x$kccdi2確認了當前使用的頻率限制是32K；

• 遠程庫當前的SCN已經超過了本地庫16K允許的上限所以使用DBLINK 同步SCN 會出現ora-600 [2252]；

• 遠程庫查詢天花板需要修改腳本中16為32；

• 其它地市能訪問遠程庫是因為他們的數據庫也是11.2.0.2版本以后，且同樣使用的是32K的限制。

SCN增長速率加快了，如果32k的速度使用6bytes的scn總上限也就不是過去說的可用500年了，所以從12.2又引入了big scn加到了8bytes。且在12.2版本中對于SCN傳播跳躍，增加了2個視圖可以定位源頭， 使用DBA_EXTERNAL_SCN_ACTIVITY  DBA_DB_LINK_SOURCES and DBA_DB_LINK關連就可以，2012年1月以后的PSU起或在11G的部份版本中提供了控制SCN相關參數：

• SCN rejected due to request for high SCN increment（controlled by _external_scn_rejection_threshold_hours）限制最多用到多少，保留時間；

• SCN rejected due to request in certain DELTA of changes（controlled by _external_scn_rejection_delta_threshold_minutes）限制一次最多變化多少，如果請求超過會失敗，提示ORA-19706；

• SCN accepted but with a warning（controlled by _external_scn_logging_threshold_seconds）增長超過一定閥值時，寫ALERT LOG。

SCN相關知識點：

• SCN是Oracle數據庫單向增長的”時鐘”,廣泛用于數據庫一致性恢復和分布式事務（如dblink）；

• SCN有兩部分組成 wrap.base， 在數據庫中占用8bytes，在12c r2前預留2bytes，是一個6bytes（48bit）的Integer類型的數字，[16bit SCN Wrap].[32bit SCN Base]，在12c R2起引入big scn，啟用了原來預留的2bytes, 總長限有原來的2^48增長到2^64；

• 為了限制SCN無限增長，在程序的代碼級設計了一個當前時間點的允許的最大SCN（Maximum Reasonable SCN）的軟限制，Reasonable SCN Limit簡稱RSL，這個值是有一個工式計算出來的RSL=（從1988年1月1日起到當前時間） * 24 * 3600 * 每秒允許的最大增長率， 需要注意的是并不是簡單的當前時間和1988-1-1兩個時間點相減，可能是出于計算的簡單，每個月是按31天計算的，從上面MOS中提供的腳本也可以看出。 每秒允許的最大增長率在11.2.0.2之前是16384（16K）11.2.0.2及以后的版本是32768（32K），有隱藏參數_max_reasonable_scn_rate控制；

• SCN Headroom是一個最重要的檢查項，值是當前時間點的允許的最大SCN與當前數據庫SCN的差值，為了方便閱讀以”天“為單位，SCN Headroom天數=（Maximum Reasonable SCN-Current SCN） /（每秒允許的最大增長率） /3600/24；

• SCN異常增長通常是有DBLINK、人為前推SCN、oracle bug，SCN的歷史變化可以從V$ARCHIVED_LOG得到， 最近5天的SCN也可以嘗試從smon_scn_time得到。 數據庫自身的增長可以從從dba_hist_sysstat得到’calls to kcmgas’的變化，SCN通過DBLINK 的傳播可以通過上面提到的參數控制，和12c 中提供的新視圖；

• 數據庫11.2.0.2及以后的版本默認是允許32K的增長速率，所以就會像本案例以上產生較大的SCN, 這就意味著11.2.0.2可能不能再與低版本的數據庫或是使用16K增長速率的數據庫通過DBLINK。