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

查看原文

其他

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

From: 盖国强数据和云 2019-12-14

在之前的文章中，我们阐述了“预警揭秘：倒计时炸弹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 问题的影响，简要再总结一下：

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

以下几点一目了然：

低版本之间通过DB Link互联，不受影响；
低版本和高版本之间通过DB Link互联，可能受到影响，主要取决于高 SCN 系统的高度；
受影响是因为新版本的 SCN 增长算法改变，可能瞬间抬升低版本的 SCN 至越界；
越界只影响跨 DB Link 的访问，不影响本数据库运行；
如果你的系统SCN都很低，增长也很慢，就基本不用担心，不升级也没有问题；

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

11.2.0.4 和 12.1.0.2 及其以上版本，天然自带加持；
11.1.0.7 和 11.2.0.3 版本有补丁，具体见下图，Windows版本和其他平台不同；
其余版本无补丁；

5FAQ

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

SCN的问题和版本有关吗？
任何版本都可能因为SCN增长过快而遭受SCN拒绝，数据库停顿的问题。高版本在尝试解决（这个修正就是），低版本不予修补。
10g受影响吗？
受影响没补丁，但是大前提是有DB Link，如果仅仅是低版本之间访问，没有问题（不受SCN算法变动影响，但是自身SCN过高仍然会有问题），低版本和高版本通过DB Link互访，可能有问题。
高版本和其它低版本通过dblink互联就算中标了，还是其它11g版本打了这次的补丁的才算？
是的，但是仅仅是跨DB Link的SQL失败，高版本数据库本身不受影响。
10.2.0.4和10.2.0.5的RAC受到影响么？
如第一个问题，这两个版本互访都没有问题，和高版本跨DB Link访问才有风险。
这问题会扩展传播吗，如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

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)