eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« Oracle 数据库需要在2019年April之前Mandatory升级的说明 | Blog首页 | Oracle 11g在补丁修正中引入DBMS_SCN包及新特性 »

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

scndblinks0.jpg

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

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

这个问题严重吗?

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

首先,我们分析这个问题的起因就是因为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拉平导致的各种异常。

影响的是什么

简单来说,影响的是 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可用空间获得了大幅度提升。

scnchangerate.png

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

在 DBMS_SCN 的工具包里提供了 DISABLEAUTOROLLOVER

ENABLEAUTOROLLOVER 的过程。

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

还能简单点吗?

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

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

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

bethunes1.jpg

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

bethunes2.jpg

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

补丁如何升级

首先,关于补丁,比如很多朋友问 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 版本;

roadmapodb.jpg

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

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

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

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

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

scnproblem.png

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

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组件漏洞挖矿程序攻击

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


云和恩墨

数据驱动,成就未来。整合业界顶尖的技术与合作伙伴资源,围绕数据及相关领域,提供解决方案和专业服务。
IT基础架构
分布式存储 | zData一体机 | 容灾方案
数据架构
Oracle DB2 MySQL NoSQL
专项服务:架构/安全/优化/升级/迁移
运维服务:运维服务 代维服务
人才培养:个人认证 企业内训
软件产品:SQL审核、自动化运维、数据恢复
应用架构
应用和中间件:数据建模 | SQL审核和优化 | 中间件服务


历史上的今天...
    >> 2011-03-17文章:
    >> 2009-03-17文章:
    >> 2007-03-17文章:
           新书最后章节框架性定稿
    >> 2006-03-17文章:
    >> 2005-03-17文章:
           Oracle WareHouse Builder培训

By eygle on 2018-03-17 09:43 | Comments (0) | Oracle12c/11g | 3280 |


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com