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

在之前的文章中,我们阐述了“预警揭秘:倒计时炸弹11.2.0.4前版本DB Link

我们整理了检查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. 其余版本无补丁;

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异常增长的问题。这个过程较复杂,云和恩墨技术支持提供协助诊断排查服务。

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)

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2018-03-17

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏沃趣科技

Oracle SCN HeadRoom分析与处理

最近几家客户的Oracle数据库开始集中爆发SCN HeadRoom问题,虽然SCN不会真正用完,但是数据库触碰到headroom天花板,还是可能有意想不到的情...

61610
来自专栏星汉技术

计算机基础(二)

2448
来自专栏Android知识点总结

01-Linux开篇-Android之路感触篇

1094
来自专栏沃趣科技

隔壁老王的数据备份“变形”记

隔壁老王作为一名合格的DBA 守护数据安全是他不可推卸的责任 比如每一次的数据库备份 可是你懂的 那备份的速度 ? 于是乎 兢兢业业的老王一边盯着屏幕 一边若有...

4237
来自专栏睿哥杂货铺

SDN 技术指南(二):OpenFlow

OpenFlow 最早由斯坦福大学提出,目前知识产权由开放网络基金会(Open Networking Foundation,ONF)持有。

3979
来自专栏FreeBuf

微软:暴力破解面前,增强密码复杂性基本没用

我们都痛恨密码,然而不幸的是在当下及可以看见的未来里,账户登录等在线认证操作的主要方法还是需要使用密码的。密码认证有时确实比较烦人,尤其是一些网站为了密码安全性...

2796
来自专栏SDNLAB

SDNLAB技术分享(十一):VXLAN基础知识

之前Arista在欧洲阶段性的有ATF的类似技术论坛的会议, ARISTA TECHNICAL FORUM, 后来到了美国和APAC, 名字改了, 改为CLOU...

4198
来自专栏FreeBuf

WPA2 安全协议惊现高危漏洞,几乎涉及所有 WiFi 设备(附固件升级列表)

近日,鲁汶大学的研究人员 Mathy Vanhoef 在 WPA2 协议中发现了严重的安全漏洞,这对无线网络的安全造成了极大的考验。本文简要介绍了此次攻击的技术...

2449
来自专栏猿湿Xoong

怎么用TWRP刷LineageOS拯救我的Android手机?

8974
来自专栏雨过天晴

我是一个线程 0x3704

1892

扫码关注云+社区

领取腾讯云代金券