预警揭秘：倒计时炸弹11.2.0.4前版本DB Link必须在2019年4月升级真相

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)

简单翻译一下就是：

2361478.1：在 2019年 4月前，Oracle 数据库需要更新到的最小 Patchset/PSU/RU 补丁； 2335265.1：使用 DB Link 的数据库，11.2.0.3 及之前版本必须应用的补丁

这两篇文章引发了用户的广泛关注，尤其是针对标题中使用的“Mandatory - 必须的”和“Before April 2019 - 在2019年4月之前”。

我注意到很多用户在问：Oracle 是如何让这样的问题在2019年4月后触发的？难道是 Oracle 在数据库中埋下了一个时间触发器？

经过我们的分析，这个时间约束的确存在，但是触发时间是：2019年6月23日。

接下来让我们一步一步来解析一下，在 2361478.1 文档的发布时间里可以看到，这个文档是 2018年2月15日创建发布的：

而在 2018年2月16日，Oracle 发布了 Oracle Database 18c 数据库，具体可以参考：Oracle 18c 数据库已经发布和新特性介绍。

所以，这篇文档是随着新版本而发布出来的，这也意味着新版本新特性导致 Oracle 的内部工作原理发生了重要的变化。

我们再来看看这篇文章宣布的内容，以下是关键内容：

What we are announcing（我们宣布的是）： All supported releases of Oracle Databases need to be patched to a minimum patchset/PSU level before April 2019 to ensure proper functioning of database links. 为确保数据库链正常工作，所有受支持的 Oracle 数据库需要在2019年4月之前修补到的最低 补丁集/ PSU。

影响范围：12.2.0.1及更高版本不受影响，11.2.0.4和12.1.0.2补丁集已经包含了必要的修复，已发布补丁程序可用于11.1.0.7和11.2.0.3版本。 其他版本无补丁，需要升级，否则低版本和新版本的其他库通过 DB Link 连接时可能遇到问题。

那么到底是什么变化引起了这个影响？关键的部分仅有以下一句话的描述：

What is the change introduced by the patches listed above? The patches listed above make the older databases capable of supporting increased SCN soft limit (i.e. support transactions with higher SCN rate) though the increased SCN soft limit only becomes effective at a later time (after April 2019). 为了允许更高的 SCN 增长率，Oracle 采用了新的 SCN soft limit 机制，补丁修正是使得之前版本能够支持这个新特性。该特性将在2019年4月之后生效，因此建议在11.2.0.4以下版本需要按照官方文档进行补丁升级。

简单来说，也就是 SCN 的算法要改变，最常见的是增长率，低版本和高版本必须保持同样的算法才能确保 DB Link 访问正常。

描述中所说的 Soft Limit 在文档中的描述如下，在 Oracle 11.2.0.2 之前这个限制是 16K：

"At any point in time, the Oracle Database calculates a "not to exceed" limit for the SCN a database can have used, based on the number of seconds elapsed since 1988, multiplied by 16,384. This is known as the 'Soft Limit'. If the soft limit is likely to be exceeded in the next SCN increment then Oracle will issue an ORA-0600 error and the process will be cancelled."

在SCN耗尽的问题出现之后，这个限制提升到32K：

在我的网站上，记录了一篇我在2006年写的文章，通过 DB Link 的查询会同步数据库的 SCN，也就是这个原理导致了后来很多 SCN 耗尽的 Headroom 问题：

[oracle@jumper oracle]$ sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.4.0 - Production on Tue Nov 7 21:07:56 2006
SQL> select dbms_flashback.GET_SYSTEM_CHANGE_NUMBER scn from dual;
       SCN
---------------
   5287824

那么会发生什么样的改变？

在 18c 中已经可以看到一些端倪，这样的新特性被引入：

Consistency Levels for Multi-Shard Queries You can specify different consistency levels for queries across multiple shards in a sharded database. For example, you might want some queries to avoid the cost of SCN synchronization across shards, and these shards could be globally distributed. Another use case is when you use standbys for replication and slightly stale data is acceptable for cross-shard queries, as the results could be fetched from the primary and its standbys. You can use the initialization parameter MULTISHARD_QUERY_DATA_CONSISTENCY to set different consistency levels when executing multi-shard queries across shards. This feature enables you to avoid the cost of SCN synchronization while executing multi-shard queries across shards and these shards potentially could be distributed globally. For multi-shard queries, this feature allows slightly stale data from the standby databases.

翻译过来就是：

多分片查询的一致性级别 您可以为分片数据库中多个分片的查询指定不同的一致性级别。 例如，您可能希望一些查询避免跨分片的 SCN 同步的成本，要知道这些分片可能是全局分布式的。 另一个用例是当您使用备用数据库时，对于跨分片查询可以接受稍陈旧的数据。 在分片上执行多分片查询时，可以使用初始化参数 MULTISHARD_QUERY_DATA_CONSISTENCY 设置不同的一致性级别。

• 通过此功能，您可以在跨分片执行多分片查询时避免 SCN 同步的成本，并且这些分片可能可以全球分发。
• 对于多分片查询，此功能允许从备用数据库稍微陈旧的数据。

这个功能目前是针对 Oracle Sharding 数据库的，也就是说，在跨 Shard 的查询中，可以避免 SCN 同步的成本。

这意味着什么？

• 通过进一步提升 SCN 增长率（超过32K）的上限约束或者避免同步，这可能意味着以前通过 DB Link 的 SCN 传播问题可以被更好的避免。
• 我们预计在 2019年4月，当 Oracle Database 19 版发布时，这些特性会获得全面支持，SCN 将全面摒弃16K 的增长率。

很多客户一直在提问，到底要修正什么 BUG？Oracle 在文档中没有说明，但是提出了最小补丁要求，不同版本的补丁应用矩阵：

那么这个列表中的最小补丁级修正的到底是什么？

经过分析，我们最终确认修复内容就是 BUG 14121009 中的内容，请注意上面列表中 Oracle 要求2019年4月前应用的最小补丁要求，和下图修正 BUG 14121009 的版本是完全相符的。如 11.2.0.3.9 、11.1.0.7.20 、以及 Windows 11.2.0.3 Patch 28、11.1.0.7 Patch 57。

那么这个补丁中到底引入了什么核心特性，改变了 Oracle SCN 的算法？

从说明中我们可以看到 Oracle 引入了一个重要的特性，这个特性就是：

SCN 兼容性特性 SCN Compatibility，而且在这个特性中设置了时间限制。这个特性要求这个补丁应用。

修改数据库 SCN 算法的命令是：

ALTER DATABASE SET SCN COMPATIBILITY.

严正警告：请不要在你的任何重要环境中进行测试，后果自负。

兼容性特性有4个选项，可以修改为：1、2、3 。

SQL> ALTER DATABASE SET SCN COMPATIBILITY 2; Database altered. SQL> ALTER DATABASE SET SCN COMPATIBILITY 3; Database altered.

SCN 算法向小值修改时，数据库需要重新启动：

那么最后的关键是，这一切到底和时间有什么关系？

经过我们的分析，得出的结论是：Oracle 为每个 SCN 的兼容性设置了时间点，也就是说，低级别的兼容性将在一定的时间后自动过期，所有的修正数据库都将在2019年6月23日直接跳级到兼容性 3 。3 级允许更高的 SCN 增长率，16K 将过时，32K 将可以被超越。所以可以预期，如果你的旧数据库不升级，连接 3 级兼容性的数据库，可能立刻就超出 SCN 的限制，访问被拒绝出错。

这一切就是因为在内核中，Oracle 引入了一个：Auto-RollOver 的特性，也就是说Oracle 为不同 SCN 的增长率设定了时间，自动过期，随着时间推移，用户会不知不觉的过度到新的 SCN 算法上来。

你可以通过 DBMS_SCN 包获得这些内部信息，我感觉数据库中被埋了一个定时炸弹，滴答滴答。。。

-- effective_auto_rollover_ts - timestamp at which rollover becomes effective -- target_compat - SCN compatibility value this database -- will move to, as a result of auto-rollover -- is_enabled - TRUE if auto-rollover feature is currently enabled

Oracle 在警告中之所以提示提示 2019年4月，我想是给用户留出了84天的余量。

基于以上分析，一些常见问题的答案是显然的：

1. 如果我是低版本之间的访问，一定会出问题吗？ 不会，如果都是未应用补丁的低版本数据库互访，不会出现问题；但是如果是未应用补丁的低版本和应用了补丁的高版本之间互访，就可能出问题。
2. 如果低版本和高版本互访，在2019年4月之后一定会出问题吗？ 不一定，跨 DB Link 的访问不一定会出现问题，尤其是 SCN 的增长率维持低位的数据库；但是由于算法的改变，很可能会出现问题，而且概率很高；
3. 为什么引入这样的修改和补丁？ 因为 SCN 是 Oracle 的核心机制，过去遇到的 Headroom问题必须获得彻底消除，所以算法需要调整，这是非常核心的改变。
4. 我们是否需要打补丁？

如果数据库全部维持在低版本，或者不通过 DB Link 互访，则无所谓; Oracle 也提供禁用该特性的功能，但是不保证之后不改变；鉴于11.2.0.4以下版本都属于不支持版本，强烈建议用户升级。

那么如果出现问题，会是什么样子的？在 MOS 上文档 1393360.1中，就有各种已知的描述，如果低版本的数据库 SCN 不能抬升，那么就可能遭遇：ORA-19706: invalid SCN 的错误。

Rejected the attempt to advance SCN over limit by 9374 hours worth to 0x0c00.00000f66, by distributed transaction remote logon, remote DB: REMDB.XX.ORACLE.COM. Client info : DB logon user ME, machine yy, program sqlplus@yy (TNS V1-V3), and OS user uuu

事实上，在这个文档的最后部分已经揭示了关于 SCN 新特性的变化，在新版本中，SCN 的增长率完全可以变成动态调节：

Warning: The SCN intrinsic growth rate has been consistently higher than system default 16384 per sec. for last 60 mins. Current SCN intrinsic growth rate is 24416 per sec., zas 7fffff! The Current SCN value is 3354492471, SCN Compat value is 1