Oracle 19C优化器中自动使用了filter操作

文章涉及问题和Oracle 19c版本及新特性并无直接关系，团队正在进行有条不紊的Oracle19c升级工作，刚好此版本遇到问题，影响大且波及范围广，故记录之，以便大家有他山石可引鉴。话不多说，看正文。

问题描述

近期迁移过程中发现，同一条SQL语句在19c上执行效率比在11g低很多。经过大范围跑批、压测、筛查得知，受影响的语句都是带有exists/not exists子查询的语句，平时只需要20分钟完成的跑批流程执行了24小时仍未结束，影响非常大。其中一条语句和两端的执行计划如下：

UPDATE A

SET (A1,A2,A3,A4) =

(SELECT C1,C2,C3,C4

FROM B B, B C

WHERE A.A1 = B.B1

AND B.B2 = C.PRE_B2)

WHERE EXISTS (SELECT 1

FROM B B, B C

WHERE A.A1 = B.B1

AND B.B2 = C.PRE_B2);

问题分析

由上可知，11g和19c的执行计划有一个很明显的差别就是filter操作，在19c环境中优化器居然自动选择了filter"连接方式"。filter被称为改良的nested loop，这个"改良"，体现在驱动表连接列的重复值很多时，filter的性能会稍优于nested loop，而代价是一旦SQL使用了filter连接方式，驱动表只能固定为"外表"无论驱动表返回的结果是否足够小。上述案例中子查询不展开的情形是，从A表中获取的每1条数据，都要代入子查询中进行匹配，对于如此量级的A表来说，这简直是场噩梦……

经常做SQL优化都知道，90%以上的filter连接都会引起性能问题，且每次引起问题都很"惊世骇俗"，解决这个问题的方法很多，最简单的是使用 /*+ unnest */提示优化器将子查询展开。如上SQL使用hint优化后执行计划"恢复"正常，执行时间从5小时下降至20秒，逻辑读从32682915下降至51073，性能提升非常明显，然而整个系统中这类SQL数量过多，一一修改，恐难尽。产生问题的根本原因，仍需要进一步挖掘，通过执行计划outline显示目标库19c中修改了优化器的隐含参数，如下：

这些隐含参数中有多个都与子查询以及查询转换有关。经反复执行排查验证发现，导致执行计划选择低效filter的罪魁祸首就是_optimizer_squ_bottomup和_optimizer_cost_based_transformation

（两个参数同时修改起作用）

参数解释

当优化器参数改变，特别是核心参数改变，势必会导致算法发生变化，优化器评估当前系统中SQL的执行计划必然会受到影响，当面对复杂查询时，很可能选择了一条错误的路径。以下列举相关参数解释。

_optimizer_squ_bottomup

优化器相关参数，与布隆过滤相关，默认值为true。默认开启子查询自底向上的展开功能（案例中filter是子查询不展开）。此参数和案例中的exists解析关系密切。

_optimizer_cost_based_transformation

优化器相关参数，查询转换相关，默认值为linear。参数值如下："exhaustive", "iterative", "linear", "on", "off"。这个参数和_optimizer_squ_bottomup参数同时作用，和案例中的filter关系密切。

_optimizer_enhanced_join_elimination

优化器相关参数，默认值为true，修复Bug 29182901外链接产生错误的结果集。ONLY FOR 19.3.0.0.0。

_optimizer_reduce_groupby_key

优化器相关参数，默认值为true，禁用新特性，建议修改为FALSE。

_optimizer_aggr_groupby_elim

默认值为true，wrong results相关的bug可以通过这个参数进行一定程度的规避。

_optimizer_null_accepting_semijoin

默认值为ture，修复 EXIST可能产生的结果集错误的问题。(Doc ID 2532531.1)。

上述参数_optimizer_squ_bottomup和_optimizer_cost_based_transformation设置默认值，优化器正常选择连接方式，如nested loop、hash join、sort merge join。修改后(设置为false和off)，优化器会更趋向于选择子查询不展开，即filter。

问题解决

1.在语句级加hint验证修改参数的作用

/*+ OPT_PARAM

(_optimizer_squ_botto

mup,'true')，

OPT_PARAM(_optimizer_cost_based

_transformation,'linear')*/

2.如果新环境大量SQL语句存在上述问题，则需系统级将优化器参数恢复到默认值（立即生效，不用重启数据库）

alter system set "_optimizer_squ_bottomup" = true scope =both sid ='*';

alter system set "_optimizer_cost_based_transforma

tion" =linear scope =both sid ='*';

值得注意的是：并非所有filter都是低效的，当我们将参数恢复默认时，需要特别关注原来使用filter的执行计划，防止本来正确的执行计划会因为参数修改而跑偏。

结语

一般来说，在没有遇到bug的情况下，优化器参数非常不建议修改，保持默认值即可。当为了修复某个bug而系统级修改优化器参数时，必须进行相关SQL性能测试验证，必要时使用oracle spa对两端环境做完整的SQL性能验证，防止牵一发而动全身，引起诸多不适。

Oracle 19C优化器中自动使用了filter操作相关推荐

实践实战：在PoC中的Oracle 12c优化器参数推荐（含PPT）
最近,Oracle数据库优化器的产品经理 Nigel Bayliss 发布了一篇文档,介绍:Setting up the Oracle Optimizer for PoCs - 在PoC测试中优化器参 ...
oracle sql 查询优化器,基于ORACLE成本优化器的SQL查询优化分析与应用
第 39 卷第 2 期2018 年 3 月内蒙古农业大学学报( 自然科学版 ) Journal of Inner Mongolia Agricultural University ( Na ...
oracle 两种优化器,Oracle的优化器有两种优化方式(一)
Oracle的优化器有两种优化方式(整理), 2010-04-13 RBO方式:基于规则的优化方式(Rule-Based Optimization,简称为RBO) 优化器在分析SQL语句时,所遵循的 ...
崔华 oracle简历,Oracle ACE崔华解析Oracle数据库优化器
[IT168专稿]第三届Oracle技术嘉年华再度来袭!作为国内顶尖级别的Oracle数据库技术盛会,现场邀请到Jonathan Lewis,Tim Gorman等Oracle数据库领域国际级专家,特 ...
深度学习优化器中的变形金刚：Ranger21
论文题目:RANGER21: A SYNERGISTIC DEEP LEARNING OPTIMIZER 论文链接:https://arxiv.org/pdf/2106.13731.pdf 1 Ran ...
RMSpro优化器中rho与decay 两参数的区别（keras)
最近在学习 efficienet 使用了 RMSProp 优化器,但是在 keras 使用的时候发现了问题 keras.optimizers.RMSprop(lr=0.001, rho=0.9, ep ...
Oracle数据库优化器的优化方式
Oracle是世界领先的信息管理软件开发商,因其复杂的关系数据库产品而闻名.本文介绍Oracle优化器,它是一个非常好用的工具.Oracle在执行一个SQL之前,首先要分析一下语句的执行计划,然后再按 ...
Oracle中的优化器--CBO和RBO
Oracle中的优化器--CBO和RBO Oracle数据库中的优化器又叫查询优化器(Query Optimizer).它是SQL分析和执行的优化工具,它负责生成.制定SQL的执行计划.Oracle的 ...
oracle 非等值关联优化,Oracle优化器、优化模式、表的连接方式（Hash Join、Nested Loop、Sort Merge Join）...
查询优化器 Oracle的查询优化器(QO)分为两种: 1. RBO:Ruled-Based Optimization, 基于规则的优化器: 2. CBO :Cost-Based Optimizati ...

Oracle 19C优化器中自动使用了filter操作

Oracle 19C优化器中自动使用了filter操作相关推荐

最新文章

热门文章