环境：OEL 5.7 + Oracle 10.2.0.5
背景：Oracle发布的两篇关于2019年6月份将自动调整高版本数据库的SCN COMPATIBILITY的MOS文章引起了很多客户的恐慌，尤其是起初Oracle对10g版本未提供任何补丁。我这里结合业界多位Oracle ACE专家的系列文章，在自己的实验环境做了系列验证总结。
1.什么都不做会怎样？
结合多位专家的结论：
Oracle 将会在 2019 年 6 月 23 日后自动调整高版本的数据库 SCN COMPATIBILITY 为 3，调整之后，这些数据库内部的 SCN 上限增速会变成 96k, 从而可能出现超出低版本的 SCN 的情况，如果发生这种情况，将会导致低版本数据库无法与高版本通过 DB Link 进行连接。
具体解释下，这里所说的高版本，可以理解为是：11.2.0.4及以上版本，同时也包含其他低于此版本但有补丁可以应用修正的版本；
而低版本就是剩下的版本。
也就是说：如果确认环境内没有所谓的高版本，理论是可以什么都不做的。但是如果你不能保证未来生产环境内不会创建新的高版本且有dblink连接交互，就不能一直坐视不管。
2.最简单的做法是啥？
这个要看你的实际情况。
2.1 无需关注
如果你的环境全是高版本，或全是低版本，且未来不会有变化，那自然无需关注。
2.2 禁用高版本的自动调整
如果你的环境绝大部分都是低版本，只有个别的高版本，可以考虑将高版本的SCN自动调整禁用掉：
begin
DBMS_SCN.DISABLEAUTOROLLOVER;
end;
/
如果是在2019年6月以后安装的新的高版本，默认就是SCN COMPATIBILITY 为 3，这就需要在mount状态调低兼容性：
ALTER DATABASE SET SCN COMPATIBILITY 1;
或者最一劳永逸的做法是，将所有低版本都应用补丁或是升级，弊端就是这个工作量很可能是巨大的。
2.3 低版本应用补丁或升级
如果你的环境绝大部分是高版本，只有个别的低版本，可以考虑将低版本进行补丁应用或升级（没有补丁的版本只能升级版本）
另外需要特殊说明的是，针对生产上占比比较高的10g稳定版本：10.2.0.5，也就是本文标题的这个版本。最开始Oracle是没有提供补丁的，但后来Oracle迫于广大10.2.0.5用户的压力，已经为这个版本提供了对应的补丁。但官方给出的列表是：应用PSU171017的基础上再应用这个SCN补丁14121009。
DATABASE PATCH SET UPDATE 10.2.0.5.171017 and Patch 14121009 [**requires extended support]
and [WIP] ** requires extended support
但是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补丁即可解决问题，无需升级大版本。
细节补充：10.2.0.5的库，如果没有打任何PSU补丁，是没有”_external_scn_rejection_threshold_hours”这个隐藏参数的。应用10.2.0.5.12 PSU：p16619894_10205_Linux-x86-64.zip后，就引入了”_external_scn_rejection_threshold_hours”这个隐藏参数,且默认值为24：
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 盖国强和罗海雄老师在很多相关文章中提供了一些常用的查询验证方法，实际测试很好用，具体查询语句如下：
3.1 确认数据库版本高低
一个检查当前数据库究竟是高版本还是低版本的简单方法，就是去看数据库是否包含dbms_scn这个包，包含就是高版本，反之就是低版本（这样低版本通过补丁应用或升级后，也可以通过这个查询去判断是否修补成功）：
select count(*) from dba_objects
where
owner = 'SYS' and object_name ='DBMS_SCN' and object_type='PACKAGE BODY';
3.2 检查SCN的状态
应用补丁或者在高版本数据库中可以查询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
一个数据库当前最大的可能SCN被称为”最大合理SCN”，该值可以通过如下方式计算：
col scn for 999,999,999,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的本质，明白了其中原理，才可以防患于未然，做到心中不慌。
我使用免费的bethune巡检发现（版本：2.2.6）,可以对SCN有更细致的安全检查：
--测试环境第一次巡检发现：
当前数据库中已存在 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文章：
- Recommended patches and actions for Oracle databases versions 12.1.0.1, 11.2.0.3 and earlier – before June 2019 (文档 ID 2361478.1)
- Recommended patching and actions for Oracle database versions 12.1.0.1, 11.2.0.3 and earlier – before June 2019 (文档 ID 2335265.1)
