歡迎光臨
每天分享高質量文章

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

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

 

案例背景

 

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

 

案例詳情

具體分析,錯誤如下:

SQL> select sysdate from [email protected]_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: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

SQL> 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----------------- ------------------- ----------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的增速):

 

[email protected]_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 rate
[email protected]_RMT>select decode(bitand(DI2FLAG,65536),65536,'Y','N') using16 from x$kccdi2;U-N
[email protected]_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。

赞(0)

分享創造快樂