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 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.
那么那些版本的库将在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,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这个机制。
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 极限
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数据库,确认版本信息,采取行动吧!
相关推荐
升级更新:Oracle关于DB Link在2019年升级的10g版本兼容性
预警揭秘:倒计时炸弹11.2.0.4前版本DB Link必须在2019年4月升级真相
作者简介
李真旭:网名 Roger,Oracle ACE,拥有超过10年的 Oracle 运维管理使用经验;参与过众多移动、电信、联通、银行等大型数据库交付项目, 具有丰富的运维管理经验,对 Oracle 数据库管理运行机制、锁机制、优化机制等具有深入理解;擅长 Oracle 数据库的 performance tunning、troubleshooting 以及异常恢复;个人博客:http://www.killdb.com
资源下载
关注公众号:数据和云(OraNews)回复关键字获取
2018DTCC ,数据库大会PPT
2018DTC,2018 DTC 大会 PPT
ENMOBK,《Oracle性能优化与诊断案例》
DBALIFE ,“DBA 的一天”海报
DBA04 ,DBA 手记4 电子书
122ARCH ,Oracle 12.2体系结构图
2018OOW ,Oracle OpenWorld 资料
云和恩墨大讲堂 | 一个分享交流的地方
长按,识别二维码,加入万人交流社群
请备注:云和恩墨大讲堂