2019年6月之前Oracle必须升级吗？
本站文章除注明转载外，均为本站原创： 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客
本文链接地址: 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号；如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
SYS@ora122>set serveroutput on 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-23 target scheme : 3 rollover enabled (1=yes): 1 PL/SQL procedure successfully completed. Elapsed: 00:00:00.01 |
那么那些版本的库将在2019年6月份自动启动这个特性呢？如下：
| Patch Name | Patch Number |
| 12.1.0.2.0 PATCH SET FOR ORACLE DATABASE SERVER | Patch 17694377 |
| 12.1.0.1.0 PATCH SET FOR ORACLE DATABASE SERVER | Upgrade to 12.1.0.2 or above Patch 17694377 |
| 11.2.0.4.0 PATCH SET FOR ORACLE DATABASE SERVER | Patch 13390677 |
| DATABASE PATCH SET UPDATE 11.2.0.3.9 (INCLUDES CPUJAN2014) | Patch 17540582 |
| DATABASE PATCH SET UPDATE 11.1.0.7.20 (INCLUDES CPUJUL2014) | Patch 18522513 |
| ORACLE 11G 11.2.0.3 PATCH 28 BUG FOR WINDOWS
**Patch 28 is withdrawn. Apply Patch 29 or above. |
Patch 17906982 (Win x64) | Patch 17906981 (Win 32-Bit) ** Patch 29 Patch 18075406 (Win x64) | Patch 18075405 (Win 32-Bit) |
| ORACLE 11G 11.1.0.7 PATCH 57 BUG FOR WINDOWS | Patch 18944208 (Win x64) | Patch 18944207 (Win 32-Bit) |
| QUARTERLY DATABASE PATCH FOR EXADATA (JAN 2014 – 11.2.0.3.22) | Patch 17747147 |
| DATABASE PATCH SET UPDATE 10.2.0.5.171017 and Patch 14121009 | WIP |
针对上述版本的数据库将会在6月23号自动自动新机制。这么这个新机制是什么呢？简单的讲就是以前老版本的scn机制我们可以理解为是scheme 1、新版本将自动改成scheme 3，每秒允许增长的阈值更大。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
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,536 headroom in scn : 16,439,897,793,807 headroom in sec : 1003411730 current scn compatibility scheme : 1 max scn compatibility scheme : 3 PL/SQL procedure successfully completed. |
当然，Oracle在这些版本中引入了一个dbms_scn包来控制这个机制。
比如我们这里就可以直接用dbms_scn来disable这个机制。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
SYS@ora122>exec dbms_Scn.DISABLEAUTOROLLOVER; PL/SQL procedure successfully completed. SYS@ora122>shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SYS@ora122>startup mount ORACLE instance started. Total System Global Area 4999610368 bytes Fixed Size 8803024 bytes Variable Size 956304688 bytes Database Buffers 3489660928 bytes Redo Buffers 7970816 bytes In-Memory Area 536870912 bytes Database mounted. SYS@ora122>alter database set scn compatibility 1; Database altered. Elapsed: 00:00:00.00 SYS@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-23 target scheme : 3 rollover enabled (1=yes): 0 PL/SQL procedure successfully completed. Elapsed: 00: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 极限
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
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数据库，确认版本信息,采取行动吧！
Leave a Reply
You must be logged in to post a comment.