SCN Headroom

1. 为什么要检查SCN Headroom

Oracle对于SCN的增长有个小小的限制，即当前HeadRoom，注意，用了 当前 两个字，表示这个HeadRoom是实时计算出来的，计算方式为：1988年距当前时间的秒数 * 16k，所以HeadRoom是按照秒，每秒16K的涨幅在增加，每个时刻，Oracle会将SCN与HeadRoom进行比较，如果事务SCN超过HeadRoom，当前事务可能失败，但随着时间的流逝，HeadRoom也在不断增长，只要你的后续SCN增长不触碰到HeadRoom，就没问题。另外触碰到HeadRoom与用尽SCN是两码事，按照16K/秒的速度，SCN需要500年才能用尽。Oracle对于SCN的增长有个小小的限制，即当前HeadRoom，注意，用了 当前 两个字，表示这个HeadRoom是实时计算出来的，计算方式为：1988年距当前时间的秒数 * 16k，所以HeadRoom是按照秒，每秒16K的涨幅在增加，每个时刻，Oracle会将SCN与HeadRoom进行比较，如果事务SCN超过HeadRoom，当前事务可能失败，但随着时间的流逝，HeadRoom也在不断增长，只要你的后续SCN增长不触碰到HeadRoom，就没问题。另外触碰到HeadRoom与用尽SCN是两码事，按照16K/秒的速度，SCN需要500年才能用尽。

那么哪些原因会导致数据库触碰到HeadRoom呢？

1.Oracle Bug，导致自身SCN异常增长
2.DBlink传染
对于1，好理解，Bug出来，猪飞上天都不足为奇；对于2，就是受限于Oracle DBLink的工作机制，每一次跨库查询，都算一个分布式事务，他们需要一个统一的SCN，两个库的SCN不一样，就同步成一样。如果一个SCN异常增长的库放在你的生产环境里，又有DBlink查询的话，这片数据库的SCN增长基本都会异常。所以当DBLink触发的SCN增长超过限定值时，对端数据库可能会拒绝这次事务。

在出现异常时，尤其是当使用DB Link跨数据库查询时，SCN会被同步，数据库之间可以通过dblink来进行数据访问，当通过dblink进行业务提交的时候，由于数据库之间存在不同的SCN，因此，为了让事务一致，Oracle将会以两者之间较大的SCN来进行同步，更新dblink两端的数据库SCN。但是，如果源数据库出现SCN生成率过高的问题，随着业务的不断运行，SCN的异常就会通过dblink传染到其他相关的数据库，而dblink使用的频率越大，这种传染的速度也就越快。如果企业内部存在网状的dblink结构，那么这将很容易将SCN的问题扩大到全网，极端情况下会引起大范围的宕机。

2. 巡检语句
   SELECT
   ((((((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;
3. 语句分析
   前面是计算当前时间到1988年1月1日的时间值（换算成秒），16*1024是每秒产生的SCN,DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER是当前的SCN，两者相减得出剩余可用SCN数，最后得出结果为SCN可用天数。