SCN增长过快的问题

最近的SCN增长过快的问题在各个通信公司搞的人人提心吊胆，这个是问题通常表现在使用的DB_LINK的数据库中出现。

SCN有两个极限：

1. hard limit,也就是SCN的最大值（281万亿），在ORACLE的自述中提到这个最大值在一两百年之后才会达到。当到达这个最大值之后数据库将再也启动不了， 只能重新建库才能解决。但是这个限制不是问题，我们现在还没有发现会使用这么长时间的数据库。

2.soft limit也就是ORACLE所说的Headroom，这是值的计算方法为：(sysdate – 1988年的秒数) * (16 * 1024)。ORACLE认为合理的情况下每秒钟SCN最大的增长数为16K。但是当使用的DB_LINK的数据库之间，数据库会同步SCN，使得数据库的SCN一下暴增。这也就是所说的SCN增长过快问题的原因。当SCN到达了Headroom后数据库会取消当前的事务，但是过一秒钟后Headroom增长16K，事务还可以继续执行。但是这对应用程序可能是致命的。

 

最终将最大合理SCN 减去当前数据库SCN，计算得出一个指标：HeadRoom。也就是SCN尚余的顶部空间，这个顶部空间最后折合成天数

 

 

SCN总是单调递增的序列， Oracle数据库最大可以使用到的SCN上限值是一个天文数字，目前该上限是281万亿，即281,474,976,710,656(2的48次方)。这是对SCN的硬限制，理论上一个数据库的SCN总是不能超过281万亿，以每秒16K的增速计算，花费557年SCN上限才会被耗尽，作为一个hard limit ，我们很少有机会触及。

 

Oracle数据库还存在一种 soft limit 即SCN headroom， 为了保证SCN的增长速度不要过于离谱，Oracle使用了一种基于时间的限量供应SCN的系统。

 

 

当2个数据库通过DBLINK相互交流访问时，他们会选用2者中当前Current SCN最大的一个来同步SCN， 譬如说数据库A 的SCN 是10000，而数据库B是20000，当2者发生DBLINK联系时，将会用最大的SCN (20000)来同步，数据库A的SCN将jump跳跃到20000。在一些环境中，往往不是本地数据库触发了SCN快速增长的bug，而是众多数据库中的某一个存在活跃的SCN BUG，而其他数据库与该问题数据库发生DBLINK联系后，就会因为SCN同步而经历 SCN headroom的的极速减少；换句话说就是一只老鼠坏了一锅汤，异常高的SCN会通过DBLINK传播给正常的数据库，这种传播往往呈爆炸式发展。

由于数据库总是会拒绝SCN超过当前的SCN上限，所以Oracle官方宣称Oracle数据库理论运行500年的SCN预备量不会受以上问题的影响。 但是受到传播的数据库仍可能由于自我保护的原因而宕机。

 

 

 

 

 

我可以通过如下的脚本检查数据库中的SCN Headroom的健康状况，当indicator持续的下降的时候我们应该提高警惕。正常的情况下它会保持在一个水平上下浮动或者持续的增长。

select version,
       date_time,
       dbms_flashback.get_system_change_number current_scn,
       indicator
  from (select version,
               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')))) * (16 * 1024)) -
               dbms_flashback.get_system_change_number) /
               (16 * 1024 * 60 * 60 * 24)) indicator
          from v$instance)

我现在手头的数据库的结果如下，这个数据库在一段时间内indicator最低到过4，发现在使用DB_LINK的数据库之间有时间不同步的现象，在同步时间后indicator持续的增长到现在的值。

VERSION           DATE_TIME                     CURRENT_SCN  INDICATOR
----------------- ------------------- --------------------- ----------
10.2.0.5.0        2012/08/07 10:36:08        12866639534536 62.1205277

 

源文档 <http://www.stanleylog.com/scn%E5%A2%9E%E9%95%BF%E8%BF%87%E5%BF%AB%E7%9A%84%E9%97%AE%E9%A2%98.html>