1. 问题背景
根据Oracle的设计，目前所有Oracle数据库对SCN都有个上限的限制，其上限为当前时间与1988/01/01的秒数差*16k。对于指定的高版本数据库(10.2.0.5.12+patch 14121009 、11.1.0.7.20、11.2.0.3.9、11.2.0.4.*、12.1.0.2及以上)，这个上限计算方式由SCN COMPATIBILITY控制，当前值为1。通过这种方式，Oracle控制所有的数据库的SCN都不超过这个上限，从而保证数据库DB Link正常的相互访问。
但是，对于高版本数据库，Oracle将会在2019年6月23日后自动调整SCN COMPATIBILITY为3，调整之后，这些数据库内部的SCN上限增速会变成96k, 从而可能出现超出低版本的SCN的情况，如果发生这种情况，将会导致低版本数据库无法与高版本通过DB Link进行连接。
对此，我公司组织技术专家进行了详细的研究。
2. 高低版本的区分
如果已经有各个数据库的准确版本及PSU信息，可以通过以下的信息判断。高版本数据库包括以下：
Ø 所有12.1.0.2 及以上的数据库,含Oracle 18c
Ø 11.2.0.4 的数据库,包含所有PSU
Ø 11.2.0.3 的数据库，PSU至少到11.2.0.3.9
Ø 11.1.0.7 的数据库，PSU至少到 11.1.0.7.20
Ø 10.2.0.5 的数据库，PSU为10.2.0.5.12，且打上 14121009补丁（注意，10.2.0.5.13+的PSU在Oracle官网上并没有14121009可供下载，所以10.2.0.5.13+应当视为低版本）
其他的版本，都是属于低版本。 也就是说:
Ø Oracle 11.1.0.6及以前版本，含绝大多数Oracle 10g（除了10.2.0.5.12+14121009）.
Ø Oracle 11.1.0.7, PSU小于11.1.0.7.20
Ø Oracle 11.2.0.1/11.2.0.2
Ø Oracle 11.2.0.3, PSU小于11.2.0.3.9
如果没有准确的PSU, 由于高版本引入了SCN Compatibility新特性, 同时引入DBMS_SCN包用来管理SCN Compatibility，因此，我们可以通过直接检查数据库是否存在DBMS_SCN包来判断数据库是高版本还是低版本。
如果返回值是1，就说明是高版本。反之，如果返回值是0，则说明是低版本。
对于高版本的数据库，通过以下代码调用DBMS_SCN，可以获取当前的SCN Compatibility信息。
如果没有做过改动，那么，Current SCN compatibility为1，AUTO rollover 启用，时间为2019、06/23, 目标为3.
对于旧版本的数据库，我们可以认为SCN compatibility为1。
3. 潜在风险分析
根据Oracle的SCN上限算法，16k的速度和96k的速度的上限显然是不一样。
如果部分数据库在2019/06/23自动把SCN Compatibility改到3，那么这些数据库的SCN上限马上就会变成3.5E13 以上，而那些没有发生变化的，SCN上限10年内只能保持在1.8E13到2E13以内。设想一下，如果那些SCN Compatibility=3的数据库，因为一些特殊的原因(bug,手动设置等)，SCN异常增加，并超过了同样时间内的rate=16k算法下的SCN上限。两个数据之间需要进行DB Link通讯时，需要把SCN统一到高的那个，而由于超出了旧版本的上限，就会报错，并导致 DB Link通讯失败。
根据以上描述，发生问题需满足以下条件：
A. 两个数据库之间的SCN Compatibility不一致。
B. SCN Compatibility高的那个数据库，SCN发生异常增长，超出了SCN Compatibility低的数据库的SCN当前时间的上限
C. 两者需要通过DB Link相互连接。
4. 应对策略
根据上面的描述，为了避免高低版本之间DB Link互联出现问题，最彻底的方法是统一SCN Compatibility。因此，可以分为4种情况来考虑：
ü 如果数据库都是高版本数据库，不用处理。
ü 如果数据库是高版本为主，有部分低版本数据库，那么，强烈建议把低版本数据库升级到高版本（其中10.2.0.5应该是调整到10.2.0.5.12 + patch 14121009）。
ü 如果数据库都是低版本数据库，不用处理。但要考虑未来新版本数据库加入的问题（参考下面的内容）。
ü 如果数据库是低版本为主，且不方便升级；或者高版本为主，但低版本数据库无法升级，那么，建议统一到SCN Compatibility=1，并且关闭高版本的Auto Rollover功能，避免自动改变SCN Compatibility。
5. 调整Auto Rollover及SCN Compatibility的方法
如果决定把整体环境在2019/06/23后依然保留在SCN Compatibility=1的状态，需要在2019/06/23之前关闭新版本的数据库的SCN Compatibility Auto Rollover功能。
请注意，以下操作存在一定风险，不建议自行操作。需要的话，请联系云和恩墨技术支持。操作如下：
Begin DBMS_SCN.DISABLEAUTOROLLOVER; end; /
Alert log 中会出现以下信息：
Fri Mar 16 17:15:15 2018 Database SCN compatibility auto-rollover disabled
你也可以通过运行第二章节的脚本来确认，脚本应该会输出:
AUTO SCN compatibility rollover is DISABLED!!!
如果决定把整个环境保持在SCN compatibility=1的状态，那么，还需要注意2019/06/23之后加入的数据库。由于在Auto Rollover时间点之后安装，数据库安装完毕后默认SCN compatibility=3，因此，需要手动将改为SCN compatibility=1。此操作需要在Mount状态下进行，操作如下：
Begin DBMS_SCN.DISABLEAUTOROLLOVER; end; / shutdown immediate startup mount alter database set SCN COMPATIBILITY 1;
Alert日志中会出现以下信息：
Completed: alter database set scn compatibility 1
可以通过第二章提供的脚本进行确认。
6. 参考资料
Oracle Support 文档:
Oracle Databases Need to be Patched to a Minimum Patchset/PSU/RU level before April 2019 (Doc ID 2361478.1)
Mandatory Patching Requirement for Database Versions 11.2.0.3 or Earlier, Using DB Links (Doc ID 2335265.1)
数据和云公众号文章：
