Oracle db_link引发的ORA-19706:invalid SCN错误

看一下ORA-19706错误的解释:可以看到too large是产生该问题的原因之一

$oerr ora 19706

19706, 00000, "invalid SCN"

// *Cause:  The input SCN is either not a positive integer or too large.

// *Action: Check the input SCN and make sure it is a valid SCN.



我们先来了解下SCN

1: SCN



SCN是当Oracle数据库更新后,由DBMS自动维护去累积递增的一个数字。

在Oracle内部,SCN分为两部分存储,分别称之为scn wrap和scn base。SCN长度为48位,即它其实就是一个48位的整数。那么SCN这个48位长的整数,最大就是 2^48(2的48次方, 281万亿,281474976710656),这是很大的一个数字了。 据推算这个值可以保证Oracle数据库理论上可以处理500年的数据。
   


      Maximum Reasonable SCN:在当前时间点,SCN最大允许达到的SCN值被称为" Maximum Reasonable SCN“(最大合理SCN),也称为Reasonable SCN Limit,简称RSL。这个值是一个限制,避免数据库的SCN无限制地增大,甚至达到了SCN的最大值。该值可以通过如下方式计算:



col scn for 999,999,999,999,999,999
select
(
    (
        (
            (
                (  
                    (
                        to_char(sysdate,'YYYY')-1988
                    )*12+
                to_char(sysdate,'mm')-1
                )*31+to_char(sysdate,'dd')-1
            )*24+to_char(sysdate,'hh24')
        )*60+to_char(sysdate,'mi')
    )*60+to_char(sysdate,'ss')
) * to_number('ffff','XXXXXXXX')/4 scn
from dual
/

SCN Headroom这个是指Maximum Reasonable SCN与当前数据库SCN的差值。在alert中通常是以“天”为单位,这个只是为了容易让人读而已。天数=(Maximum Reasonable SCN-Current SCN)/16384/3600/24。这个值就的意思就是,如果按SCN的每大增长速率,多少天会到达Maximum Reasonable SCN。但实际上即使如此,也不会到达Maximum Reasonable SCN,因为到那时Maximum Reasonable SCN也增大了(越时间增大),要到达Maximum Reasonable SCN,得必须以SCN最大可能速率的2倍才行。


关于SCN Headroom, Oracle提供了一个脚本 scnhealthcheck.sql 用于检查数据库当前SCN的剩余情况



SCN的异常增长几种类型

1: 数据库内部BUG触发,

2:人为调整导致SCN异常增长过大,比如数据库通过特殊手段强制打开,手工把SCN递增得很大。

3 : 通过db link传播。如果A库通过db link连接到B库,如果A库的SCN高于B库的SCN,那么B库就会递增SCN到跟A库一样,反之如果A库的SCN低于B库的SCN,那么A库的SCN 会递增到跟B库的SCN一样。也就是说,涉及到db link进行操作的多个库,它们会将SCN同步到这些库中的最大的SCN。

客户场景的实际情况来看,属于第3种类型导致SCN异常增长。B库的SCN值要高于A库的SCN,因此要将B库的SCN增同步到A库,但是如果B库的SCN过高,这样同步到A库之后, 使得A库面临Headroom过小的风险,那么A库会拒绝同步SCN,这个时候就会报ORA-19706: Invalid SCN错误。




解决方法:

  1: 由于B库数据库版本为10.2.0.4. Oracle推荐解决SCN增长异常的最佳办法就是给B库打上相应的补丁或者直接升级到10205并打上最新的PSU .但由于B库和A库不是同一个中心管辖的系统,而且B库也不允许升级带来的风险和停机时间。

 2: 只能委曲求全从A库下手,由于A库是最新升级的oracle 11203版本,通过隐含参数_external_scn_rejection_threshold_hours来处理这个问题,

在11203版本中,该值默认为24,单位小时。从_external_scn_rejection_threshold_hours这个参数名的字面意思结合它的作用,可以说这个参数就是”拒绝外部SCN“的阈值。极端情况下可以设置为1。

在本案例中,减少该隐含参数的值,我们将该值设置为1,重启数据库后,ORA-19706报错得以解决。



来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26655292/viewspace-2086023/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/26655292/viewspace-2086023/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值