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

解决方案:Oracle 的 DB Link 问题及2019年4月前升级路线详述_第1张图片

在之前的文章中,我们阐述了“预警揭秘:倒计时炸弹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 可用空间获得了大幅度提升。

解决方案:Oracle 的 DB Link 问题及2019年4月前升级路线详述_第2张图片

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

在DBMS_SCN的工具包里提供了DISABLEAUTOROLLOVERENABLEAUTOROLLOVER 的过程。

并且 Oracle 修改了 SCN 起点的算法从 1998 年 推进到 2008 年。时代已然改变。具体请各位向下看详细描述的技术内容。

3还能简单点吗?

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

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

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

解决方案:Oracle 的 DB Link 问题及2019年4月前升级路线详述_第3张图片

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

解决方案:Oracle 的 DB Link 问题及2019年4月前升级路线详述_第4张图片

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

解决方案:Oracle 的 DB Link 问题及2019年4月前升级路线详述_第5张图片

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

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 版本;

解决方案:Oracle 的 DB Link 问题及2019年4月前升级路线详述_第6张图片

关于这个 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. 其余版本无补丁;

解决方案:Oracle 的 DB Link 问题及2019年4月前升级路线详述_第7张图片

5FAQ

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

  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 扩展传播。

  6. 我这里用11204 连了10g,报 scn 错了。只能升级吗?很多 10g。

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

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

解决方案:Oracle 的 DB Link 问题及2019年4月前升级路线详述_第8张图片

6环境判断

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

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

解决方案:Oracle 的 DB Link 问题及2019年4月前升级路线详述_第9张图片

通过如下一段代码,就可以查出数据库当前的 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

7SCN 算法

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

  • 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 有很多有意思的变化,大家一起来探索吧!

相关阅读:

SCN、ORA-19706 错误和内部参数

深入剖析:Oracle SCN 机制详解

预警揭秘:11.2.0.4前版必须在2019年4月升级

安全警报:2018一月号安全补丁修复安全漏洞

安全警告:WebLogic WSAT 组件漏洞挖矿程序攻击

如果在此问题上需要进一步的协助,请联系云和恩墨的技术团队,更详细的解决方案将提供给我们的服务客户。也欢迎加入我们的微信群进一步的讨论该问题。


解决方案:Oracle 的 DB Link 问题及2019年4月前升级路线详述_第10张图片

云和恩墨

数据驱动,成就未来。整合业界顶尖的技术与合作伙伴资源,围绕数据及相关领域,提供解决方案和专业服务。

IT基础架构

分布式存储 | zData一体机 | 容灾方案

数据架构

Oracle DB2 MySQL NoSQL

专项服务:架构/安全/优化/升级/迁移

运维服务:运维服务  代维服务

人才培养:个人认证  企业内训

软件产品:SQL审核、自动化运维、数据恢复

应用架构

应用和中间件:数据建模 | SQL审核和优化 | 中间件服务

解决方案:Oracle 的 DB Link 问题及2019年4月前升级路线详述_第11张图片

你可能感兴趣的:(数据库,java,python,人工智能,编程语言)