環境：OEL 5.7 + Oracle 10.2.0.5
背景：Oracle釋出的兩篇關於2019年6月份將自動調整高版本資料庫的SCN COMPATIBILITY的MOS文章引起了很多客戶的恐慌，尤其是起初Oracle對10g版本未提供任何補丁。我這裡結合業界多位Oracle ACE專家的系列文章，在自己的實驗環境做了系列驗證總結。

• 1.什麼都不做會怎樣？
• 2.最簡單的做法是啥？
• 3.常用查詢驗證方法
• 4.總結

1.什麼都不做會怎樣？

結合多位專家的結論：

Oracle 將會在 2019 年 6 月 23 日後自動調整高版本的資料庫 SCN COMPATIBILITY 為 3，調整之後，這些資料庫內部的 SCN 上限增速會變成 96k, 從而可能出現超出低版本的 SCN 的情況，如果發生這種情況，將會導致低版本資料庫無法與高版本透過 DB Link 進行連線。

具體解釋下，這裡所說的高版本，可以理解為是：11.2.0.4及以上版本，同時也包含其他低於此版本但有補丁可以應用修正的版本；而低版本就是剩下的版本。

也就是說：如果確認環境內沒有所謂的高版本，理論是可以什麼都不做的。但是如果你不能保證未來生產環境內不會建立新的高版本且有dblink連線互動，就不能一直坐視不管。

2.最簡單的做法是啥？

這個要看你的實際情況。
2.1 無需關註
如果你的環境全是高版本，或全是低版本，且未來不會有變化，那自然無需關註。

2.2 禁用高版本的自動調整
如果你的環境絕大部分都是低版本，只有個別的高版本，可以考慮將高版本的SCN自動調整禁用掉：

begin
    DBMS_SCN.DISABLEAUTOROLLOVER;end;
/

如果是在2019年6月以後安裝的新的高版本，預設就是SCN COMPATIBILITY 為 3，這就需要在mount狀態調低相容性：

ALTER DATABASE SET SCN COMPATIBILITY 1;

或者最一勞永逸的做法是，將所有低版本都應用補丁或是升級，弊端就是這個工作量很可能是巨大的。

2.3 低版本應用補丁或升級
如果你的環境絕大部分是高版本，只有個別的低版本，可以考慮將低版本進行補丁應用或升級（沒有補丁的版本只能升級版本）

另外需要特殊說明的是，針對生產上佔比比較高的10g穩定版本：10.2.0.5，也就是本文標題的這個版本。最開始Oracle是沒有提供補丁的，但後來Oracle迫於廣大10.2.0.5使用者的壓力，已經為這個版本提供了對應的補丁。但官方給出的串列是：應用PSU171017的基礎上再應用這個SCN補丁14121009。

DATABASE PATCH SET UPDATE 10.2.0.5.171017 and Patch 14121009 [**requires extended support]
and [WIP] ** requires extended support

但是PSU171017是需要擴充套件支援服務才可以有權下載，普通許可權的MOS無法下載，這對於國內大部分客戶都是相當於沒有的。好在我們透過搜尋測試發現，這個14121009的scn補丁對於10.2.0.5.12版本也有提供，經測試可以解決問題，而10.2.0.5.12的PSU普通MOS使用者就可以下載的到。

補丁程式14121009: PLACEHOLDER ENHANCEMENT REQUEST FOR PROJECT ID 40828
先決條件補丁程式
16619894    DATABASE PATCH SET UPDATE 10.2.0.5.12 (INCLUDES CPUJUL2013)

所以對於10.2.0.5版本，可以應用10.2.0.5.12的PSU，再應用14121009的SCN補丁即可解決問題，無需升級大版本。
細節補充：10.2.0.5的庫，如果沒有打任何PSU補丁，是沒有”_external_scn_rejection_threshold_hours”這個隱藏引數的。應用10.2.0.5.12 PSU：p16619894_10205_Linux-x86-64.zip後，就引入了”_external_scn_rejection_threshold_hours”這個隱藏引數,且預設值為24：

NAME                                                    DESCRIPTION                                                        VALUE------------------------------------------------------- ------------------------------------------------------------------ ------------------------------_external_scn_rejection_threshold_hours                 Lag in hours between max allowed SCN and an external SCN           24

但此時還不能調整SCN COMPATIBILITY，需要繼續應用p14121009_1020512_Linux-x86-64.zip這個SCN補丁後，才可進行調整：

--開庫狀態只能調高，調低需要在mount狀態下：ALTER DATABASE SET SCN COMPATIBILITY 1;ALTER DATABASE SET SCN COMPATIBILITY 2;ALTER DATABASE SET SCN COMPATIBILITY 3;

而對於比10.2.0.5更低的版本，截止目前依然是沒有補丁提供，就只能透過升級來解決。

3.常用查詢驗證方法

Oracle ACE 蓋國強和羅海雄老師在很多相關文章中提供了一些常用的查詢驗證方法，實際測試很好用，具體查詢陳述句如下：

3.1 確認資料庫版本高低
一個檢查當前資料庫究竟是高版本還是低版本的簡單方法，就是去看資料庫是否包含dbms_scn這個包，包含就是高版本，反之就是低版本（這樣低版本透過補丁應用或升級後，也可以透過這個查詢去判斷是否修補成功）：

select count(*) from dba_objectswhereowner = 'SYS' and object_name ='DBMS_SCN' and object_type='PACKAGE BODY';

3.2 檢查SCN的狀態
應用補丁或者在高版本資料庫中可以查詢SCN的狀態：

--check your scn statusset serverout ondeclare
v_autorollover_date date;
v_target_compat number;
v_RSL number;
v_hr_in_scn number;
v_hr_in_sec number;
v_t4 number;
v_max_cmpat number;
v_isenabled boolean;
v_current_compat number;begindbms_scn.GETCURRENTSCNPARAMS(
        v_RSL,v_hr_in_scn,v_hr_in_sec,v_current_compat,v_max_cmpat);
dbms_scn.GETSCNAUTOROLLOVERPARAMS(
        v_autorollover_date,v_target_compat,v_isenabled);
dbms_output.put_line('Current SCN compatibility:'||v_current_compat);
dbms_output.put_line('Current SCN RATE:'||round((v_hr_in_scn/v_hr_in_sec)/1024)||'k');if(v_isenabled) thendbms_output.put_line('AUTO SCN compatibility rollover is ENABLED!!!');
dbms_output.put_line('AUTO rollover time:'||to_char(v_autorollover_date,'YYYY/MM/DD'));
dbms_output.put_line('AUTO rollover target value:'||v_target_compat );elsedbms_output.put_line('AUTO SCN compatibility rollover is DISABLED!!!');end if;end;
/

查詢結果類似如下：

Current SCN compatibility:1Current SCN RATE:16k
AUTO SCN compatibility rollover is ENABLED!!!
AUTO rollover time:2019/06/23AUTO rollover target value:3PL/SQL procedure successfully completed.

3.3 查詢當前最大合理SCN
一個資料庫當前最大的可能SCN被稱為”最大合理SCN”，該值可以透過如下方式計算：

col scn for 999,999,999,999,999,999select (
    (
        (
            (
                (   
                    (
                        to_char(sysdate,'YYYY')-1988
                    )*12+
                to_char(sysdate,'mm')-1
                )*31+to_char(sysdate,'dd')-1
            )*24+to_char(sysdate,'hh24')
        )*60+to_char(sysdate,'mi')
    )*60+to_char(sysdate,'ss')
) * to_number('ffff','XXXXXXXX')/4 scnfrom dual
/

這個演演算法即SCN演演算法，這裡是以1988年1月1日 00點00時00分開始，每秒計算1個點數，最大SCN為16K。

4.總結

這段關於SCN的風波引起了不少客戶的過度恐慌，實際上最本質的還是要理解Oracle的本質，明白了其中原理，才可以防患於未然，做到心中不慌。
我使用免費的Bethune巡檢（點選“閱讀原文”瞭解）發現（版本：2.2.6）,可以對SCN有更細緻的安全檢查：

--測試環境第一次巡檢發現：
當前資料庫中已存在 SCN 升級邏輯，當前的 SCN 每秒增長上限為 32768 （來源於引數 _max_reasonable_scn_rate）, 並未啟動 SCN 版本自動升級，需要時時關註 SCN Headroom 的增長情況，必要時及時升級 SCN 版本。
2018-12-26 21:20:18 15184372089397  800.3--非常規手段將測試環境的SCN 推進到16316960000000，再次巡檢發現：
截至資料採集時，當前資料庫的 SCN 增長速度過快，當前 Headroom 為 .2 天，不足 10 天，當前資料庫並沒有對應的 SCN 升級補丁，可能會在未來（2019 年 6 月之後）執行過程中出現 SCN 相關問題。
2018-12-26 21:29:08 16316960000074  0.2

不過測試發現，在10.2.0.5版本，即使我應用了PSU和對應的SCN補丁，再次巡檢還是提示沒有對應SCN升級補丁，這可能是工具還沒有考慮到10.2.0.5這種應用補丁的方式：

--DATABASE PATCH SET UPDATE 10.2.0.5.12 + 14121009補丁
截至資料採集時，當前資料庫的 SCN 增長速度過快，當前 Headroom 為 .3 天，不足 10 天，當前資料庫並沒有對應的 SCN 升級補丁，可能會在未來（2019 年 6 月之後）執行過程中出現 SCN 相關問題。
2018-12-26 23:24:22   16316960012451  0.3

引起這一波使用者恐慌的MOS文章：

• Recommended patches and actions for Oracle databases versions 12.1.0.1, 11.2.0.3 and earlier – before June 2019 (檔案 ID 2361478.1)
• Recommended patching and actions for Oracle database versions 12.1.0.1, 11.2.0.3 and earlier – before June 2019 (檔案 ID 2335265.1)

 

原創：趙靖宇