最近几个客户到遇到了ORA-19706: Invalid SCN

这个错误时由于SCN激增超过SCN HEADROOM导致。

SCN HEADROOM由在CPUJAN2012引入的一个参数_external_scn_rejection_threshold_hours控制，其作用是防止过高的CPU被传播过来。

1.该参数不一定能防止传播：
某客户的一套5个库组成的系统，11.2.0.3.1，其中一个库被传染了很高的SCN，而其他库正常，_external_scn_rejection_threshold_hours参数为24，导致业务发生故障。

2.有该参数后，在拒绝SCN传播的同时，会做CDMP
同样是这套系统，一个数据库被外围系统连接的比较多，其由于已经是11.2.0.3.1，包含了CPUJAN2012，其拒绝了SCN传播，但是其不停的写CDMP，当监控发现文件系统到达90%时，开始人工介入删除CDMP，删除速度跟不上产生速度。开始扩文件系统，由于扩的时候文件系统利用已经100%，扩文件系统动作卡死，数据库完全HANG住。

3.CPUJAN2012在增加该参数的同时，引入了其他导致SCN激增的问题
某系统，10204，打了10.2.0.4.11后，其SCN自增突然无原因变快，可能是触发了BUG：12780098。其可能是10204.11引入的问题

4.对于没有安装CPUJAN2012的数据库，从当前经验来看，其是安全的
其他两个客户，大量9i,10g的库，并且这些库都未安装CPUJAN2012，SCN HEADROOM低值1小时。
从现在观察的情况看，未安装CPUJAN2012的数据库正常，只是存在一些DBLINK的报错，未发生宕机
只有唯一一个安装了CPUJAN2012的10204的RAC库，其中一个节点经常性由于ORA-600[16384]宕机
所以，不要考虑盲目升级

5.当前已知的几个SCN自增速度过快的BUG：
12780098 12748240 13916709 13503598

6.处理该问题的步骤：
断开和外围系统的连接，如省局断开到总局的连接。
观察SCN是否持续下降，如果仍然持续下降，那么说明自己有问题，如果没有，说明受到其他地方的影响
如果自己有问题，使用下面SQL检查所有数据库的自增，隔离异常增长的数据库

CREATE OR REPLACE FUNCTION F_SLEEP(AN_SEC NUMBER)
RETURN NUMBER
AS
BEGIN
dbms_lock.sleep(AN_SEC);
RETURN AN_SEC;
END;
/
----------------------------------------------------
SET pagesize 999 linesize 130
break on ID
col info for a50
set timing on

WITH SAMPLE AS (
select /*+MATERIALIZE*/* from(
-- **************************************************************************
select /*+leading(b) use_nl(a)*/* FROM
-- view a beg -------------------------------------------------------------
(SELECT VALUE FROM v$sysstat WHERE NAME='calls to kcmgas'
    UNION ALL
   SELECT (0-F_SLEEP(10)) s1
     FROM dual ) a,
-- view b beg -------------------------------------------------------------
(select * from dual connect by rownum<=12) b
-- **************************************************************************
) where VALUE>0)
SELECT (VALUE-LAG(VALUE) OVER(ORDER BY VALUE))/10 KCMGAS FROM SAMPLE;

7.隔离出异常机器，加大监控即可，补丁不是必须的。
如果考虑要打补丁，一定要安装该版本最新的PATCHSET+PSU。10204最好能升级到10205。
并且整个DBLINK连接的网状机器都需要升级，只升级部分机器意义不大

ORA-19706: Invalid SCN 的一点总结