最近关于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号;如下:
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
procedure successfully completed.
那么那些版本的库将在2019年6月份自动启动这个特性呢?如下:
针对上述版本的数据库将会在6月23号自动自动新机制。这么这个新机制是什么呢?简单的讲就是以前老版本的scn机制我们可以理解为是scheme 1、新版本将自动改成scheme 3,每秒允许增长的阈值更大。
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
procedure successfully completed.
当然,Oracle在这些版本中引入了一个dbms_scn包来控制这个机制。
比如我们这里就可以直接用dbms_scn来disable这个机制。
dbms_Scn.DISABLEAUTOROLLOVER;
procedure successfully completed.
immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
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
Area 536870912 bytes
Database mounted.
database set scn compatibility 1;
Database altered.
Elapsed: 00:00:00.00
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
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 资料
云和恩墨大讲堂 | 一个分享交流的地方
长按,识别二维码,加入万人交流社群
请备注:云和恩墨大讲堂