SCN警报

SCN Headroom警报

项目巡检时，发现了有关于SCN的headroom警报,这是我第一次在项目中遇到SCN相关的警报，遂记录下来解决过程以及SCN相关知识。

SCN介绍

concept文档中是这么介绍：
A system change number (SCN) is a logical, internal timestamp used by Oracle Database. SCNs order events that occur within the database, which is necessary to satisfy the ACID properties of a transaction. >
Oracle Database uses SCNs to mark the SCN before which all changes are known to be on disk so that recovery avoids applying unnecessary redo. The database also uses SCNs to mark the point at which no redo exists for a set of data so that recovery can stop.

SCN是Oracle数据库的逻辑时间戳，用来保证Oracle中的事物和数据一致性。SCN在数据库中是一个单一的不断的随着数据库一致性状态的改变而自增的序列。

查看SCN:
SELECT current_scn scn FROM v$database;

SCN两个极限

SCN会有两个极限，一个是hard limit,一个是soft limit,即headroom。

Hard Limit

SCNs occur in a monotonically increasing sequence, and there is a very large upper limit to how many SCNs an Oracle Database can use - that limit is currently 281 trillion, or specifically 281,474,976,710,656 (is 2^48) SCN values.
Given that there is an upper limit, it is important that any given Oracle Database does not run out of available SCNs. The Oracle Database uses a time based rationing system to ensure that this does not happen.

最大值281万亿，oracle确保在不出现bug的时候不会达到，理论上最大值需要一两百年才能达到，当到这个最大值时，数据库将再也启动不了，只能重新建库解决。

Headroom

At any point in time, the Oracle Database calculates a "not to exceed" limit for the number of SCNs a database can have used, based on the number of seconds elapsed since 1988, multiplied by 16,384. This is known as the database's current maximum SCN limit. Doing this ensures that Oracle Databases will ration SCNs over time, allowing over 500 years of data processing for any Oracle Database.
The difference between the current SCN the database is using, and the "not to exceed" upper limit, is known as the SCN headroom. For almost all Oracle Databases, this headroom is constantly increasing every second.

计算方法（sysdate-1988年的秒数）*（16*1024）。oracle认为合理的情况下每秒钟SCN最大的增长数为16384。

SCN警报信息

SCN的警报信息会出现在告警日志中，通过相关MOS提供的脚本也能检查出来。
当告警日志中出现了以下的信息，即代表出现了Headroom问题了。

Warning信息

Warning信息
SCN跳跃信息

SCN跳跃信息

由图中信息可知当前数据库SCN存在跳跃信息，向前跳跃7862分钟，到了0x0e1332b78159(转化为十进制是 15475618054489)，远端机器HAJC，登录用户EPOINTOA8_HA，主机名、程序等信息。
scnhealthcheck.sql脚本

The "scnhealthcheck.sql" script can be downloaded here: Patch:13498243.
If you install the patch then it will create "scnhealthcheck.sql" in the $ORACLE_HOME/rdbms/admin directory.
Alternatively you can use the script directly from the unzipped patch without actually installing it in your $ORACLE_HOME.

需要打补丁[Patch:13498243](https://support.oracle.com/epmos/faces/ui/patch/PatchDetail.jspx?parent=DOCUMENT&sourceId=1393363.1&patchId=13498243)，脚本自动创建到$ORACLE_HOME/rdbms/admin下。

SQL语句检查

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)

使用以上SQL检查，根据INDICATOR列的值来判定Headroom还可以使用多久，这应该是一个趋于稳定的值，当小于10天的时候应该提高注意，系统可能出现问题，而这个项目上的INDICATOR值只有6.1。

解决办法

在上一章警报信息中的SCN跳跃信息栏中已经解析了日志中的一些信息，可以用来解决问题。
我们下面应该找到HAJC这个库和POINTOA8_HA用户，既然是远端信息连接到这台HAOA数据库上，那肯定是通过Dblink的方式。
所以，在HAJC库中查找对应的Dblink信息，信息匹配，确实存在Dblink。

Dblink有可能会导致SCN爆炸增长，当两个数据库通过Dblink相互访问时，他们会选用两者中当前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传播给正常的数据库，这种传播往往呈爆炸式发展。

打2012年1月后发布的CPU或PSU补丁
补丁增加了_external_scn_rejection_threshold_hours参数，通常设置该参数为24小时
源头解决
将对应的Dblink源头找到并禁用

对于此项目的情况，分析Dblink的使用功能是做数据同步，和相关负责人讨论后可以用数据交换平台替代Dblink，于是决定禁用此Dblink，来解决问题。

看下删掉Dblink同步后的效果。

5月27日检查Headroom只剩下6.1天，5月31日drop掉此Dblink,6月1日检查，Headroom增加到11天，接下来还会继续释放，SCN恢复使用正常，趋于稳定。