Oracle的 DB Link 问题及2019年4月前升级路线详述-SCN

 

解决方案：Oracle的 DB Link 问题及2019年4月前升级路线详述

发布时间：2018-03-19 发布人：盖国强   1981

 

在之前的文章中，我们阐述了“预警揭秘：倒计时炸弹11.2.0.4前版本DB Link必须在2019年4月升级真相”，很多读者提出了很多问题，我们在此进一步的补充和介绍一点基础知识，并给出解决方案。

 

我们整理了检查 SCN 的脚本 scnhealthcheck.sql 和文中用到的脚本，以及几篇文章的 PDF 版本，关注本公众号（ OraNews）回复：SCNCOMP ，你可以找到下载链接。

 

1. 这个问题严重吗？

 

我想首先回答一下这个问题，可能很多人心存疑惑，这个问题严重吗？有多严重？会影响到我吗？

 

首先，我们分析这个问题的起因就是因为Oracle用了空前严重的措辞，11.2.0.3 及以前版本，使用DB Link的，在2019年4月前必须应用到推荐的补丁。

 

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)

 

这个警告是非常严重的。

 

如果经历过 2011 - 2013 年左右，通宵达旦升级 SCN 补丁的DBA都会心有余悸、印象深刻，如果数据库的 SCN 接近极限，则数据库就可能频繁出错，最坏的情况是事务都执行不了，数据库停顿。由于SCN不可以重置，严重情况甚至要重建数据库。

 

所以和 SCN 相关的问题，都是很严重的问题。遇到这类问题的症状参考：SCN、ORA-19706错误和内部参数。

 

但是注意，严重的问题不一定会影响所有客户，最容易遭遇问题的是，事务频繁、交易频繁、压力大的数据库，这类系统SCN增长快，Headroom紧张，对于空闲度高、事务率低的系统基本上没有什么事（除非杯具的遇到BUG），这一类的系统无需过度忧虑。

 

还要一个大前提，如果你不用 DB Link，这个事情就和你一点关系都没有，可以安全的忽略之！

 

但是不要误会：低版本、不用DB Link并不意味着你不会遇到SCN的 ORA-19706错误，你的数据库如果有SCN增长过快的问题，同样会中止服务（用 scnhealthcheck 脚本可以进行检查）。只是没有办法使用新特性的增强解决方案，Oracle 致力于解决的就是跨DB Link的SCN拉平导致的各种异常。

 

2. 影响的是什么

 

简单来说，影响的是 SCN 算法，SCN 是数据库内部的时钟。

 

Oracle设置了倒计时，在 2019年6月23日，自动启用 3 级兼容性，提升SCN的可用量。

 

也彻底废弃 16K/s 的增长率，提升到 96K/s 的增长率，目标是让数据库支持的变化更多，承载能力更强，这是进步。但是注意：即便都升级到高版本并且到2019年自动过度到 3 级兼容性，SCN 越界的ORA-19706问题仍然可能会遇到。

 

SCN新算法兼容性有四个级别，是为了让SCN的可用量更多而已，级别可设置的是 1，2，3，将要自动进化到的就是 3 级。下表我们绘制了兼容性曲线，可以看到 RSL 3 的SCN可用空间获得了大幅度提升。

 

 

当然你可以通过禁用这个自动过度，让数据库 SCN 维持在以前的增长率上。

 

在 DBMS_SCN 的工具包里提供了 DISABLEAUTOROLLOVER 和 ENABLEAUTOROLLOVER 的过程。并且 Oracle 修改了 SCN 起点的算法从 1998 年 推进到 2008 年。时代已然改变。具体请各位向下看详细描述的技术内容。

 

3. 还能简单点吗？

 

如果您还觉得有点复杂，在我们免费的SaaS产品 Bethune 中，已经全面提供了关于 SCN 和 DB Link 的检测和可视化输出，够体贴吗？

网址是： https://bethune.enmotech.com 

 

以下是关于 SCN 和 Headroom 的检查：

 

 

下图是 DB Link 的安全检查和图谱：

 

 

还有关于安全来源的检测等：

 

 

不要犹豫，云和恩墨 免费、优雅又好用的产品工具等着你。

 

4. 补丁如何升级

 

首先，关于补丁，比如很多朋友问 10.2.0.5 有没有补丁，请看下图，目前Oracle在支持的最低版本是11g。而且 11.2.0.4 将在 2019年1月1日进入扩展支持期（Extended Support），也就是必须要有支持合同才为用户提供补丁，不对外公开发布补丁了。所以，所有 10g 的版本，已经没有补丁了。例外的是 11.1.0.7 和 11.2.0.3 有补丁。所以这个问题应该清楚了。

 

版本升级路线如下：

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

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

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

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

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

 

 

关于这个 DB Link 问题的影响，简要再总结一下：

1）首先定义一下高版本：就是 11.2.0.4 和 12.1.0.2 及其以上版本，和打过补丁的 11.1.0.7 和 11.2.0.3 版本；

2）再定义一下低版本：不再上述版本中的；

 

以下几点一目了然：

1）低版本之间通过 DB Link 互联，不受影响；

2）低版本和高版本之间通过 DB Link 互联，可能受到影响，主要取决于高 SCN 系统的高度；

3）受影响是因为新版本的 SCN 增长算法改变，可能瞬间抬升低版本的 SCN 至越界；

4）越界只影响跨 DB Link 的访问，不影响本数据库运行；

5）如果你的系统 SCN 都很低，增长也很慢，就基本不用担心，不升级也没有问题；

 

再明确一下，哪些版本有补丁：

1）11.2.0.4 和 12.1.0.2 及其以上版本，天然自带加持；

2）11.1.0.7 和 11.2.0.3 版本有补丁，具体见下图，Windows 版本和其他平台不同；

3）其余版本无补丁；

 

 

5. FAQ

 

很多朋友提出了很多问题，在此一一解答如下：

 

1）SCN 的问题和版本有关吗？

任何版本都可能因为 SCN 增长过快而遭受 SCN 拒绝，数据库停顿的问题。高版本在尝试解决（这个修正就是），低版本不予修补。

 

2）10g 受影响吗？

受影响没补丁，但是大前提是有 DB Link，如果仅仅是低版本之间访问，没有问题（不受 SCN 算法变动影响，但是自身 SCN 过高仍然会有问题），低版本和高版本通过 DB Link 互访，可能有问题。

 

3）高版本和其它低版本通过 dblink 互联就算中标了，还是其它 11g 版本打了这次的补丁的才算？

是的，但是仅仅是跨 DB Link 的 SQL 失败，高版本数据库本身不受影响。

 

4）10.2.0.4 和 10.2.0.5 的 RAC 受到影响么？

如第一个问题，这两个版本互访都没有问题，和高版本跨 DB Link 访问才有风险。

 

5）这问题会扩展传播吗，如 10.2.0.5 连接 11.2.0.4，10g 被传染，又有个新的 10g 连接了被传染的 10g。会扩散吗？

会的，SCN 问题天然会通过 DB Link 扩展传播。

 

我这里用11204连了10g，报 scn 错了。只能升级吗？很多 10g。

不一定非要升级，只要能够有效控制 SCN，不要增长过快，就没有问题。一般来说跳变 SCN 的源数据库是能够排查和解决的。

 

下图是昨天网友提出的一个问题，10.2.0.5 的 SCN 已经接近限制的极限，数据库出现问题，这类数据库根本上要去解决 SCN 异常增长的问题。这个过程较复杂，云和恩墨技术支持提供协助诊断排查服务。

 

 

6. 环境判断

 

如何判断我的数据库是否已经应用了这个补丁？

只需要看看是否存在 DBMS_SCN 这个包，如果存在，就意味着已经应用了这个补丁：

 

 

通过如下一段代码，就可以查出数据库当前的SCN兼容性和启用时间：

SQL> @scncomp

date:20190623000000, compatiable:3

Auto-rollover is disabled

SQL> exec dbms_scn.ENABLEAUTOROLLOVER;

SQL> @scncomp

date:20190623000000, compatiable:3

Auto-rollover is enabled

SQL> set echo on

SQL> @scncomp

SQL> declare

  2  v_date date;

  3  v_compat number;

  4  v_enable boolean;

  5  begin

  6  dbms_scn.getscnautorolloverparams(v_date, v_compat, v_enable);

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

  8  if v_enable then

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

 10  else

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

 12  end if;

 13  end;

 14  /

date:20190623000000, compatiable:3

Auto-rollover is enabled

 

7. SCN 算法

 

我们再来阐述一下技术问题，有以下几个小知识需要明确：

SCN 是 Oracle 数据库的内部时钟，单调递增，不可逆转；

SCN 在很多情况下会增长，比如 Commit，Oracle 对这个增长进行控制，最初是允许每秒 16K ；

如果通过 DB Link 进行跨数据库访问，基于分布式一致性原理，Oracle 会将两个数据库的 SCN 时钟同步；

通过 DB Link，SCN 低的被拉高，一旦超过数据库的允许限制，就会出错；

 

了解了这几点，我们可以向下进行了，详细一点说：

 

SCN(System Change Number) ，也就是通常我们所说的系统改变号，是数据库中非常重要的一个数据结构。

它定义数据库在某个确切时刻提交的版本。在事物提交时，它被赋予一个唯一的标示事物的 SCN 。 SCN 提供 Oracle 的内部时钟机制，可被看作逻辑时钟，这对于恢复操作是至关重要的 （ Oracle 仅根据 SCN 执行恢复）。 

Oracle 通过 SCN 来维护数据库的一致性，并通过 SCN 实施 Oracle 至关重要的恢复机制。

 

为什么 SCN 的增长要进行控制？

这是因为 Oracle 使用了 6 Bytes 记录 SCN，也就是48位，不能无限增长用超了就麻烦了。6 Bytes 的最大值是：

SQL> select power(2,48) scn from dual;

                                SCN

----------------------------

     281,474,976,710,656

如果 Oracle 在内部控制每秒增加的SCN不超过 16K，按照这样计算，这个数值可以使用大约544年：

SQL> select power(2,48) / 16 / 1024 / 3600 / 24 / 365 

       2 from dual;

POWER(2,48)/16/1024/3600/24/365

-------------------------------

                     544.770078

SCN 算法是以1988年1月1日 00点00时00分开始，每秒计算1个点数，有了16K的限制，一个数据库当前最大的可能 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 因为种种原因增长越来越快，Oracle 不得不放宽约束，也就有了参数 _max_reasonable_scn_rate ，增长率从 16k 放宽到 32k，现在看起来，在即将启用的特性中，将进一步放宽到 96K。

 

那么在 96K 的约束之下，SCN 的存储空间，可以使用 90 年。所以有朋友问，是否SCN加位扩展了，事实上并没有：

SQL> select power(2,48) / 96 / 1024 / 3600 / 24 / 365

 from dual;

POWER(2,48)/96/1024/3600/24/365

-------------------------------

      90.795013

但是注意，还有一个好问题，为什么要选择 1988年 作为起点呢？这个起点可以修改吗？

 

当然，在新的算法中，Oracle改变了 SCN 算法的起点值，在32K和96K的增长率下，起点分别近似调整为：

2：~ 1998/07/01

3： ~ 2008/03/30

 

这也可算作起征点调整吧，所以经过调整最大支持到大约 2097年（极限不稳定值 Oracle 最高可以用到 2105 年），你可能会问，那到了2097年怎么办？这个，呵呵。。。

 

8. 可能遇到的提示

 

我们再来阐述一下技术问题，有以下几个小知识需要明确：

 

此外，昨天的文章我们提到，如果出现问题，你可能看到的提示或者错误。这一部分必须要补充完整。

 

新的提示大约类似如下这些，我就不一一翻译了，大家可以看到主要是提示用户SCN的兼容性版本发生改变，基于自动的Rollover特性，这些关键字在未来不要奇怪：

Database SCN compatibility changed from %d to %d due to auto-rollover

Warning - High Database SCN: Current SCN value is %s, threshold SCN value is %s

If you have not previously reported this warning on this database, please notify Oracle Support so that additional diagnosis can be performed.

Database SCN compatibility auto-rollover - control file update

ALTER DATABASE SET SCN COMPATIBILITY: setting compatibility to %d does not allow sufficient headroom

Parameter value %s is invalid for _external_scn_rejection_delta_threshold_minutes

Database SCN compatibility auto-rollover enabled

Database SCN compatibility auto-rollover disabled

Initializing SCN for created control file

Database SCN compatibility initialized to %d

Warning: The SCN headroom for this database is only %d hours!

Warning: The SCN headroom for this database is only %d days!

SCN compatibility auto-rollover is disabled

SCN compatibility changed from %d to %d (auto-rollover)

 

关于 SCN 有很多有意思的变化，大家一起来探索吧！