Oracle SCN headroom、ORA-19706和_external_scn_rejection_threshold_hours参数说明
一．SCN 相关知识
SCN可以说是Oracle中的很基础，但同时也是很重要的东西，它是一个单向增长的“时钟”，广泛应用于
数据库的恢复、事务ACID、一致性读还有分布式事务中。SCN还有以下一些知识点：
1）.SCN的内部存储方式：在
Oracle内部，SCN分为两部分存储，分别称之为scn wrap和scn base。实际上SCN长度为48位，即它其实就是一个48位的整数。只不过可能是由于在早些年通常只能处理32位甚至是16位的数据，所以人为地分成了低32位（scnbase）和高16位（scn wrap）。为什么不设计成64位，这个或许是觉得48位已经足够长了并且为了节省两个字节的空间：）。那么SCN这个48位长的整数，最大就是2^48（2的48次方, 281万亿，281474976710656），很大的一个数字了。
2） Maximum Reasonable SCN：在当前时间点，SCN最大允许达到（或者说最大可能）的SCN值。也称为Reasonable SCN Limit，简称RSL。这个值是一个限制，避免数据库的SCN无限制地增大，甚至达到了SCN的最大值。
这个值大约是这样一个公式计算出来的：(当前时间-1988年1月1日）*24*3600*SCN每秒最大可能增长速率。
当前时间减1988年1月1日的结果是天数，24表示1天24小时，3600表示1小时3600秒。不过这个公式里面“当前时间-1988年1月”部分并不是两个时间直接相减，而是按每月31天进行计算的（或许是为了计算简单，因此在Oracle内部可能要频繁地计算.
该计算公式可以在MOS文档：
Installing,Executing and Interpreting output from the “scnhealthcheck.sql” script [ID1393363.1]
中的提到的Patch：13498243中提供的脚本看到。
那么SCN每秒最大可能增长速率是多少呢，这个跟Oracle版本有一定的关系，在11.2.0.2之前是16384（即16K），在11.2.0.2版本是32768（即32K）。在11.2.0.2的版本中有一个隐含参数，_max_reasonable_scn_rate，其默认值就是32768（不建议调整这个值）。如果按16K的最大值，SCN要增长到最大，要超过500年。
[oracle@dave ~]$ ora _param _max_reasonable_scn_rate
NAME VALUE
--------------------------------------------------------------------------------
_max_reasonable_scn_rate 32768
[oracle@dave ~]$ ora si
SQL*Plus: Release11.2.0.3.0 Production on Sat Oct 20 19:39:48 2012
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise EditionRelease 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Miningand Real Application Testing options
SQL> selectdecode(bitand(DI2FLAG,65536),65536,'Y','N') using16 from x$kccdi2;
US
--
N
上面的SQL的结果只有在11.2.0.2及以上版本才有意义，结果为Y，表示使用的是16K的速率，否则是使用32K速率。
这个是我在11.2.0.3 版本里的一个测试，不过据老熊blog的说明，在11.2.0.2及之后的版本，从原来的32K SCN最大速率调整回了16K速率。不清楚老熊是在什么环境下测试的。我这的单机环境还是32k。
3） SCN Headroom： 这个是指MaximumReasonable SCN与当前数据库SCN的差值。在alert中通常是以“天”为单位，这个只是为了容易让人读而已。天数=(Maximum Reasonable SCN-Current SCN)/16384/3600/24。 这个值就的意思就是，如果按SCN的每大增长速率，多少天会到达Maximum Reasonable SCN。但实际上即使如此，也不会到达Maximum Reasonable SCN，因为到那时MaximumReasonable SCN也增大了（越时间增大），要到达Maximum Reasonable SCN，得必须以SCN最大可能速率的2倍才行。
4） SCN的异常增长： 通常来说，每秒最大允许的16K/32K增长速率已经足够了，但是不排除由于BUG，或者人为调整导致SCN异常增长过大。特别是后者，比如数据库通过特殊手段强制打开，手工把SCN递增得很大。同时Oracle的SCN会通过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。
5） 那么，如果是数据库本身操作而不是通过db link同步使得SCN的增长，其增长速率如何判断呢，这个可以通过
系统的统计量(AWR)“calls to kcmgas”和”DEBUG calls to kcmgas”来得到。kcmgas的意思是get and advance SCN，即获取并递增SCN。
6) 在两个库通过db link进行分布式事务时，假设B库的SCN值要高于A库的SCN，因此要将B库的SCN增同步到A库，但是如果B库的SCN过高，这样同步到A库之后，使得A库面临Headroom过小的风险，那么A库会拒绝同步SCN，这个时候就会报ORA-19706: Invalid SCN错误。
分布式事务，或者说是通过dblink的操作就会失败，即使是通过db link的查询操作。这里显然有一个阈值，如果递增SCN使得Headroom过小到什么值时，就会拒绝递增（同步）SCN？目前来看是这样：
如果打了2012年1月CPU或PSU补丁，11.2.0.2及以后的版本，是1天即24小时，其他版本是31天即744小时，打了补丁之后可以由隐含参数_external_scn_rejection_threshold_hou