ORA-19706: invalid SCN 問題分析

531968912發表於2016-01-22
SQL> select sysdate from dual@dl330781;
select sysdate from dual@dl330781
*
ERROR at line 1:
ORA-19706: invalid SCN
[oracle@jbdb bdump]$ tail -f alert_orcl.log
Mon Mar 23 16:43:25 CST 2015
db_recovery_file_dest_size of 2048 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Mon Mar 23 16:43:25 CST 2015
Completed: alter database open
Tue Mar 24 13:48:13 CST 2015
Rejected the attempt to advance SCN over limit by 389 hours worth to 0×0d05.bcf8452b(這個是準備同步的scn目標值), by distributed transaction remote logon, remote DB: LXSB.US.ORACLE.COM.
Client info : DB logon user LWZBDB, machine jbdb, program sqlplus@jbdb (TNS V1-V3), and OS user oracle
這個錯誤的原因是,在兩個庫透過db link進行分散式事務時，假設B庫的SCN值要高於A庫的SCN，因此要將B庫的SCN增同步到A庫，但是如果B庫的SCN過高，這樣同步到A庫之後，使得A庫面臨Headroom過小的風險，那麼A庫會拒絕同步SCN，這個時候就會報ORA-19706: Invalid SCN錯誤
而說起headroom則需要理解以下概念
1）.SCN的內部儲存方式：在Oracle內部，SCN分為兩部分儲存，分別稱之為scn wrap和scn base。實際上SCN長度為48位，即它其實就是一個48位的整數。只不過可能是由於在早些年通常只能處理32位甚至是16位的資料，所以人為地分成了低32位（scnbase）和高16位（scn wrap）。為什麼不設計成64位，這個或許是覺得48位已經足夠長了並且為了節省兩個位元組的空間：）。那麼SCN這個48位長的整數，最大就是2^48（2的48次方, 281萬億，281474976710656），很大的一個數字了。
2） Maximum Reasonable SCN：在當前時間點，SCN最大允許達到（或者說最大可能）的SCN值。也稱為Reasonable SCN Limit，簡稱RSL。這個值是一個限制，避免資料庫的SCN無限制地增大，甚至達到了SCN的最大值。
那麼SCN每秒最大可能增長速率是多少呢，這個跟Oracle版本有一定的關係，在11.2.0.2之前是16384（即16K），在11.2.0.2版本是32768（即32K）。在11.2.0.2的版本中有一個隱含引數，_max_reasonable_scn_rate，其預設值就是32768（不建議調整這個值）。如果按16K的最大值，SCN要增長到最大，要超過500年
這個值大約是這樣一個公式計算出來的：(當前時間-1988年1月1日(因為系統時間小於它oracle將不能啟動)）*24*3600*SCN每秒最大可能增長速率
SCN Headroom(頂部空間,可以理解為增長空間或者剩餘空間)： 這個是指MaximumReasonable SCN與當前資料庫SCN的差值。在alert中通常是以“天”為單位，這個只是為了容易讓人讀而已。天數=(Maximum Reasonable SCN-Current SCN)/16384/3600/24。 這個值就的意思就是，如果按SCN的最大增長速率，多少天會到達Maximum Reasonable SCN。但實際上即使如此，也不會到達Maximum Reasonable SCN，因為到那時MaximumReasonable SCN也增大了（時間增大），要到達Maximum Reasonable SCN，得必須以SCN最大可能速率的2倍才行。
2012年1月CPU或PSU補丁的一個重要變化是增加了_external_scn_rejection_threshold_hours引數，這個引數字面意思就是就是”拒絕外部SCN“的閾值。對於資料庫自身產生的SCN遞增是沒有影響的。
其最重要的功能就是防止dblink同步scn使得資料庫SCN headroom變小,這帶來的影響就是ORA-19706的錯誤出現的機率更高。
解決的辦法將_external_scn_rejection_threshold_hours這個隱含引數設定為較小的值，推薦的值是24，即1天。
查詢當前庫該引數的預設值
SQL> select * from v$version;
BANNER
—————————————————————-
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 – 64bi
PL/SQL Release 10.2.0.5.0 – Production
CORE 10.2.0.5.0 Production
TNS for Linux: Version 10.2.0.5.0 – Production
NLSRTL Version 10.2.0.5.0 – Production
SQL> select a.ksppinm name, b.ksppstvl value, a.ksppdesc description from x$ksppi a, x$ksppcv b where a.indx = b.indx and a.ksppinm like ‘_external_scn_rejection_threshold_hours’;
NAME
——————————————————————————–
VALUE
——————————————————————————–
DESCRIPTION
——————————————————————————–
_external_scn_rejection_threshold_hours
744
Lag in hours between max allowed SCN and an external SCN
也就是說外部SCN想要同步到本庫,則必須滿足同步後本庫scn即使以最快的增長速度（這裡是16K）也要744個小時(31天)才能達到最大允許scn,而alert日誌裡面顯示如果同步外部scn,則這個時間值將變成389小時,小於744,所以被拒絕,前臺則提示ORA-19706: invalid SCN錯誤
11.2.0.2以後的版本該值預設為24,即1天，說明從這個版本開始oracle放寬了這個限制，允許scn有更大的增長空間
SQL> select timestamp_to_scn(to_timestamp(‘2015-03-24 13:48:13‘,’yyyy-mm-dd hh24:mi:ss’)) src,to_number(‘0d05bcf8452b‘,’xxxxxxxxxxxx’)tar from dual;
SRC TAR
——————– ——————–
2395460 14318296384811
SQL> select (14318296384811-2395460)/16384/3600/24 hours from dual;
HOURS
——————–
10114.80683881335788
根據alert日誌顯示的報錯時間,計算該時間點的rsl
SQL> select (to_date(‘2015-03-24 13:48:13′,’yyyy-mm-dd hh24:mi:ss’)-to_date(‘1988-01-01′,’yyyy-mm-dd’))*24*3600*16384 rsl from dual;
RSL
——————–
14077317824512
SQL> select (
((to_number(to_char(cur_date,’YYYY’))-1988)*12*31*24*60*60) +
((to_number(to_char(cur_date,’MM’))-1)*31*24*60*60) +
(((to_number(to_char(cur_date,’DD’))-1))*24*60*60) +
(to_number(to_char(cur_date,’HH24′))*60*60) +
(to_number(to_char(cur_date,’MI’))*60) +
(to_number(to_char(cur_date,’SS’)))
) * (16*1024) rsl
from (select to_date(‘2015-03-24 13:48:13′,’yyyy-mm-dd hh24:mi:ss’) cur_date from dual);
RSL
——————–
14339199680512
兩種方法獲取的最大合理scn有差距，第一種是透過oracle內部計算得出，第二種以每月31天粗略估算，可以看出傳遞的scn值已經超過了第一種。
根據第二種方法計算的rsl繼續計算其對應的headroom
SQL> select
((((
((to_number(to_char(cur_date,’YYYY’))-1988)*12*31*24*60*60) +
((to_number(to_char(cur_date,’MM’))-1)*31*24*60*60) +
(((to_number(to_char(cur_date,’DD’))-1))*24*60*60) +
(to_number(to_char(cur_date,’HH24′))*60*60) +
(to_number(to_char(cur_date,’MI’))*60) +
(to_number(to_char(cur_date,’SS’)))
) * (16*1024)) – 14318296384811)
/ (16*1024*60*60*24)
) headroom
from (select to_date(‘2015-03-24 13:48:13′,’yyyy-mm-dd hh24:mi:ss’) cur_date from dual);
HEADROOM
——————–
14.76661943576954029
由此說明如果同步scn到14318296384811，則以16k的增長速度，只需要14天即可達到rsl 14339199680512，小於_external_scn_rejection_threshold_hours引數指定的744/24=31天
SQL> select (31-14.76661943576954029)*24 from dual;
(31-14.76661943576954029)*24
—————————-
389.601133541531033
修改heardroom閾值限制為24小時.
SQL> alter system set “_external_scn_rejection_threshold_hours”=24 scope=spfile;
shutdown immediate;
startup
SQL> select b.ksppstvl value from x$ksppi a, x$ksppcv b where a.indx = b.indx and a.ksppinm like ‘_external_scn_rejection_threshold_hours’;
VALUE
——————————————————————————–
24
SQL> select current_scn from v$database;
CURRENT_SCN
——————–
2407528
SQL> conn lwzbdb/lwzbdb
Connected.
SQL> select sysdate from dual@dl330781;
SYSDATE
———
24-MAR-15
SQL> conn / as sysdba
Connected.
SQL> select current_scn from v$database;
CURRENT_SCN
——————–
14318296497701 這裡可以看到scn在經過一個dblink查詢之後 大幅增長
Tue Mar 24 21:55:54 CST 2015
Advanced SCN by 14565321 minutes worth to 0×0d05.bcf9fda3, by distributed transaction remote logon, remote DB: LXSB.US.ORACLE.COM.
Client info : DB logon user LWZBDB, machine jbdb, program sqlplus@jbdb (TNS V1-V3), and OS user oracle
SQL> select to_number(‘0d05bcf9fda3′,’xxxxxxxxxxxx’),14565321/60/24 from dual;
TO_NUMBER(‘0D05BCF9FDA3′,’XXXXXXXXXXXX’) 14565321/60/24
—————————————- ——————–
14318296497571 10114.80625
10114.80625表示按照每秒16k的增長速度 ,需要經過10114.80625天scn才能從2407528增長到14318296497571 ,足見增幅之大
SQL> select
((((
((to_number(to_char(cur_date,’YYYY’))-1988)*12*31*24*60*60) +
((to_number(to_char(cur_date,’MM’))-1)*31*24*60*60) +
(((to_number(to_char(cur_date,’DD’))-1))*24*60*60) +
(to_number(to_char(cur_date,’HH24′))*60*60) +
(to_number(to_char(cur_date,’MI’))*60) +
(to_number(to_char(cur_date,’SS’)))
) * (16*1024)) – 14318296497571)
/ (16*1024*60*60*24)
) headroom
from (select to_date(‘2015-03-24 21:55:54′,’yyyy-mm-dd hh24:mi:ss’) cur_date from dual);
HEADROOM
——————–
15.10520876072071217
由此說明如果同步scn到14318296384811，則以16k的增長速度，需要15天才能達到2015-03-24 21:55:54時間點的rsl，大於_external_scn_rejection_threshold_hours引數指定的24/24=1天，所以即使其增幅巨大也被oracle透過

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

相關文章