Oracle
Allen 2022-07-19 17:32:20 11936 0 0 0 0
Oracle,Oracle版本,随着版本号的变化,补丁策略也随之改变,自18c开始, Oracle推出RU策略(Release Update),每个季度发布一个RU,所以对应18c,我们看到的RU系列版本号就是18.1,18.2等等,RU是一个累积的增量补丁,也就是说后发布的包含之前RU的内容

2020-04-25 07:47

众所周知,自 Oracle 18c开始,Oracle将数据库的版本发布变更为年度发布,以践行敏捷迭代的研发理念。所谓年度发布 也就是按照年份,每年发布一个版本。2018年发布了Oracle 18c,2019年是Oracle 19c,2020年发布Oracle 20c( 20c 云上版本已经在2月14日发布,按照官方计划公众发布是在4月)。

这其中,18c = 12.2.0.2,19c = 12.2.0.3,这两个年度版本仍然处于 12c 的发布序列中, 19c 属于 12c 体系的最后一个版本。由于 11g 已经退出了官方支持序列,越来越多的用户开始升级到 19c 。

随着版本号的变化,补丁策略也随之改变,自18c开始, Oracle推出RU策略(Release Update),每个季度发布一个RU,所以对应18c,我们看到的RU系列版本号就是18.1,18.2等等,RU是一个累积的增量补丁,也就是说后发布的包含之前RU的内容,如果我们从18.1开始,可以直接应用18.4,跳过其间的18.2和18.3版本。

由于每个季度的间隔事实上很大,如果期间用户报告了安全问题或严重的Bug,那么 针对每个RU,Oracle还可能发布最多两个RUR(Release Update Revision)修订版本,其中主要包含安全补丁和重要的回归修复。

下图是新策略下的Oracle数据库版本发布计划表:

这个图,可能会让大多数人看得头晕,但是升级路径有一个原则,记住这个原则就一目了然了。这个原则就是: 主版本号后面的2个数字之和要小于等于目标版本。例如 18.8.2 的低位 8+2 =10,这个版本可以升级到 18.10.0 ,但是不可以升级到 18.9.0,因为 9+0 < 10 。

当然,在非特殊情况下,官方推荐采取 RU 路线的更新策略,这看起来就简化多了:

当我们进行大版本升级时,总是建议用户通过SPA(SQL Performance Analyzer),对源环境和目标版本之间的测试,以避免出现SQL的兼容性问题或者性能问题,通过在源库进行SQL捕获,在目标库(通常是升级的高版本)进行重演,并生成性能对比报告,以指导用户的升级变更:

而对于小版本的升级,往往无法进行如此详尽的测试准备工作,这就需要我们能够预先收集已知问题并做出防范。

在进行数据库升级时,SQL 是最容易受到影响的部分,这些影响包括:

SQL 语法发生改变:原应用SQL出错无法正确执行或执行结果发生改变;

内部函数改变:函数返回值或返回值类型发生变化,导致SQL结果出错或异常;

执行计划改变:因为算法调整,SQL的执行计划发生改变,一部分执行计划变坏,影响性能;

新特性的BUG:往往新特性引入,会带来相应的新BUG,影响系统性能或者稳定性;

次生BUG:因为修复某些BUG,而引入的新BUG,导致SQL可能出现不兼容或其他错误和异常;

本文针对SQL方面的几个 19c 中典型案例,作为范例,希望能够为即将升级到 19c的朋友们提供一些经验借鉴。考虑到这些内容是DBA们知识储备的一部分,所以在一些知识点上做了介绍和扩展。

1. Oracle 19.3 中优化器问题导致的执行结果错误

在 Oracle 数据库跨版本升级时,很多SQL的新特性被引入到数据库中来,不可避免的,一些BUG会潜移默化的发生。而我们认为, 最让人困扰的是那些SQL不出异常,但是查询结果出错的语句,这类SQL很难通过测试发现,只能在人们注意到查询结果出错时,才会追究并发现问题。

以下就是这样一个问题,在 19.3 版本中广泛存在。创建简单的测试表和测试数据:

CREATE TABLE ENMO AS SELECT * FROM DBA_OBJECTS;

UPDATE ENMO SET EDITION_NAME = 'ORA$BASE' WHERE MOD(ROWNUM, 10000) = 0;

CREATE TABLE TECH AS SELECT ROWNUM ID FROM ENMO;

analyze table ENMO compute statistics;

...

此时执行如下查询,可以从结果看到返回了2个零值,这个结果显然是错误的:

set autotrace on

SELECT COUNT(OBJECT_NAME ||','|| OBJECT_TYPE), COUNT(EDITION_NAME) FROM ENMO, TECH WHERE ID = OBJECT_ID;

COUNT(OBJECT_NAME||’,’||OBJECT_TYPE) COUNT(EDITION_NAME)------------------------------------ -------------------0 0

在以下执行计划中,可以看出执行计划的错误出现在第三个步骤,在这个步骤中,通过Filter增加了一个 NOT NULL 的过滤,这就使得大部分数据被抛弃了,进一步向上的查询连接自然就出现了结果集的错误:

...

那么正常的情况应该是如何呢?去掉第二个输出,可以获得以下结果:

SELECT COUNT(OBJECT_NAME ||','|| OBJECT_TYPE) FROM ENMO, TECH WHERE ID = OBJECT_ID;

COUNT(OBJECT_NAME||','||OBJECT_TYPE)------------------------------------71789

...

经过确认,这是一个因为修复BUG而引入的BUG。Oracle最为强大的地方是,几乎为每一个修正都加入了一个开关,如果发现某个修正引起了新的问题,那么通过开关就可以恢复原有的工作方式。

...

以下语句就关闭了这个修复:

alter session set "_fix_control"='24761824:OFF';

Session altered.

...

再来看现在的执行计划,去掉了 NOT NULL 的过滤,SQL执行结果恢复了正常:

...

那么这个BUG是如何发生的呢?


Tag: Oracle Oracle版本
我也要发一个   ·   返回首页   ·   返回[Oracle]   ·   前一个   ·   下一个
欢迎评论
未登录,
请先 [ 注册 ] or [ 登录 ]
(一分钟即可完成注册!)
返回首页     ·   返回[Oracle]   ·   返回顶部