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

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

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

具體分析，錯誤如下：

SQL> select sysdate from dual@ANBOB_RMT
ORA-00600: 內部錯誤程式碼, 引數: [2252], [3985], [1364216517], [], [], [], [], []

ORA-600 [2252] [A] [B] [] [] []

原因：Oracle將給定的SCN值與基於系統日期，如果Oracle檢測到提供的SCN太大，則會引發ORA-600[2252]。
ARGS:
引數A：SCN WRAP
引數B：SCN BASE
修復：
症狀：兩臺機器的系統日期不同
症狀：在兩臺機器之間使用資料庫連結的查詢失敗
原因：

ORA-00600的引數[2252]表示Oracle為事務計算的系統更改號（SCN）是一個不合理的數字。SCN部分基於主機系統日期進行計算。如果系統日期相差很遠，則為SCN計算的最大可能值可能不可能大，這將導致ORA-600[2252]。

總結：資料庫當前的請求SCN大於當前最大允許SCN時會提示ORA-600[2252]，最大允許SCN是有本地系統時間決定。一個可能性是本地庫主機時間向前調了，還有個可能性是通過DBLINK分散式事務同步SCN時，遠端庫SCN大於本地允許的最大SCN。

SQL@ANBOB> select 3985*power(2,32)+1364216517 from dual;
3985*POWER(2,32)+1364216517---------------------------17116808891077
SQL@ANBOB> select dbms_flashback.get_system_change_number scn from dual;
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。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31556440/viewspace-2640941/，如需轉載，請註明出處，否則將追究法律責任。