警告：ORA-00600 2252 错误正在SCN问题下不断爆发

« 安装 Oracle 时升级 CentOs 6 至 glibc 2.17 | Blog首页 | MySQL 实践：清理 binlog 日志的几种方法和常见问题 »

自2019年6月23日之后，Oracle启用了 SCN 自动 Auto-Rollover 的新特性，也就是自动调整了 SCN 的增长率算法（缺省32K 每秒，允许 SCN 最高以每秒 96K 计算）。注意，这里说的自动，是指不需要用户做任何主动的变化，数据库会自动调整。

在告警日志中，可以看到如下一行信息：

Database SCN compatibility auto-rollover - control file update
SCN compatibility changed from 1 to 3 (auto-rollover)

而这一调整生效之后，带来的一个可能的负面影响就是：当SCN增长率高的数据库连接增长率低的数据库，如果低版本的数据库无法同步拉高SCN，就会出现错误，事务或查询无法进行，影响业务运行。

这个问题直接引发的错误号是：ORA-600 2252 ，在Google搜索上，我的历史文章排在第一位：ORA-600 2252 错误与SCN的一致性。

针对这个问题，我们曾经发布过一个系列的文章去阐述，所以在此不再赘述，以下链接可以参考：

1. 揭秘Oracle 11.2.0.4前版本DB Link必须在2019年4月前升级

2.解决方案：Oracle的DB Link问题及2019年4月升级路线详述

3.Oracle全面修正了关于DB Link和SCN补丁的公告

4.Oracle 的 DBMS_SCN 修正以及SCN的auto-rollover新特性

现在，我们首先看看官方对 ORA-600 2552 错误的解释：

symptom: Query that uses a database link between two machines fails
cause: Argument [2252] for the ORA-00600 indicates that the System Change
Number (SCN) Oracle is calculating for a transaction is an unreasonable number.
The SCN is calculated based in part on the host system date. If the system
date is a LONG way off, the maximum possible value calculated for the SCN may
be impossibly large which would result in an ORA-600[2252].

翻译一下就是：

ORA-600 的 2552 号错误，表明 Oracle 为事务计算出来的 SCN 号是不合理的数值，其中的一个可能原因和系统时间相关，因为 SCN 的计算和时间有关，如果操作系统的时间错误，就可能导致这个问题。

当然，最近爆发的 2552 问题和时间无关，是和 SCN 的算法改变相关。对于高版本的数据库，SCN的合理值很高，而对于低版本的数据库，SCN的合理值较低，当通过 DB Link 连接这两个数据库时，因为分布式事务需要同步两个数据库之间的SCN，而低版本数据库不可抬升，就出现了 2552 错误。

当出现这个错误之后，意味着，高版本的数据库 SCN 已经跃升到高值，这个跃迁不可逆转，所以唯一的办法就是升级低版本的数据库；

如果在遇到这个错误之前，可以针对高版本的数据库禁用自动的SCN Roll-Over新特性，继续保持低增长率，则不会出现和低版本失联问题。

我们再来看一下出现这类问题的症状：

例如，主生产数据库为 12.1.0.2/11.2.0.4等高版本（SCN 增长率高），但还有核心库为10.2.0.4.0，为低版本（SCN增长率低）。

主生产数据库和核心库通过 DB Link 进行核心业务数据交互，决定业务成败运行的。

关键点：客户未在6/23前升级低版本，也没有关闭高版本的SCN Auto RollOver.
案发场景：某12.1.0.2的数据库，由于相连某个数据库发生SCN异常增长,通过DB Link被推高到同样位置。

2019-08-12T16:17:13.142309+08:00
Session (2038,312): EXTERNAL SCN ALERT: Advanced SCN by 1244395 minutes worth to 0x000016cbca6399b7, by outbound distributed transaction begin with returned scn
Session (2038,312): EXTERNAL SCN SOURCE: Outbound connection to DBID: xxxx GLOBAL_DB_NAME: DXHX
Session (2038,312): EXTERNAL SCN SOURCE: DBlink Name: XXXX, Connect String: (DESCRIPTION = (ADDRESS_LIST = (LOAD_BALANCE = no) (FAILOVER=ON) (ADDRESS = (PROTOCOL = TCP)(HOST = XXXX)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = XXXX)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = XXXX) (failover_mode=(type=select)(method=basic)))), Remote Machine: XXX

这个高版本数据库SCN异常跳增涨到2.39E13，而当前的16k速率SCN上限仅为1.66E13。

以下查询诊断输出了SCN的跳变时间，正常情况下数据库的 SCN 位于低位，但是在某个时间受其他数据库影响发生跳变：

Time SCN Changed By Time
------------- --------------------
20190812-1600 16,625,261,888,353
20190812-1601 16,625,261,888,724
20190812-1644 16,625,269,791,170
20190812-1728 16,625,271,982,215 ==> 16k速率下正常SCN, 离headroom 约13天
20190812-1813 23,965,018,894,186 ==> 96k速率下正常SCN, 远高于 16k速率下headroom
20190812-1814 23,965,018,894,301
20190812-1900 23,965,020,302,986
20190812-1947 23,965,022,403,528
20190812-2028 23,965,024,519,726
20190812-2028 23,965,024,522,323
20190812-2119 23,965,027,176,419

该数据库需要通过DB Link访问低版本数据库，由于SCN超出低版本数据库SCN 的最大限制，导致ORA-00600 [2252 错误。两者之间DB Link无法再接通，严重影响业务：