知識星球
作者 | 張維照，雲和恩墨技術專家，Oracle ACEA，2006年起從事資料庫管理工作，2009年轉Oracle，從事過多套TB級省級工商、醫療、交通、人社、電信運營等資料庫維護最佳化工作，擅長Oracle資料庫效能問題的分析與解決、故障分析、升級遷移。個人部落格：www.anbob.com
案例背景
前段時間有個朋友遇到的問題，讓我協助分析，現象是一個地市的資料庫與省級資料庫透過DBLINK連線時提示ORA-600 2252，但是其它地市與省級的DBLINK正常。
案例詳情
具體分析，錯誤如下：
SQL> select sysdate from dual@ANBOB_RMTORA-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---------------------------17116808891077SQL@ANBOB> select dbms_flashback.get_system_change_number scn from dual;SCN----------15756464714sys@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:48sysdate: 20171204 .. 20171204 ..scn: 15756464722 17117005290806DB ver: 11.2.0.1 11.2.0.3OS Plat: Windows Aix
註意：
本地庫和遠端庫的SCN不在一個數量級，相差1000倍，其實我們可以根據當前的時間計算一下SCN 的最大允許值，遠端庫的SCN 遠大於本地庫的最大允許SCN（簡稱RSL，下麵會補充相關知識）。關於SCN可以查閱MOS note <>
— 查詢遠端庫的SCN Headroom
select2 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 ) indicator14 from v$instance15 ;VERSION DATE_TIME INDICATOR------------------- ----------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_rateShow 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 ratesys@ANBOB_RMT>select decode(bitand(DI2FLAG,65536),65536,'Y','N') using16 from x$kccdi2;U-Nsys@ANBOB_RMT>selectversion,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。
