Oracle SCN headroom、ORA-19706和_external_scn_rejection_threshold_hours参数说明(三)
或PSU补丁，请尽快设置此参数为建议的值24，极端情况下你可以设置为1。
3. alert中的那些提示或警告信息是BUG引起的吗？
答案是：这些提示或警告不是BUG引起的。它只是提醒你注意SCN过高增长，或者是你的Headroom较小（在Headroom小于62天时可能会提醒），引起你的重视。实际上根据MOS文档《System Change Number (SCN), Headroom,Security and Patch Information [ID 1376995.1]》的说法，这个补丁修复了SCN相关的一些BUG。
如果非要说BUG，可以勉强认为补丁安装后新增的参数_external_scn_rejection_threshold_hours其默认值过大。Bug 13554409 - Fix for bug 13554409 [ID 13554409.8]就是说的这个问题。不过这个问题已经在2012年4月的CPU或PSU补丁中得到修复。
4.解读一下alert日志中的一些信息
4.1 信息：
Wed May 30 15:09:53 2012
Completed crash recovery at
Thread 1: logseq 3059, block 19516, scn 12754630269552
2120 data blocks read, 2120 data blocks written, 19513 redo blocks read
…..
Wed May 30 15:09:57 2012
Advanced SCN by 68093 minutes worth to 0×0ba9.4111a520, by distributed transactionremote logon, remote DB:xxxx.
Client info : DB logon user xxxx, machine xxxx, program oracle@xxxx (J001), andOS user oracle
这里是说，SCN向前（跳跃）递增了68098分钟，其递增后的SCN是0×0ba9.4111a520。注意这里的分钟的计算就是根据SCN每秒最大可能增长速率为16K来的。我们计算一下：
0×0ba94111a520转换成10进制12821569053984。
在alert日志中，这个信息是刚打开数据库的时候，所以 crash recovery完成时的scn可以做为近似的当前SCN，其值为12754630269552：
(12821569053984-12754630269552)/16384/60=68093.65278320313
这里16384值的是SCN每秒最大可能增长速率，可以看到计算结果极为接近。
我们再来计算一下这个SCN的headroom是多少:
SQL> select
2 ((((
3 ((to_number(to_char(cur_date,'YYYY'))-1988)*12*31*24*60*60) +
4 ((to_number(to_char(cur_date,'MM'))-1)*31*24*60*60) +
5 (((to_number(to_char(cur_date,'DD'))-1))*24*60*60) +
6 (to_number(to_char(cur_date,'HH24'))*60*60) +
7 (to_number(to_char(cur_date,'MI'))*60) +
8 (to_number(to_char(cur_date,'SS')))
9 ) * (16*1024)) - 12821569053984)
10 / (16*1024*60*60*24)
11 ) headroom
12 from (select to_date('2012-05-30 15:09:57','yyyy-mm-dd hh24:mi:ss') cur_date from dual);
HEADROOM
----------
24.1496113
可以看到结果为24天，由于这个时候_external_scn_rejection_threshold_hours参数值为24，即1天，所以虽然有这么大的跳跃，但SCN仍然增长成功。
4.2 信息：
Wed May 30 12:02:00 2012
Rejected the attempt to advance SCN over limit by 166 hours worth to0×0ba9.3caec689, by distributed transaction remote logon, remote DB: xxxx.
Client info : DB logon user xxxx, machine xxxx, program oracle@xxxx (J000), andOS user oracle
在这个信息中，拒绝了db link引起的SCN增加。计算一下这个SCN的headroom：
0×0ba93caec689转换成10进制是12821495465609
当前时间是2012-05-30 12:02:00，
SQL> select
2 ((((
3 ((to_number(to_char(cur_date,'YYYY'))-1988)*12*31*24*60*60) +
4 ((to_number(to_char(cur_date,'MM'))-1)*31*24*60*60) +
5 (((to_number(to_char(cur_date,'DD'))-1))*24*60*60) +
6 (to_number(to_char(cur_date,'HH24'))*60*60) +
7 (to_number(to_char(cur_date,'MI'))*60) +
8 (to_number(to_char(cur_date,'SS')))
9 ) * (16*1024)) - 12821495465609)
10 / (16*1024*60*60*24)
11 ) headroom
12 from (select to_date('2012-05-30 12:02:00','yyyy-mm-dd hh24:mi:ss') cur_date from dual);
HEADROOM
----------
24.0710752
由于这个时候_external_scn_rejection_threshold_hours参数值为744，即31天，计算出的headroom在这个阈值之内，因此拒绝增加SCN。
(31-24.0710752)*24=166.2941952，正好是166小时。
四．为什么是1988年
在MOS的文档里提供了一个检查SCN 的脚