谈谈Oracle为2019年埋下的雷：Oracle关于DBLINK的预警

最近一个月，Oracle在MOS上发布了两篇与DBLINK相关的预警：

Oracle Databases Need to be Patched to a Minimum Patchset/PSU/RU level before April

2019 (Doc ID 2361478.1)

Mandatory Patching Requirement for Database Versions 11.2.0.3 or Earlier, Using DB

Links (Doc ID 2335265.1)

文章大概的意思是：11.2.0.3 及以前版本，使用DB Link的，在2019年4月前必须应用到推荐的补丁，否则你使用DBLINK的场景可能会遇到故障。

看似很严重，有点以前2000年说的千年虫的味道，其实仔细研究，这个预警其实没多大的事。

1.       这个补丁是什么用途？

增加DBMS_SCN的工具包，设置在2019年6月23日，自动启用 3 级兼容性，提升SCN的可用量。从16K/s或32K/s的增长率，提升到 96K/s 的增长率，目标是让数据库支持的变化更多，承载能更强。

但是注意：图1中可以看出，3级兼容性的SCN上限是高很多的，但毕竟还是有上限的，所以就算启动3级兼容性，SCN 越界的ORA-19706问题仍然可能会遇到。

2.       本次预警涉及哪些版本需打补丁？

豁免版本：11.2.0.4 和 12.1.0.2 及以上版本，已然自带加持；

10g 版本：你可以选择升级到 11g 或者 12c；

11.1版本：你可以选择升级到11.1.0.7 版本，应用补丁升级到11.1.0.7.20+；

11.2版本：你可以选择升级到11.2.0.3 版本，应用补丁升级到11.2.0.3.9+；

12.1版本：你至少升级到 12.1.0.2.0 版本；

版本对应的补丁：

3.       怎么检查数据库有没包含相关的补丁和它的一些信息？

最简单的是在sqlplus下,desc dbms_scn

如果存在这个工具，就是包含补丁的。

可以在sqlplus下用以下脚本检查：

vi scncomp.sql

declare

v_date date;

v_compat number;

v_enable boolean;

begin

dbms_scn.getscnautorolloverparams(v_date, v_compat, v_enable);

dbms_output.put_line('date:' || to_char(v_date, 'yyyymmddhh24miss') || ', compatiable:' || v_compat );

if v_enable then

dbms_output.put_line('Auto-rollover is enabled');

else

dbms_output.put_line('Auto-rollover is disabled');

end if;

end;

很明显，这个补丁将会在20190623这天启动3级兼容性

4.       相关补丁和SCN有关系，但好像与DBLINK没啥关系啊？

低版本和高版本之间的数据库通过DB Link互联，可能受到影响，主要取决于高SCN系统的高度，因为高版本的SCN增长算法改变，当高版本的current SCN值在高位时，可能瞬间抬升低版本的SCN至越界（认真观察图1，3级兼容的上限高很多），DBLINK的访问就被拒绝和报错了。

通过DBLINK的查询会同步数据库的SCN，这个结论的实验就不做了，盖总博客有，可以自行观察有DBLINK互相访问的那几个库，current scn值是否都在同一个数量级，即可以验证。

注：高版本就是 11.2.0.4 和 12.1.0.2 及其以上版本，和打过补丁的 11.1.0.7和 11.2.0.3 版本；其他的都为低版本。

5.       怎么检查SCN还多久到达上限？

SCN其实有2个上限值，一个是硬限制：

Oracle 使用了6 Bytes 记录SCN，也就是48位，即SCN的最大值是281万亿（281,474,976,710,656），到达这个数值后，数据库将再也启动不了，需要重建数据库才能解决。按3级兼容的96K/s的速度，也可以用90年，所以这不是我们考虑的上限，远达不到。

我们需要考虑的是软上限，还是得认真观察图1，

下面是Oracle提供的计算多久到达软上限的公式：

select

   version,

   date_time,

   dbms_flashback.get_system_change_number current_scn,

   Headroom

  from

  (

   select

   version,

   to_char(SYSDATE,'YYYY/MM/DD HH24:MI:SS') DATE_TIME,

   ((((

    ((to_number(to_char(sysdate,'YYYY'))-1988)*12*31*24*60*60) +

    ((to_number(to_char(sysdate,'MM'))-1)*31*24*60*60) +

    (((to_number(to_char(sysdate,'DD'))-1))*24*60*60) +

    (to_number(to_char(sysdate,'HH24'))*60*60) +

    (to_number(to_char(sysdate,'MI'))*60) +

    (to_number(to_char(sysdate,'SS')))

    ) * (16*1024)) - dbms_flashback.get_system_change_number)

   / (16*1024*60*60*24)

   ) Headroom

   from v$instance

  )

这些显示还有629天，是否到629天我数据库就不能用呢？

不是的，

1)      Oracle提供的公式，用的是兼容性1的16K速度来计算，而我实际版本是兼容性2的32K速度的，所以这个HEADROOM值只能大概参考。

2)      current scn是在不断增大的，可每天可到达的SCN limit值也在增大啊（看图1），629天后，那时都被自动开启过兼容性3了，那当天SCN limit值又倍增不少（看图1）。结合根据计算公式来看，629天后也远达不到软上限值。

补充下SCN Headroom概念：

Headroom（天） = (Reasonable SCN Limit -CurrentSCN)/ SCN每秒最大可能增长

速率/3600/24

也就是如果SCN按最大速率增长，达到当前理论最大值需要的天数。这个值可以用来

判断SCN增长速率是否过快。

补充下计算公式中，兼容级别1-3中用于计算的初始时间：

1：~1988/01/01

2：~ 1998/07/01
3： ~ 2008/03/30

接近上限值的时候，就可能开始报错了：

--相关隐含参数_external_scn_rejection_threshold_hours, 采集自11.2.0.3.9

select ksppinm,ksppstvl,ksppdesc from x$ksppi x,x$ksppcv y where x.indx=y.indx and ksppinm like '_external_scn_rejection_threshold_hours';

这个参数在11.2.0.2版本之前是744，也就是31天。意思是SCN Headroom剩下31天时，就会拒绝DBLINK访问。

例子：

ORA-19706错误：最常见的就是拒绝dblink连接的时候，如A库跟B库通过dblink连接，

A的SCN有通过人为调整增大许多，连接B库的时候，Oracle会判断该SCN传播过来之

后，如果会导致SCN headroom小于_external_scn_rejection_threshold_hours设置的

阈值，则拒绝连接。

6.       打了补丁后，DBLINK就肯定不会出问题么？哪些库最优先要打补丁？

不，打了补丁，只是让数据库可以支持到96K/s秒的速率，这样就极大增高当天的SCN LIMIT（看图1），让你很难达到SCN软上限。

但是

1）我们怕SCN被DBLINK传染，有没可能DBLINK连到一个曾经坏过，用推进多次SCN的方法开库又未重建的数据库呢？一堆数据库DBLINK互联传染SCN呢？

2）我们怕数据库BUG等异常造成的SCN异常。

如果你的数据库不使用DBLINK连其他库，业务也不忙，确实可以不打补丁。

11.2.0.2之前的数据库版本，SCN的默认的最大增长速率是16K/s，

11.2.0.2及之后的数据库版本，SCN的默认的最大增长速率是32K/s，

--相关隐含参数_max_reasonable_scn_rate，采集自11.2.0.3.9

select ksppinm,ksppstvl,ksppdesc from x$ksppi x,x$ksppcv y where x.indx=y.indx and ksppinm like '_max_reasonable_scn_rate';

如果你的业务增长速度可能超过16K或者32K的（超过兼容性级别的速率），就需要小心了。

可以取业务高峰时的AWR，观察calls to kcmgas的速率。

在2018年3月份里，兼容性为1（16K速率）的SCN极限值为15.9万亿，兼容性为2（32K速率）的SCN极限值为20.7万亿。

select to_char(current_scn) from v$database;

查询自己库的current SCN和极限值对比，如果接近，就要小心了。

查询select * from dba_db_links，看看自己库和其他系统的关联。

主要是计算以业务高峰的速率，SCN还多久会达到软上限。

综合这些情况下，自己的库和DBLINK目标库都要尽早打上补丁。

参考文档

恩莫公众号、中亦安图公众号

作者|陈俊亮