ANBOB™

Oracle MOS中新发布预警对于版本和对应版本的已安装PSU高于11.1.0.7.20，11.2.0.7.57(for Windows), 11.2.0.3.9，11.2.0.3.29 (for Windows), 11.2.0.3 BP22(for Exadata),  11.2.0.4，12.1.0.2 ，12.2.0.1 的Oracle 数据库， 将在2019年06月23日后自动调整SCN的增长速率为更大的上限，DBLINK 在不同数据库之间访问时会同步SCN， 为了避免不同SCN 上限数据库之间因SCN拒接访问，建议所有DBLINK访问的数据库升级为相同的SCN 兼容性。

Note: 如果不使用DBLINK，或也不存在scn headroom问题，可以不安装该补丁。

背景

Oracle的MOS上发布了两篇与DB Link（数据库链接）相关的预警文章，它们分别是：

• Mandatory Patching Requirement for Database Versions 11.2.0.3 or Earlier, Using DB Links (文档1)
• ANNOUNCEMENT: Recommended patches and actions for Oracle databases versions 12.1.0.1, 11.2.0.3 and earlier – before June 2019 (文档 ID 2361478.1)

注意里面用到了Mandatory（必须的）这个词，引起一片恐慌，但是没隔几天，Oracle又重新修改了用词，把Mandatory（必须的）换成了Recommended（建议的）。 建议在2019年4月份前安装上对应的补丁和升级版本，实际的SCN新兼容性变化时间是2019年06月24日。

Oracle如何自动触发的?

在高版本的数据库中引入了SCN 兼容性特性( Compatibility)，而且在这个特性中设置了时间限制。在Oracle数据库软件内核中， 引入了一个：Auto-RollOver 的机制，也就是说Oracle 为不同 SCN 兼容性设定了触发时间，随着时间推移自动迭代，用户会在不知情的情况下自动应用了新的SCN 兼容性。

应用了补丁在2019年6月23后会发生什么？

不同的SCN兼容性又有不同的SCN速率限制，会有不同的SCN RSL(当前时间点的允许的最大SCN ).Oracle 为每个 SCN 的兼容性设置了时间点, 2019年6月23日直接跳级到兼容性 3， 3 级允许更高的 SCN 增长率, 但并不改变系统中SCN自身变化的速率，也不会修改当前的SCN，只是让系统在当前时间点可以生成更大的SCN，应对更忙的数据库，更高的事务速率。

如果所有数据库的事务处理速率没有任何重大变化, SCN都低于低速率的当前最大SCN允许值，应用补丁和未应用补丁的数据之间使用DBLINK还是可以正常的访问，不受应用补丁后允许更大速率的影响。

如果应用了补丁数据允许更大的增长速率，同时因为数据库SCN使用较快比如超过了32K每秒， 那当前SCN如果超过了未打补丁数据库的最大SCN，两个库通过DBLINK访问时就会因为无法同步SCN，而访问会被拒绝。

SCN 兼容级别

上面介绍了SCN兼容性级别的调整会改变SCN允许的最大增长速率限制和RSL（允许的SCN最大限制）， 从11.2.0.4版本数据库提供了一个dbms_scn package ，可以查看当前的SCN兼容级别，在$ORACLE_HOME/rdbms/admin/dbmsscnc.sql中可以找到其定义。使用这个package也可以启停Auto-rollover特性，和下一次调整的行为。

如何查看当前的SCN兼容性级别？

当前scn 兼容级别是1，最大级别为3

如何查看下一次SCN兼容性级别的调整？

当前auto rollover是启用的， 会在2019-6-23自动调整SCN兼容级别为3

SCN兼容级别和Auto-RollOver的关系？

SCN 兼容级别是限制SCN增速和SCN RSL， Auto -rollover 是一种类例JOB的任务，定时修改SCN 兼容性级别， 禁用了AUTO-ROLLOVER 到2019-06-23后SCN兼容级别就不会自动调整，还保持原来的限制。 禁用了Auto-RollOver，可以手动调整scn兼容性(前提是应用了补丁)。

如何禁用、启用Auto-RollOver?

同样使用DBMS_SCN包，禁用执行

exec DBMS_SCN.DISABLEAUTOROLLOVER;

启用执行

EXEC DBMS_SCN. ENABLEAUTOROLLOVER;

如何禁用SCN兼容级别自动调整，手动调整级别?

目前禁用Auto-RollOver就可以禁用SCN兼容性的自动调整，这样已安装补丁的数据库在2019年6月23日不会有新变化。

手动可以调整SCN兼容性，执行

ALTER DATABASE SETSCN COMPATIBILITY N;   — N可以是1，2，3

不同SCN Compatibility的区别

以2018-4-20一个11.2.0.4的数据库为例，不同SCN兼容性的区别。

为什么引入这样的修改和补丁？

SCN 是 Oracle 的一致性的核心，为了应对更高的事务率，和解决SCN Headroom问题，需要引入新的SCN算法。

本次预警影响的数据库版本？

在本次预警涉及的变化，在11.1.0.7.20+ /11.2.0.3.9+ /11.2.0.4+/ 12.1.0.2+/ 12.2.0.1+ 版本已经包含对应的补丁，实现了关于SCN兼容性自动修改的新特性，默认将会在2019年6月23日之后改变SCN的兼容性为3， 增强了SCN的增长速率限制和最大允许SCN限制。

对于11g之前的版本需要升级，和11G版本安装PSU 来达到SCN 兼容级别的统一，避免因不同SCN兼容性级别，在后期SCN 访问时的限制而拒绝连接。

该补丁实现了什么功能？

补丁本身并不针对某个具体bug进行修复，是内部特性的增强，意在调整SCN的增速上限和当前最大允许SCN的策略， 规避SCN增长过快的系统可能遇到的“SCN Headroom（SCN天花板）”问题，注：这个补丁并不改变系统中SCN本身的变化的速率，只是可允许的系统中SCN的变化率和当前SCN最大值较之前增长数倍。

这个补丁是怎么影响到DBLink的？

打了补丁的系统与未打补丁的系统的SCN不同的增长速率限制不同，如果打了补丁的系统确实非常繁忙，SCN增长快且最大允许SCN限制高，而未打补丁系统SCN增长上限不变，这样在新旧系统间通过DB Link同步SCN时，可能因为打补丁的系统SCN超过未打补丁系统的“RSL”而出现问题；但是，上述问题出现的前提是：新系统运行确实非常繁忙，SCN增长速度确实足够快，这与补丁本身无关, 有效的解决办法还是找到SCN增长的根源。

注： 如果不使用DBLINK，而且也不存在scn headroom，可以不安装该补丁。

不升级/不打补丁现有DB Link或数据库就必然会有问题吗？

不是！系统SCN的变化是基于系统的繁忙情况，事务的多少和DBLINK的同步， 在打上该补丁后，系统SCN的变化速度并不改变，只是允许系统上支持更繁忙事务和当前SCN允许更大的值，这样在通过DBLINK同步到其他低SCN又未打补丁的系统上时，才会有可能造成DB link访问拒绝或其它未知问题。

升级/打补丁之后DB Link因SCN拒绝或SCN headroom就不存在了么？

不是。 该补丁本质只是增大了SCN增长速度和上限限制，如果某系统上依然存在bug或其他原因导致SCN的异常增长， 即使是所有系统都打上了该补丁，DB Link间的SCN同步依然会发生，同样会将SCN的异常传播到整个DB Link网络，SCN HEADROOM依然存在。

对于10.2 版本以及更早版本影响

如果不存在SCN headroom问题和也不存在DBLINK 指向已安装补丁的数据库，可以不在任何改变；

2019年6月之后，如果老版本数据库和已安装了补丁并使用了新的SCN兼容性的数据库存在dblink，如果已安装补丁数据库SCN 使用速度没有变化（虽然已允许更快的速率），老版本的DBLINK 仍可以正常访问； 如果DBLINK 另一端已安装补丁的数据库SCN 增长超过了16K, 可能就会因为DBLINK 同步老版本的数据库SCN导致SCN headroom问题甚至拒绝链接，并且那时需要断开这些dblink 连接或升级。Oracle研发目前正在评估为10.2提供补丁的需求和可行性. 也到2019年还在陆续发布补丁。

— update 20180924

当前10.2.0.5 的补丁已发布，对于10G R2版本的客户如果不想做大版本升级，可以升级到10.2.0.5， 安装PATCH 26493118 (10.2.0.5.171017)补丁和补丁14121009(引入scn compatibility)解决该问题.  注：但是10.2.0.5.171017需要有ECS服务的用户才可以下载，也有一种非官方方法，可以安装10.2.0.5.12 PSU(引入_external_scn_rejection_threshold_hours)+补丁14121009 同样也可以启到相应的效果.

— update 20190801

当前已对10.2.0.4 同样也提供了解决办法， 安装10.2.0.4.4 PSU 和补丁14121009。

对于11.2.0.4,12.1.0.2和12.2.0.1版本数据库需要做什么？

什么都不用做， 所有需要的修补程序已包含在这些版本中，但是并不是SCN就不会有SCN headroom，只是概率非常低，很少有数据库事务率会使用SCN每秒增长超过90多K.

未安装补丁的数据库dblink间是否会有问题？

不会， 两个未修复的数据库或两个旧版本的数据库之间，如10204以前,9i的版本数据dblink连接不受此更改的影响。

应该优先处理什么样的系统？

综上，我们应该优先处理环境中目前是否存在SCN增长过快的系统和SCN headroom天数较小的系统。

建议检查目前环境中的所有数据库的SCN值和headroom是否都大于30天。

如何查看具体的DBLINK信息？

所有的数据库版本可以使用DBA_DB_LINKS视图查看现在数据库中存在的DBLINK.

对于12.1以后的数据库可以查询dba_db_link_sources视图查看。

从12.2 版本起数据库提供了DBA_EXTERNAL_SCN_ACTIVITY 视图可以排查SCN 的跳跃信息，更新信息查看MOS note ID 2171090.1

如果需要升级，升级方案

对于老版本的数据库，建议升级，升级列表汇总如下:

PSU 安装方法

略

— 如果有疑问和升级需求可以QQ: 85304522 联系我 —

打赏

微信扫一扫，打赏作者吧～