在 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日建立釋出的：
是以，這篇文檔是随着新版本而釋出出來的，這也意味着新版本新特性導緻 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 問題：
那麼會發生什麼樣的改變？
在 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;
SCN 算法向小值修改時，資料庫需要重新啟動：
那麼最後的關鍵是，這一切到底和時間有什麼關系？
經過我們的分析，得出的結論是：Oracle 為每個 SCN 的相容性設定了時間點，也就是說，低級别的相容性将在一定的時間後自動過期，所有的修正資料庫都将在2019年6月23日直接跳級到相容性 3 。3 級允許更高的 SCN 增長率，16K 将過時，32K 将可以被超越。是以可以預期，如果你的舊資料庫不更新，連接配接 3 級相容性的資料庫，可能立刻就超出 SCN 的限制，通路被拒絕出錯。
這一切就是因為在核心中，Oracle 引入了一個：Auto-RollOver 的特性，也就是說Oracle 為不同 SCN 的增長率設定了時間，自動過期，随着時間推移，使用者會不知不覺的過度到新的 SCN 算法上來。
你可以通過 DBMS_SCN 包獲得這些内部資訊，我感覺資料庫中被埋了一個定時炸彈，滴答滴答。。。
Oracle 在警告中之是以提示提示 2019年4月，我想是給使用者留出了84天的餘量。
基于以上分析，一些常見問題的答案是顯然的：
如果我是低版本之間的通路，一定會出問題嗎？
不會，如果都是未應用更新檔的低版本資料庫互訪，不會出現問題；但是如果是未應用更新檔的低版本和應用了更新檔的高版本之間互訪，就可能出問題。
如果低版本和高版本互訪，在2019年4月之後一定會出問題嗎？
不一定，跨 DB Link 的通路不一定會出現問題，尤其是 SCN 的增長率維持低位的資料庫；但是由于算法的改變，很可能會出現問題，而且機率很高；
為什麼引入這樣的修改和更新檔？
因為 SCN 是 Oracle 的核心機制，過去遇到的 Headroom問題必須獲得徹底消除，是以算法需要調整，這是非常核心的改變。
我們是否需要打更新檔？
如果資料庫全部維持在低版本，或者不通過 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
如果在此問題上需要進一步的協助，請聯系雲和恩墨的技術團隊，更詳細的解決方案将提供給我們的服務客戶。也歡迎加入我們的微信群進一步的讨論該問題。
原文釋出時間為：2018-03-14
本文作者：蓋國強