关于Oracle 10.2.0.5 版本应用SCN补丁14121009相关问题
环境:OEL 5.7 + Oracle 10.2.0.5
1.什么都不做会怎样?结合多位专家的结论:
具体解释下,这里所说的高版本,可以理解为是:11.2.0.4及以上版本,同时也包含其他低于此版本但有补丁可以应用修正的版本; 也就是说:如果确认环境内没有所谓的高版本,理论是可以什么都不做的。但是如果你不能保证未来生产环境内不会创建新的高版本且有dblink连接交互,就不能一直坐视不管。 2.最简单的做法是啥?这个要看你的实际情况。 2.2 禁用高版本的自动调整 begin DBMS_SCN.DISABLEAUTOROLLOVER; end; / 如果是在2019年6月以后安装的新的高版本,默认就是SCN COMPATIBILITY 为 3,这就需要在mount状态调低兼容性: ALTER DATABASE SET SCN COMPATIBILITY 1; 或者最一劳永逸的做法是,将所有低版本都应用补丁或是升级,弊端就是这个工作量很可能是巨大的。 2.3 低版本应用补丁或升级
但是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补丁即可解决问题,无需升级大版本。 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 盖国强和罗海雄老师在很多相关文章中提供了一些常用的查询验证方法,实际测试很好用,具体查询语句如下: select count(*) from dba_objects where owner = ‘SYS‘ and object_name =‘DBMS_SCN‘ and object_type=‘PACKAGE BODY‘; 3.2 检查SCN的状态 --check your scn status set serverout on declare 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; begin dbms_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) then dbms_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 ); else dbms_output.put_line(‘AUTO SCN compatibility rollover is DISABLED!!!‘); end if; end; / 查询结果类似如下: Current SCN compatibility:1 Current SCN RATE:16k AUTO SCN compatibility rollover is ENABLED!!! AUTO rollover time:2019/06/23 AUTO rollover target value:3 PL/SQL procedure successfully completed. 3.3 查询当前最大合理SCN col scn for 999,999,999 select ( ( ( ( ( ( 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 scn from dual / 这个算法即SCN算法,这里是以1988年1月1日 00点00时00分开始,每秒计算1个点数,最大SCN为16K。 4.总结这段关于SCN的风波引起了不少客户的过度恐慌,实际上最本质的还是要理解Oracle的本质,明白了其中原理,才可以防患于未然,做到心中不慌。 --测试环境第一次巡检发现: 当前数据库中已存在 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文章:
(编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |