原文：https://www.enmotech.com/web/detail/1/843/1.html
自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 2552錯誤，事務或查詢無法進行，影響業務運行。
這個問題直接引發的錯誤號：ORA-600 2252，在Google搜索上，我的2012年的歷史文章排在第一位：《ORA-600 2252 錯誤與SCN的一致性》，這篇文章描述了時間相關的一種情況。
針對 SCN 兼容性問題，我們曾經發布過一個系列的文章去闡述，所以在此不再贅述，以下鏈接供參考：
揭祕Oracle 11.2.0.4前版本DB Link必須在2019年4月前升級
解決方案：Oracle的DB Link問題及2019年4月升級路線詳述
Oracle全面修正了關於DB Link和SCN補丁的公告
Oracle 的 DBMS_SCN 修正以及SCN的auto-rollover新特性
（如鏈接跳轉網頁後仍無法查看，請點擊文章上方閱讀原文，即可查看)
在『DBASK』問答小程序中，用戶在線提問，專家隨時解答，每期會整理出一些重要的問題與回覆。
（如鏈接跳轉網頁後仍無法查看，請點擊文章上方閱讀原文，即可查看)
現在，我們首先看看官方對 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.2/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 (10381,312): EXTERNAL SCN ALERT: Advanced SCN by 1244395 minutes worth to 0x000016cbca6399b7, by outbound distributed transaction begin with returned scn
Session (10381,312): EXTERNAL SCN SOURCE: Outbound connection to DBID: xxxx GLOBAL_DB_NAME: DXHX
Session (10381,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,985,018,894,186 ==> 96k速率下SCN, 遠高於 16k速率下headroom
20190812-1814 23,985,018,894,301
20190812-1900 23,985,020,302,986
20190812-1947 23,985,022,403,528
20190812-2028 23,985,024,519,726
20190812-2028 23,985,024,522,32320190812-2119 23,985,027,176,419
該數據庫需要通過DB Link訪問低版本數據庫，由於SCN超出低版本數據庫SCN 的最大限制，導致ORA-00600 2252 錯誤。兩者之間DB Link無法再工作，嚴重影響業務：
ORA-00600: 內部錯誤代碼, 參數: [2252], [2834], [4076555716], [], [], [], [], []
由於 SCN 具有傳播性，所有和高 SCN 數據庫相連接的數據庫，都擡升了 SCN，這些數據庫連接低版本平臺都會出現錯誤，所有相關業務都可能遭受影響，這時候就只能通過緊急升級低版本數據庫來解決問題。
再次警示：請大家再次檢查自己管理的數據庫，是否還有高低版本混用的情況，如果有，重點關注是否有高版本數據庫的SCN超越16k headroom的情況，最好做成監控腳本，萬一有超過需要儘快升級舊版本。
整理了一個監控腳本供大家參考：https://www.modb.pro/download/3131
以上問題對於有大量分支機構數據庫的全國性企業，尤其需要重視。
此前我們低估了這一罕見異常可能出現的概率，根據墨菲定律，可能會發生的事情是一定會發生的。所以強烈建議大家要麼及時升級低版本的數據庫，要麼禁用高版本數據庫的 Auto-Rollover 特性（同時降低 SCN 兼容性級別至 1 ），避免問題出現時措手不及而影響業務，造成損失。
在處理此問題時有任何疑難，歡迎隨時諮詢雲和恩墨技術支持：010-59007017 。
想了解更多關於數據庫、雲技術的內容嗎？
快來關注“數據和雲”、“雲和恩墨”公衆號及“雲和恩墨”官方網站，我們期待與您一同學習與進步！
數據和雲小程序“DBASK”在線問答，隨時解惑，歡迎瞭解和關注！
