名词解释
SCN是在某个时间点定义数据库已提交版本的时间戳标记。 Oracle为每个已提交的事务分配一个唯一的SCN。 SCN的值是对数据库进行更改的逻辑时间点。 Oracle使用此编号记录对数据库所做的更改。在数据库中，SCN也可以说是无处不在，数据文件头，控制文件，数据块头，日志文件等等都标记着SCN。也正是这样，数据库的一致性维护和SCN密切相关。不管是数据的备份，恢复都是离不开SCN的
寿命
如果SCN正常增长，达到最大值大约可以用500年
结构
SCN =（SCN_WRAP * 4294967296）+ SCN_BASE
SCN是一个6字节（6*8=48bit）的数字，其值为281,474,976,710,656（2^48），分为2个部分：
SCN_BASE是一个4字节（4*8=32bit）的数字
SCN_WRAP是一个2字节（2*8=16bit）的数字
每当SCN_BASE达到其最大值（2^32 = 4294967296）时，SCN_WRAP增加1，SCN_BASE将被重置为0,一直持续到SCN_WRAP达到其最大值，即2^16 = 65536
分类（4种）
系统检查点（System Checkpoint）SCN
- 当checkpoint完成后，ORACLE将System Checkpoint SCN号存放在控制文件中
- select checkpoint_change# from v$database;
数据文件检查点（Datafile Checkpoint）SCN
- 当checkpoint完成后，ORACLE将System Checkpoint SCN号存放在控制文件中
- select checkpoint_change# from v$database;
结束SCN（Stop SCN）
- 存放在控制文件中。这个SCN号用于检查数据库启动过程是否需要做instance recovery
- select name,last_change# from v$datafile;
开始SCN（Start SCN）
- 存放在数据文件头中。这个SCN用于检查数据库启动过程是否需要做media recovery
- select name,checkpoint_change# from v$datafile_header;
RSL /Reasonable SCNLimit /当前最高可用SCN
名词解释
- RSL = (当前时间 - 1988年1月1日)*24*3600*SCN每秒最大可能增长速率，每月按31天算也就是从1988年1月1日开始，假如SCN按最大速率增长，当天理论上的最大值。最大增长速率：在11.2.0.2之前是16384（16K），在11.2.0.2及之后版本是32768（32K）在11.2.0.2版本之后由_max_reasonable_scn_rate参数控制
查看相关参数
- select a.KSPPINM "参数名称",b.KSPPSTVL "当前值",b.KSPPSTDVL "默认值",a.KSPPDESC "描述" from x$ksppi a,x$ksppcv b where a.indx=b.indx and a.ksppinm like '_max_reasonable_scn_rate%';
- select a.KSPPINM "参数名称",b.KSPPSTVL "当前值",b.KSPPSTDVL "默认值",a.KSPPDESC "描述" from x$ksppi a,x$ksppcv b where a.indx=b.indx and a.ksppinm like '_external_scn_rejection_threshold_hours%';
版本区别
虽然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 /剩余日期
Headroom（天） = (Reasonable SCN Limit -CurrentSCN)/ _max_reasonable_scn_rate/3600/24
也就是如果SCN按最大速率增长，达到当前理论最大值需要的天数。这个值可以用来判断SCN增长速率是否过快，这个数值并不是指离SCN的最大值2^48的天数，而是指多少天后可能达到此时的最大值，一般随时间的动态变化，这个值很难达到
SCN健康度检测脚本（来自云和恩墨）：点击打开链接（也可以百度哦）
脚本的运行结果，可能是以下三种之一：
Result: A - SCN Headroom is good，数据库处于正常状态，建议短期内处理；
Result: B - SCN Headroom is low， 数据库SCN生成率过高，需要尽快处理；
Result: C - SCN Headroom is low， 数据库SCN生成率过高，需要紧急处理；
ORA-19706: Invalid SCN错误
该报错是因为远程数据库拒绝dblink连接导致。如A库跟B库通过dblink连接，A的SCN有通过人为调整增大许多，连接B库的时候，Oracle会判断该SCN传播过来之后，如果会导致SCN headroom小于_external_scn_rejection_threshold_hours设置的阈值，则拒绝连接
SCN暴增原因（headroom变小的原因）
- dblink传播（查询、修改等）（原因：基于分布式事务一致性原理，Oracle会对SCN时钟进行同步）
- Oracle BUG
- 特殊手段的人为调整
- 如果数据库版本＜11.2.0.4，请计划考虑升级到最新版本或打补丁，该补丁仅修复了一些BUG并添加了一些SCN相关的功能（如_external_scn_rejection_threshold_hours），但是该补丁也并不能彻底解决SCN问题，而且该补丁也带来的新问题是——更加容易引发ORA-19706错误
定位DB_LINK
在12C之前都不容易定位出源头，但是从12.2开始，可以用DBA_EXTERNAL_SCN_ACTIVITY 以及 DBA_DB_LINK_SOURCES 和 DBA_DB_LINKS 使我们能够跟踪这些跳转
- 在警告日志中过滤db_link的方法——点击打开链接
解决方法
目前为止没有一个非常彻底的好方法，即使12C等新版本也只是容许更快的SCN变化速度，但还是有可能会触发该问题
- 找出SCN污染源，并进行隔离处理（推荐）
- 减少或禁用dblink
- 避免＜11.2.0.2之前的版本和≥11.2.0.2的版本进行dblink互联
- 控制物化视图的使用
- 修改_external_scn_rejection_threshold_hours为一个更小的值，加快SCN变更时限，从而临时解决SCN问题，该方法有前提并且仅供应急时使用，ORACLE官方不建议修改此参数值
- 如果数据库版本＜11.2.0.4，请计划考虑升级到最新版本或打补丁，该补丁仅修复了BUG和添加了一些SCN相关的功能（如_external_scn_rejection_threshold_hours），但是该补丁并不能彻底解决SCN问题
相关网文链接
https://blog.csdn.net/songyundong1993/article/details/52514865
https://blog.csdn.net/stranger_huang/article/details/52928027
http://www.docin.com/p-1221558382.html
https://mp.weixin.qq.com/s/l1f7YhipsWNfaGv33rCqqg
