Oracle Database 12c查询优化器的缺陷-视图合并会造成查询结果不准确

栏目: 数据库 · Oracle · 发布时间: 7年前

内容简介:Oracle Database 12c查询优化器的缺陷-视图合并会造成查询结果不准确

最近在将一个11g的数据库导入到12c(12.1.0.2,并打了最新的补丁)的库后,测试人员反馈有一个 SQL 执行结果不正确。

具体的SQL如下:

  1. SELECT *
  2.   FROM ( SELECT watnum ,
  3.                  agentcode ,
  4.                  managecom ,
  5.                   SUM ( prem ) AS prem ,
  6.                   SUM ( charge ) AS charge
  7.             FROM ( SELECT ct . card_number ,
  8.                          ct . card_managecode ,
  9.                          cp . riskcode ,
  10.                          cp . riskname ,
  11.                          cp . prem ,
  12.                          csm . watnum ,
  13.                          csm . charge ,
  14.                           SUBSTR ( csm . agentcode , 2 ) AS agentcode ,
  15.                           SUBSTR ( csm . managecom , 2 ) AS managecom
  16.                     FROM card_table @ webapp ct ,
  17.                          ZZHCardSettleMent csm ,
  18.                          CARDPREMIUM @ WEBAPP cp
  19.                     WHERE ct . card_type = cp . cardtype
  20.                           AND csm . idcard = ct . card_number
  21.                           AND csm . checktype = 1
  22.                           AND ct . card_managecode = '8602' )
  23.         GROUP BY watnum , agentcode , managecom ) c
  24.   WHERE NOT EXISTS
  25.           ( SELECT 'Y'
  26.               FROM policyinfo
  27.             WHERE c . watnum = proposalcontno ) ;

由于第一个子查询(我们姑且把它称为C子查询)涉及到DBLINK,所以一开始怀疑DBLINK不一致导致的。但是查看了DBLINK的配置后发现和源11g的配置是一样的,连的都是相同的数据库。

试着单独 C子查询 ,在11g和12c中的执行结果是一样的!

接着试着把 C子查询的结果做成一张表ctemp,用ctemp

代替

C子查询,即:

  1. SELECT *
  2.   FROM ctemp c
  3.   WHERE NOT EXISTS
  4.           ( SELECT 'Y'
  5.               FROM policyinfo
  6.             WHERE c . watnum = proposalcontno ) ;

这时 在11g和12c中的执行 结果是一样的。
接着
试着把 C子查询的结果做成一张试图cvtemp,用 cvtemp 代替 C子查询,即:

  1. SELECT *
  2.   FROM cvtemp c
  3.   WHERE NOT EXISTS
  4.           ( SELECT 'Y'
  5.               FROM policyinfo
  6.             WHERE c . watnum = proposalcontno ) ;

查询的结果出现差异了。仔细观察执行计划,似乎12c中的执行计划有异常,NOT EXISTS这个条件居然没有在执行计划中体现!因为这是在用视图的情况下发生的,所以有理由怀疑12c的优化器在视图合并上是有异常的,那把视图合并禁用掉会是什么情况?

  1. SELECT /*+ NO_MERGE(c) */ *
  2.   FROM cvtemp c
  3.   WHERE NOT EXISTS
  4.           ( SELECT 'Y'
  5.               FROM policyinfo
  6.             WHERE c . watnum = proposalcontno ) ;

这里通过HINT禁用了视图合并,执行结果和11g是一样的了。然后观察执行计划,非常明显的在 禁用了视图合并后多了NOT EXISTS条件的过滤:
filter( NOT EXISTS (SELECT 0 FROM "POLICYINFO" "POLICYINFO" WHERE "PROPOSALCONTNO"=:B1))
而在之前的执行计划中是没有这个过滤的。
考虑到C子查询是个复杂视图,所以尝试在系统层面禁用了复杂视图的合并:

altersystemset"_complex_view_merging"=false;

再执行上述语句时,即使不加HINT也能执行出正确的结果了。
简单视图合并会不会也存在上述类似的问题?这个还有待验证。
12c引入了很多吸引人的功能,比如对租户,比如内存数据库,还有更强大的优化器。但是首要保证的是执行出正确的结果,如果这都无法保证了,那一切都要成为浮云了。

更多Oracle相关信息见 Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12

本文永久更新链接地址 http://www.linuxidc.com/Linux/2017-06/144578.htm


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

A=B

A=B

Marko Petkovsek、Herbert S. Wilf、Doron Zeilberger / AK Peters, Ltd. / 1996-01 / USD 49.00

At some point, this book describes methods of solving the problem raised by Donald E. Knuth in the classical book "The Art of Computer Programming, Volume 1: Fundamental Algorithms". The main purpo......一起来看看 《A=B》 这本书的介绍吧!

XML、JSON 在线转换
XML、JSON 在线转换

在线XML、JSON转换工具

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具