歡迎光臨
每天分享高質量文章

SCN風波又起,2019年6月之前Oracle必須升級嗎?

最近關於SCN的問題又被炒的沸沸揚揚;因為Oracle之前更新了一篇文章(ANNOUNCEMENT: Recommended patches and actions for Oracle databases versions 12.1.0.1, 11.2.0.3 and earlier – before June 2019 (Doc ID 2361478.1))

 

簡單的說,Oracle將在2019年6月份自動啟動SCN的新機制,即SCN rate 最大增長可達96kb,遠超之前的32kb。當然,並不是說所有版本的Oracle資料庫,都將自動啟用這一特性(感覺Oracle埋了一個坑)。準確一點的說,時間點是2019年6月23號;如下:

SYS@ora122>set serveroutput onSYS@ora122>declare  2    v_autorollover_date date;  3    v_target_compat number;  4    v_is_enabled boolean;  5  begin  6    dbms_scn.getscnautorolloverparams(v_autorollover_date, v_target_compat, v_is_enabled);  7    dbms_output.put_line('auto rollover date      : '||to_char(v_autorollover_date,'YYYY-MM-DD'));  8    dbms_output.put_line('target scheme           : '||v_target_compat);  9    dbms_output.put_line('rollover enabled (1=yes): '||sys.diutil.bool_to_int(v_is_enabled)); 10  end; 11  /auto rollover date      : 2019-06-23target scheme           : 3rollover enabled (1=yes): 1
PL/SQL procedure successfully completed.

 

那麼那些版本的庫將在2019年6月份自動啟動這個特性呢?如下:

 

 

針對上述版本的資料庫將會在6月23號自動自動新機制。這麼這個新機制是什麼呢?簡單的講就是以前老版本的scn機制我們可以理解為是scheme 1、新版本將自動改成scheme 3,每秒允許增長的閾值更大。

 

SYS@ora122> declare  2    v_rsl number;  3    v_headroom_in_scn number;  4    v_headroom_in_sec number;  5    v_cur_scn_compat number;  6    v_max_scn_compat number;  7  begin  8    dbms_scn.getcurrentscnparams(v_rsl, v_headroom_in_scn, v_headroom_in_sec, v_cur_scn_compat, v_max_scn_compat);  9    dbms_output.put_line('reasonable scn limit (soft limit): '||to_char(v_rsl,'999,999,999,999,999,999')); 10    dbms_output.put_line('headroom in scn                  : '||to_char(v_headroom_in_scn,'999,999,999,999,999,999')); 11    dbms_output.put_line('headroom in sec                  : '||v_headroom_in_sec); 12    dbms_output.put_line('current scn compatibility scheme : '||v_cur_scn_compat); 13    dbms_output.put_line('max scn compatibility scheme     : '||v_max_scn_compat); 14  end; 15  /reasonable scn limit (soft limit):       16,439,976,001,536headroom in scn                  :       16,439,897,793,807headroom in sec                  : 1003411730current scn compatibility scheme : 1max scn compatibility scheme     : 3
PL/SQL procedure successfully completed.

 

當然,Oracle在這些版本中引入了一個dbms_scn包來控制這個機制。

比如我們這裡就可以直接用dbms_scn來disable這個機制。

SYS@ora122>exec dbms_Scn.DISABLEAUTOROLLOVER;
PL/SQL procedure successfully completed.SYS@ora122>shutdown immediateDatabase closed.Database dismounted.ORACLE instance shut down.SYS@ora122>startup mountORACLE instance started.
Total System Global Area 4999610368 bytesFixed Size                  8803024 bytesVariable Size             956304688 bytesDatabase Buffers         3489660928 bytesRedo Buffers                7970816 bytesIn-Memory Area            536870912 bytesDatabase mounted.
SYS@ora122>alter database set scn compatibility 1;
Database altered.
Elapsed00:00:00.00SYS@ora122>alter database open;
Database altered.SYS@ora122>declare  2    v_autorollover_date date;  3    v_target_compat number;  4    v_is_enabled boolean;  5  begin  6    dbms_scn.getscnautorolloverparams(v_autorollover_date, v_target_compat, v_is_enabled);  7    dbms_output.put_line('auto rollover date      : '||to_char(v_autorollover_date,'YYYY-MM-DD'));  8    dbms_output.put_line('target scheme           : '||v_target_compat);  9    dbms_output.put_line('rollover enabled (1=yes): '||sys.diutil.bool_to_int(v_is_enabled)); 10  end; 11  /auto rollover date      : 2019-06-23target scheme           : 3rollover enabled (1=yes): 0
PL/SQL procedure successfully completed.
Elapsed00:00:00.01

 

說明瞭這麼多,最重要的問題來了。

 

1. 如何判斷我的資料庫是否受這個scn機制變化的影響?

 

  • 如果你的所有Oracle資料庫都是11.2.0.4或12.2等新版本,那麼無需做任何處理;
  • 如果你的所有資料庫中,有部分低版本(如10205、11.1)需要透過dblink訪問高版本的庫(如11.2.0.4,12.2),那麼可能有風險,建議將低版本的庫進行升級或者安裝上面推薦的Patch;
  • 如果你的資料庫都是低版本的庫,那麼不受任何影響;
  • 如果你的資料庫之間,沒有dblink相互訪問,你也可以高枕無憂!

 

2. 如果判斷一個資料庫的scn是否異常,是否達到scheme 極限

 

SYS@ora122>select dbms_flashback.get_system_change_number "current value",  2         ((((to_number(to_char(sysdate,'YYYY'))-1988)*12*31*24*60*60) +  3         ((to_number(to_char(sysdate,'MM'))-1)*31*24*60*60) +  4         (((to_number(to_char(sysdate,'DD'))-1))*24*60*60) +  5         (to_number(to_char(sysdate,'HH24'))*60*60) +  6         (to_number(to_char(sysdate,'MI'))*60) +  7         (to_number(to_char(sysdate,'SS')))) * (16*1024)) "RSL scheme 1",  8         round(dbms_flashback.get_system_change_number/((((to_number(to_char(sysdate,'YYYY'))-1988)*12*31*24*60*60) +  9         ((to_number(to_char(sysdate,'MM'))-1)*31*24*60*60) + 10         (((to_number(to_char(sysdate,'DD'))-1))*24*60*60) + 11         (to_number(to_char(sysdate,'HH24'))*60*60) + 12         (to_number(to_char(sysdate,'MI'))*60) + 13         (to_number(to_char(sysdate,'SS')))) * (16*1024))*100,5) "% to RSL scheme 1" 14  from dual;
         current value           RSL scheme 1 % to RSL scheme 1---------------------- ---------------------- -----------------            78,207,891     16,439,977,345,024            .00048

 

透過上述指令碼即可判斷,如果to RSL scheme 1 百分比高達90%,那麼說明你的資料庫scn增長異常,建議進行處理。

 

3. 新版本的scn機制後,scn最大可到多少?

 

我們知道老版本中scn最大值為power(2,48);新機制後被成為Big Scn,可達power(2,64),相差了數萬倍。

 

最後接下來大家需要做什麼? 梳理所有Oracle資料庫,確認版本資訊,採取行動吧!

已同步到看一看
贊(0)

分享創造快樂