Oracle Database 12c查询优化器的缺陷-视图合并会造成查询结果不准确
最近在将一个11g的数据库导入到12c（12.1.0.2，并打了最新的补丁）的库后，测试人员反馈有一个SQL执行结果不正确。
具体的SQL如下：
由于第一个子查询（我们姑且把它称为C子查询）涉及到DBLINK，所以一开始怀疑DBLINK不一致导致的。但是查看了DBLINK的配置后发现和源11g的配置是一样的，连的都是相同的数据库。
试着单独C子查询，在11g和12c中的执行结果是一样的！
接着试着把C子查询的结果做成一张表ctemp，用ctemp代替C子查询，即：
这时在11g和12c中的执行结果是一样的。
接着试着把C子查询的结果做成一张试图cvtemp，用cvtemp代替C子查询，即：
查询的结果出现差异了。仔细观察执行计划，似乎12c中的执行计划有异常，NOT EXISTS这个条件居然没有在执行计划中体现！因为这是在用视图的情况下发生的，所以有理由怀疑12c的优化器在视图合并上是有异常的，那把视图合并禁用掉会是什么情况？
这里通过HINT禁用了视图合并，执行结果和11g是一样的了。然后观察执行计划，非常明显的在禁用了视图合并后多了NOT EXISTS条件的过滤：
filter( NOT EXISTS (SELECT 0 FROM "POLICYINFO" "POLICYINFO" WHERE "PROPOSALCONTNO"=:B1))
而在之前的执行计划中是没有这个过滤的。
考虑到C子查询是个复杂视图，所以尝试在系统层面禁用了复杂视图的合并：
再执行上述语句时，即使不加HINT也能执行出正确的结果了。
简单视图合并会不会也存在上述类似的问题？这个还有待验证。
12c引入了很多吸引人的功能，比如对租户，比如内存数据库，还有更强大的优化器。但是首要保证的是执行出正确的结果，如果这都无法保证了，那一切都要成为浮云了。
具体的SQL如下：
- SELECT *
- FROM ( SELECT watnum,
- agentcode,
- managecom,
- SUM (prem) AS prem,
- SUM (charge) AS charge
- FROM (SELECT ct.card_number,
- ct.card_managecode,
- cp.riskcode,
- cp.riskname,
- cp.prem,
- csm.watnum,
- csm.charge,
- SUBSTR (csm.agentcode, 2) AS agentcode,
- SUBSTR (csm.managecom, 2) AS managecom
- FROM card_table@webapp ct,
- ZZHCardSettleMent csm,
- CARDPREMIUM@WEBAPP cp
- WHERE ct.card_type = cp.cardtype
- AND csm.idcard = ct.card_number
- AND csm.checktype = 1
- AND ct.card_managecode = '8602')
- GROUP BY watnum, agentcode, managecom) c
- WHERE NOT EXISTS
- (SELECT 'Y'
- FROM policyinfo
- WHERE c.watnum = proposalcontno);
试着单独C子查询，在11g和12c中的执行结果是一样的！
接着试着把C子查询的结果做成一张表ctemp，用ctemp代替C子查询，即：
- SELECT *
- FROM ctemp c
- WHERE NOT EXISTS
- (SELECT 'Y'
- FROM policyinfo
- WHERE c.watnum = proposalcontno);
接着试着把C子查询的结果做成一张试图cvtemp，用cvtemp代替C子查询，即：
- SELECT *
- FROM cvtemp c
- WHERE NOT EXISTS
- (SELECT 'Y'
- FROM policyinfo
- WHERE c.watnum = proposalcontno);
- SELECT /*+ NO_MERGE(c) */ *
- FROM cvtemp c
- WHERE NOT EXISTS
- (SELECT 'Y'
- FROM policyinfo
- WHERE c.watnum = proposalcontno);
filter( NOT EXISTS (SELECT 0 FROM "POLICYINFO" "POLICYINFO" WHERE "PROPOSALCONTNO"=:B1))
而在之前的执行计划中是没有这个过滤的。
考虑到C子查询是个复杂视图，所以尝试在系统层面禁用了复杂视图的合并：
- alter system set "_complex_view_merging"=false;
简单视图合并会不会也存在上述类似的问题？这个还有待验证。
12c引入了很多吸引人的功能，比如对租户，比如内存数据库，还有更强大的优化器。但是首要保证的是执行出正确的结果，如果这都无法保证了，那一切都要成为浮云了。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
