客户的db报scn生成频率高，因此百度了一下，来自互联网，供学习使用，原文url:http://www.cnblogs.com/daduxiong/archive/2010/08/19/1803764.html
从接触oracle到使用过程中，始终能看到SCN的身影，在oracle的备份恢复原理中更是如此。由此看来SCN的重要性不言而喻呀，对其有个综合的了解能够有对其功能有清晰地认识，在oracle中SCN的种类不一中，对SCN理解的时候常常犯晕，偶尔这样，偶尔那样。说白了就是把多种SCN混淆在一起了。
如果结合控制文件，数据文件，redo等文件的dump内容来了解那几种重要的SCN，将会对其有更深的认识。
直接入题：
SCN: System Change Number
SCN是顺序递增的一个数字，在Oracle 中用来标识数据库的每一次改动，及其先后顺序。SCN的最大值是0xffff.ffffffff。
Oracle对SCN的管理
单节点的instance中，SCN值存在SGA区，由system commit number latch保护。任何进程要得到当前的SCN值，都要先得到这个latch。
RAC/OPS环境中
Oracle通过排队机制(Enqueue)实现SCN在各并行节点之间的顺序增长。具体有两种方法：
Lamport算法：又称面包房算法，先来先服务算法。跟很多银行采用的排队机制一样。客户到了银行，先领取一个服务号。一旦某个窗口出现空闲，拥有最小服务号的客户就可以去空闲窗口办理业务。
Commit广播算法：一有commit完成，最新的SCN就广播到所有节点中。
上述两种算法可以通过调整初始化参数max_commit_propagation_delay来切换。在多数系统 (除了Compaq Tur64 Unix)中，该参数的默认值都是700厘秒(centisecond)，采用Lamport算法。如果该值小于100厘秒，Oracle就采用广播算法，并且记录在alert.log文件中。
几种重要的SCN
Commit SCN
当用户提交commit命令后，系统将当前scn赋给该transaction。这些信息都反映在redo buffer中，并马上更新到redo log 文件里。
Offline SCN
除了System tablespace以外的任何表空间，当我们执行SQL>alter tablespace … offline normal命令时，就会触发一个checkpoint，将内存中的dirty buffer写入磁盘文件中。Checkpoint完成后，数据文件头会更新checkpoint scn和offline normal scn值。其中数据库文件头的checkpoint scn值可通过查询列x$kccfe.fecps得到。
如果执行SQL>alter tablespace …offline命令时采用temporary或 immediate选项，而不用normal选项时，offline normal scn会被设成0。这样当数据库重启后通过resetlog方式打开时，该表空间就无法再改回在线状态。
Checkpoint SCN
当数据库内存的脏数据块(dirty blocks)写到各数据文件中时，就发生一次checkpoint。数据库的当前checkpoint scn值存在x$kccdi.discn中。Checkpoint scn在数据库恢复中起着至关重要的作用。无论你用何种办法恢复数据库，只有当各个数据库文件的checkpoint scn都相同时，数据库才能打开。
虽然参数“_allow_resetlogs_corruption”可以在checkpoint scn不一致时强制打开数据库，但是这样的数据库在open后必须马上作全库的export，然后重建数据库并import数据。
Resetlog SCN
数据库不完全恢复时，在指定时间点后的scn都无法再应用到数据库中。Resetlog时的scn就被设成当前数据库scn，redo log也会被重新设置。
Stop SCN
Stop scn记录在数据文件头上。当数据库处在打开状态时，stop scn被设成最大值0xffff.ffffffff。在数据库正常关闭过程中，stop scn被设置成当前系统的最大scn值。在数据库打开过程中，Oracle会比较各文件的stop scn和checkpoint scn，如果值不一致，表明数据库先前没有正常关闭，需要做恢复。
High and Low SCN
Oracle的Redo log会顺序纪录数据库的各个变化。一组redo log文件写满后，会自动切换到下一组redo log文件。则上一组redo log的high scn就是下一组redo log的low scn。
在视图v$log_history中，sequence#代表redo log的序列号，first_change#表示当前redo log的low scn，列next_change#表示当前redo log的high scn。
代码
SQL> col recid format 9999 SQL> col requence# format 9999 SQL> col first_change# format 9,999,999,999,999 SQL> col next_change# format 9,999,999,999,999 SQL> select recid,sequence#,first_change#,next_change# from v$log_historywhere rownum<6;RECID SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# ----- ---------- ------------------ ------------------ 484 484 1,928,645,840,091 1,928,645,840,436 485 485 1,928,645,840,436 1,928,645,840,636 486 486 1,928,645,840,636 1,928,778,045,209 487 487 1,928,778,045,209 1,929,255,480,725 488 488 1,929,255,480,725 1,930,752,214,033
关于如何使用参数_allow_resetlogs_corruption，可参见文档http://www.sidibe.net/allow_resetlog.html
点滴总结：
1，在control file,redo log,data file中都存在SCN值；
2，数据库open时，检查control file中记录的SCN值与数据文件，redo log文件是否一致，如果是，数据库打开，否则，提示错误；假如数据文件SCN值小于control file中的SCN值则提示该数据文件需要介质恢复；
3，redo log 中存在低SCN，高SCN值两种，当前的redo log文件的高SCN值为无穷大；日志发生切换时，高SCN值更新为系统当前SCN值，新日志文件低SCN值为前日志文件高SCN值加1，高SCN值仍然为去穷大；数据库发生变化，则写redo log文件，同时SCN值会加1。
4，检查点发生时，CKPT更新数据文件头。
原文url:http://www.2cto.com/database/201308/237373.html
一．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_hours来调整。
而没有打补丁的情况下，视同此参数设为0，实际最小为1小时。由于Oracle9.2.0.8没有了最新的补丁集，显示也不会有这个参数，保持默认为1小时。注意这是一个静态参数。
所以打了2012年1月CPU或PSU补丁的一个重要变化是增加了_external_scn_rejection_threshold_hours参数，同时使11.2.0.2以下版本的数据库其Headroom的阈值增得较大。这带来的影响就是ORA-19706的错误出现的概率更高。
解决的办法将_external_scn_rejection_threshold_hours这个隐含参数设置为较小的值，推荐的值是24，即1天。从_external_scn_rejection_threshold_hours这个参数名的字面意思结合它的作用，可以说这个参数就是”拒绝外部SCN“的阈值。对于数据库自身产生的SCN递增是没有影响的。
7) 虽然11.2.0.2及之后的版本，其默认的每秒最大可能SCN增长速率为32K，这使得Maximum Reasonable SCN更大，也就是说其SCN可以增长到更大的值。那也就是可能会使11.2.0.2的库与低版本的数据库之间不能进行db link连接。或者是11.2.0.2的库不能与16K速率的（比如调整了_max_reasonable_scn_rate参数值）的11.2.0.2的库进行db link连接。
二．SCN Headroom 引发的问题
在安装了2012年1月发布的CPU或PSU补丁之后，增加了_external_scn_rejection_threshold_hours参数，同时使11.2.0.2以下版本的数据库其Headroom的阈值增得较大。
因此可能会出现如下现象：
1. 应用出现ORA-19706: invalid SCN错误。
2. 在alert日志中出现类似于：
Wed May 30 15:09:57 2012
Advanced SCN by 68093 minutes worth to 0×0ba9.4111a520, by distributedtransaction remote logon, remote DB:xxxx.
Client info : DB logon user xxxx, machine xxxx, program oracle@xxxx (J001), andOS user oracle
这样的警告。
3. 在alert日志中出现类似于：
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
这样的错误信息。
4. 在alert日志中出现类似于：
Sat Mar 17 05:57:45 2012
ALTER DATABASE OPEN
************************************************************
Warning: The SCN headroom for this database is only 38 days!
************************************************************
这样的信息。
5. 在MOS文档《ORA-19706 and Related Alert LogMessages [ID 1393360.1]》中还提到其他会出现在alert中的一些警告信息：
Warning - High Database SCN: Current SCN value is 0×0b7b.0008e40b, thresholdSCN value is 0×0b75.055dc000, If you have not previously reported this warningon this database, please notify Oracle Support so that additional diagnosis canbe performed.
WARNING: This patch can not take full effect until this RAC database has beencompletely shutdown and restarted again.Oracle recommends that it is done atthe earliest convenience.
6. 如果说以上的现象只是警告或应用级报错，影响范围有限，那么不幸的是如果遇到RECO进程在恢复分布式事务时遇到SCN问题，则可能使数据库宕掉，例如： Wed May 30 14:44:02 2012
Errors in file /oracle/admin/miboss/bdump/xxxx_reco_225864.trc:
ORA-19706: invalid SCN
Wed May 30 14:44:02 2012
Errors in file /oracle/admin/miboss/bdump/xxxx_reco_225864.trc:
ORA-00600: internal error code, arguments: [18348], [0x000000000], [485331304561], [], [], [], [], []
.........
RECO: terminating instance due to error 476
Intance terminated by RECO, pid s= 225864
三．2012年1月发布的CPU或PSU 带来的影响
1.2012年1月后发布的CPU或PSU补丁到底使数据库在SCN处理方面产生了什么样的变化？
答案是：增加了_external_scn_rejection_threshold_hours参数，11.2.0.2及以上版本的这个参数默认值是24，其他版本默认值是744。这样使11.2.0.2以下版本的数据库其Headroom的阈值增得较大。
2.这种变化对数据库有什么危害吗？
答案是：在一个具有很多系统的大型企业环境里面，db link使用很多，甚至有一些不容易管控到的数据库也在跟关键系统通过 db link进行连接，在这样的环境中，过高的SCN扩散到关键系统，而系统如果打了这个补丁，其Headroom阈值变大，那么就更容易出现ORA-19706错误，对db link依赖很严重的系统可能会导致业务系统问题，严重情况下甚至会宕库。不过通过设置隐含参数_external_scn_rejection_threshold_hours可解决这样的问题。所以，如果你安装了2012年1月的CPU或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 的脚本。
Installing,Executing and Interpreting output from the “scnhealthcheck.sql” script [ID1393363.1]
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
这里为什么是1988. Maclean 的blog 上有一段说明，直接引用过来：
在1988年发布了Oracle V6，首次实现了行级锁定，首次实现了数据库热备份，Oracle公司从Belmont移到加利福尼亚的redwood shores，并引入了PL/SQL。
能否在1988年之前运行Oracle V6以后的程序？ Maclean 的测试如下，将Oracle 10.2.0.5 数据的OS时间改到1988年之前，测试结果如下：
[root@vrh8 ~]# date -s "1985-07-2500:00:00"
Thu Jul 25 00:00:00 EDT 1985
SQL> startup;
ORA-01513: invalid current time returned byoperating system
[oracle@vrh8 ~]$ strace -ostartup.log -p 9935
Process 9935 attached - interrupt to quit
SQL> startup;
ORA-01513: invalid current time returned byoperating system
[oracle@vrh8 ~]$ oerr ora 01513
01513, 00000, "invalid current timereturned by operating system"
// *Cause: Theoperating system returned a time that was not between
// 1988 and 2121.
// *Action: Correct the time kept by theoperating system.
这里可以看到Oracle数据库可运行的时间区间其实是 1988-2121年，但是前面的说明也提高，SCN headroom 可以使用500年。这个作用就不那么明显了。
