Oracle SCN机制详细解读

SCN介绍
SCN即系统改变号（System Change Number），是在某个时间点定义数据库已提交版本的时间戳标记。 Oracle为每个已提交的事务分配一个唯一的SCN。 SCN的值是对数据库进行更改的逻辑时间点。 Oracle使用此编号记录对数据库所做的更改。在数据库中，SCN也可以说是无处不在，数据文件头，控制文件，数据块头，日志文件等等都标记着SCN。也正是这样，数据库的一致性维护和SCN密切相关。不管是数据的备份，恢复都是离不开SCN的。

SCN是一个6字节（48bit）的数字，其值为281,474,976,710,656（2^48），分为2个部分：

SCN_BASE是一个4字节（32bit）的数字
SCN_WRAP是一个2字节（16bit）的数字

Oracle Database 12.2 中，为了更彻底的解决SCN问题，Oracle 通过引入 BigSCN 的新特性，最终改变了 SCN 的算法。
BigSCN 新特性最根本的改变是：将原来 SCN 的存储位数从 6 字节扩展为 8 字节。对比起来，我们将原来的SCN算法称为 SmallSCN，现在的就是 BigSCN。

SCN 位数和设置
SCN值
6 Bytes最大可用
281,474,976,710,656
_big_scn_test_mode=4
562,949,953,421,312
BigSCN 最大可用
9,223,372,036,854,775,808
_big_scn_test_mode=4 的起点是 49 位，比较 原来的 48 位增进一位，这个起点就直接超越了过去的最大限制：
SQL> select power(2,49) scn from dual;
SCN
------------------------
562,949,953,421,312
BigSCN 最大可用值上升到一个天量数字，可以看到关于SCN问题，我们越来越不需要去担心了：
SQL> select power(2,63) scn from dual;
SCN
--------------------------------
9,223,372,036,854,775,808
虽然理论值做出了改变，SCN的地址空间也获得了增加，但是在实践中，这些新特性的获得是渐进式，在 12.2 之后，这些特性才会逐渐的释放出来。
在以下我的测试环境中，尝试将SCN推进到了极高的位置：
SQL> select current_scn scn from v$database;
SCN
--------------------------------
4,519,057,215,000,399
SQL> oradebug setmypid
Statement processed.
SQL> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [0600113B8, 0600113E8) = 00050F5D 00100E0F
将这个数字放到前面的表格中，大家可以看到SCN在实践中可以获得的海量值空间：
SCN 位数和设置
SCN值
6 位SmallSCN 最大
281,474,976,710,656
_big_scn_test_mode=4
562,949,953,421,312
测试环境 SCN 推进量
4,519,057,215,000,399
8 位BigSCN 最大
9,223,372,036,854,775,808
为了防止SCN的过度增加，Oracle 增加了内部函数去分析headroom，并通过 600 号错误的 kcm_low_scn_headroom_alert_1 抛出异常：
2018-03-23T18:12:01.849206+08:00
Errors in file /enmo12c/enmo12c/trace/enmo12c_ora_5259.trc (incident=174424) (PDBNAME=CDB$ROOT):
ORA-00600: internal error code, arguments: [2252], [4520092301887888], [4519517455400960], [], [], [], [], [], [], [], [], []
Incident details in: /enmo12c/enmo12c/incident/incdir_174424/e nmo12c_ora_5259_i174424.trc
2018-03-23T18:12:01.858629+08:00
Errors in file /enmo12c/enmo12c/trace/enmo12c_ckpt_5220.trc (incident=174304) (PDBNAME=CDB$ROOT):
ORA-00600: internal error code, arguments: [kcm_low_scn_headroom_alert_1], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /enmo12c/enmo12c/incident/incdir_174304/enmo12c_ckpt_5220_i174304.trc
这个启用了 BigSCN 的 12.2 数据库，当通过DB Link连接 11.2.0.4 的数据库时：
SQL> create database link enmo
connect to eygle identified by eygle using 'enmo';
Database link created.
SQL> select * from dual@enmo;
select * from dual@enmo
*
ERROR at line 1:
ORA-24442: SCN exceeds the capability of the target OCI database or client
这是一个新的错误号：
ORA-24442: SCN exceeds the capability of the target OCI database or client
Cause: An attempt was made to transfer a system change number (SCN) to an Oracle database or client that is older than Release 12.2 and the SCN exceeds the maximum value that such a system can handle.
Action: If needed, update the target database or client to Release 12.2 or higher.
有了BigSCN的新特性，在12.2版本之后，Oracle 关于SCN的种种问题，可能再也不容易被遇到了。
在官方文档上有一些描述与 8 Bytes的 BigSCN相关：
Data Pump Export and Data Pump Import support the new big SCN size of 8 bytes. See the Export FLASHBACK_SCN and the Import FLASHBACK_SCN parameters.
As of Oracle Database 12c release 2 (12.2), the SCN value can be a big SCN (8 bytes). You can also specify a big SCN when you create a dump file for an earlier version that does not support big SCNs because actual SCN values are not moved. See the following restrictions for more information about using big SCNs.

You cannot specify a big SCN for a network export or network import from a version that does not support big SCNs.
附录：
在kcm内核文件中，可以看到和BigSCN相关的一些函数调用：
bigscn: %c
comment:PROF: NO_PROFILE krsu_fal_rcv_hndl_bigscn()
comment:PROF: NO_PROFILE krsu_fal_send_hndl_bigscn()
krsu_fal_rcv_hndl_bigscn
krsu_fal_send_hndl_bigscn
krsu_rfs_rcv_hndl_bigscn
krsu_rfs_send_hndl_bigscn
krsu_rfx_rcv_hndl_bigscn
krsu_rfx_send_hndl_bigscn
-?comment:PROF: USED kcm_low_scn_headroom_alert()
kcm_low_scn_headroom_alert
kcm_low_scn_headroom_alert_1
每当SCN_BASE达到其最大值（2^32 = 4294967296）时，SCN_WRAP增加1，SCN_BASE将被重置为0,一直持续到SCN_WRAP达到其最大值，即2^16 = 65536。

SCN =（SCN_WRAP * 4294967296）+ SCN_BASE

SCN随着每个事务的完成而增加。提交不会写入数据文件，也不更新控制文件。当发生checkpoint时，控制文件更新，SCN被写入到控制文件。

当前的SCN可以通过以下查询获得：

select dbms_flashback.get_system_change_number scn from dual;

select current_scn from v$database;
四种重要的SCN
在理解这几种SCN之前，我们先看下oracle事务中的数据变化是如何写入数据文件的：

第一步：事务开始；
第二步：在buffer cache中找到需要的数据块，如果没找到，从数据文件中载入buffer cache中；
第三步：事务修改buffer cache的数据块，该数据被标识为“脏数据”，并被写入log buffer中；
第四步：事务提交，LGWR进程将log buffer中的“脏数据”的日志条目写入redo log file中；
第五步：当发生checkpoint，CKPT进程更新所有数据文件的文件头中的信息，DBWn进程则负责将Buffer Cache中的脏数据写入到数据文件中。
经过上述5个步骤，事务中的数据变化最终被写入到数据文件中。但是，一旦在上述中间环节数据库意外宕机了，在重新启动时如何知道哪些数据已经写入数据文件、哪些没有写呢？（同样，在DG、streams中也存在类似疑问：redolog中哪些是上一次同步已经复制过的数据、哪些没有）

SCN机制就能比较完善的解决上述问题。 SCN是一个数字，确切的说是一个只会增加、不会减少的数字。正是它这种只会增加的特性确保了 Oracle知道哪些应该被恢复、哪些应该被复制。
总共有4种SCN：

系统检查点（System Checkpoint）SCN
数据文件检查点（Datafile Checkpoint）SCN
结束SCN（Stop SCN）
开始SCN（Start SCN）


（1）System Checkpoint SCN

当checkpoint完成后，ORACLE将System Checkpoint SCN号存放在控制文件中。我们可以通过下面SQL语句查询：

select checkpoint_change# from v$database;

（2）Datafile Checkpoint SCN

当checkpoint完成后，Oracle将Datafile Checkpoint SCN存放在控制文件中。我们可以通过下面SQL语句查询所有数据文件的Datafile Checkpoinnt SCN。

select name,checkpoint_change# from v$datafile;

（3）Start SCN

Oracle将StartSCN存放在数据文件头中。这个SCN用于检查数据库启动过程是否需要做media recovery。我们可以通过以下SQL语句查询：

select name,checkpoint_change# from v$datafile_header;

（4）Stop SCN

ORACLE将StopSCN存放在控制文件中。这个SCN号用于检查数据库启动过程是否需要做instance recovery。我们可以通过以下SQL语句查询：

select name,last_change# from v$datafile;
在数据库正常运行的情况下，对可读写的online数据文件，该SCN号为NULL。

SCN与数据库启动：

在数据库启动过程中，当 System Checkpoint SCN、Datafile Checkpoint SCN 和 Start SCN 都相同时，数据库可以正常启动，不需要做media recovery。三者当中有一个不同时，则需要做media recovery.如果在启动的过程中，End SCN为NULL，则需要做instance recovery。Oracle在启动过程中首先检查是否需要media recovery，然后再检查是否需要instance recovery。

SCN与数据库关闭：

如果数据库的正常关闭的话，将会触发一个checkpoint，同时将数据文件的END SCN设置为相应数据文件的Start SCN。当数据库启动时，发现它们是一致的，则不需要做instance recovery。在数据库正常启动后，ORACLE会将END SCN设置为NULL.如果数据库异常关闭的话，则END SCN将为NULL。

为什么ORACLE在控制文件中记录System checkpoint SCN 号的同时，还需要为每个数据文件记录DatafileCheckpoint SCN？

A

如果有表空间read only，那么该表空间的所有datafile的start SCN和stop SCN将被冻结，这个时候就跟System Checkpoint SCN不一致，但在库open的时候是不需要做media recovery的，如果没有DatafileCheckpoint SCN就无法判断这些datafile是否是最新的。



可能遇到的SCN问题
首选我们看几个跟SCN有关的概念：
Reasonable SCNLimit（RSL）
RSL = (当前时间 - 1988年1月1日)*24*3600*SCN每秒最大可能增长速率
也就是从1988年1月1日开始，假如SCN按最大速率增长，当天理论上的最大值。

最大增长速率：在11.2.0.2之前是16384，在11.2.0.2及之后版本是32768

在11.2.0.2版本之后由_max_reasonable_scn_rate参数控制

该参数不建议修改。

SCN Headroom

Headroom（天） = (Reasonable SCN Limit -CurrentSCN)/ SCN每秒最大可能增长速率/3600/24
也就是如果SCN按最大速率增长，达到当前理论最大值需要的天数。这个值可以用来判断SCN增长速率是否过快。

那么，SCN Headroom如果获取呢？
参考MOS： Bug 13498243 -"scnhealthcheck.sql" script (文档 ID 13498243.8)，打上该BUG的patch之后，将在$ORACLE_HOME/rdbms/admin中增加scnhealthcheck.sql文件，该文件就是用来检查SCN是否正常。



另外还有一篇MOS文档，专门对该脚本的输出做了解释。即Installing, Executing and Interpreting output from the"scnhealthcheck.sql" script (文档 ID 1393363.1)。



执行该脚本，结果如下：


这个结果我们仍然无法得到该数据库的具体SCN Headroom，下面这个SQL是从scnhealthcheck.sql中找到的，可以直接查到SCN Headroom的值（indicator字段）。


Q&A
Q

针对上面的查询结果，是不是意味着过1647天之后，SCN就将达到最大值？

A

不会，因为1647天之后，Current SCN会变大，Reasonable SCN Limit同样也会变大，正常情况下，SCNHeadroon只会变大不会变小。



SCN headroom过小的问题

如果SCN正常增长，达到最大值大约可以用500年，SCN headroom的值也会随着时间的推移慢慢变大，但是可能由于BUG、用特殊手段人为调整、dblink传播导致SCN增长出现异常。但如果出现SCN headroom过小，alert log会出现警告：Warning: The SCN headroom for this database is only NN days!



原因定位：

1. 通过下面这篇文档里提供的脚本，该脚本类似于创建AWR，可以按snap_id对dba_hist_sysstat里的某个stat_name做统计，我们这里的Stat_name选择calls to kcmgas。
How to Extract the Historical Values of aStatistic from the AWR Repository (文档 ID 948272.1)

2. 通过查询V$ARCHIVED_LOG单位时间内scn变化

3. 通过上面两个方式得出的结果分析，如果是非持续突发增长，认为很可能是通过dblink引起；

4. 同时比较awr报告中“callsto kcmgas” 和“user commits”，如果user commits也是高速增长，很可能是自身引起；


kcmgas是Oracle分配scn的函数，在一个空库上做测试，可以看出每分配一次scn，calls to kcmgas的统计增加1，所以calls to kcmgas的量可以作为scn的增长量来分析。


ORA-19706: Invalid SCN错误



[1376995.1]里的介绍，在2012年1月CPU或PSU里增加_external_scn_rejection_threshold_hours参数，11.2.0.2及以后的版本，默认为1天即24小时，其他版本默认为31天即744小时，相当于把拒绝外部SCN连接的阈值调大了，因而更加容易引发ORA-19706错误。该参数对数据库自身产生的SCN递增没有影响。Bug 13554409 - Fix for bug13554409 [ID 13554409.8]的里对该问题也有介绍。



ORA-19706错误：最常见的就是拒绝dblink连接的时候，如A库跟B库通过dblink连接，A的SCN有通过人为调整增大许多，连接B库的时候，Oracle会判断该SCN传播过来之后，如果会导致SCN headroom小于_external_scn_rejection_threshold_hours设置的阈值，则拒绝连接
相关参考：SCN、ORA-19706错误和_external_scn_rejection_threshold_hours参数



如果打完2012年1月CPU或PSU后遇到ORA-19706错误，对于以下这些版本的数据库：

Oracle 10.2.0.5
Oracle 11.1.0.7
Oracle 11.2.0.2
Oracle 11.2.0.3
oracle建议给数据库安装2012年4月发布的PSU，并在安装该PSU的基础上，安装补丁13916709。如果是集群架构，同时给集群软件最新安装PSU。参数_external_scn_rejection_threshold_hours在2012年4月（包含2012年4月）以后发布的PSU/CPU中，11.2.0.2及以后的版本，是1天即24小时，其他版本是31天即744小时。其他版本：先升级到高版本，再按照上面的方法处理。



总结
如果发现SCN有异常，需要及时通过上述方法来打上最新的PSU，同时尽量少用DBLINK，从系统设计角度来讲也是不推荐这种系统间强耦合的设计。