问题描述
在 Oracle 官方支持站点 MOS 上，最近发布了两篇告警文章，引发了用户的广泛关注，这两篇文章分别是：
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 的内部工作原理发生了重要的变化。
我们再来看看这篇文章宣布的内容，以下是关键内容：
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 同步的成本。
