前言

前些天优化了一些耗费buffers较多的SQL,但系统CPU降低的效果不明显,于是又拉了awr报告,查看了SQL ordered by Gets排名前列的SQL。

分析

SQL代码:

select distinct pro5.value as CUSTOMERCODE,
to_date('19000101000000', 'yyyymmddhh24miss') as LAST_UPDATE_TIME,
pro2.value as NAME,
nvl(pro3.value, '$$400006000004') as GENDER,
decode(pro4.value,
'$$400003000001',
decode(length(trim(pro5.value)),
18,
substr(trim(pro5.value), 7, 8)),
null) as BIRTHDAY,
decode(pro4.value, '$$400003000001', pro5.value, null) as CERT_NO,
pro4.value as CERTIFICATE_TYPE,
pro5.value as CERTIFICATE_NO,
null as NATION,
null as EFFECTIVE_DATE,
null as EXPIRE_DATE
from policy p
inner join role r
on p.topactualid = r.topactualid
and r.kind = 'INSURANCECERTIFICATELIST'
inner join property pro2
on r.topactualid = pro2.topactualid
and r.actualid = pro2.parentactualid
and r.parentagreementid = pro2.parentagreementid
and r.topagreementid = pro2.topagreementid
and pro2.kind = 'CUSTOMERNAME'
inner join property pro3
on r.topactualid = pro3.topactualid
and r.actualid = pro3.parentactualid
and r.parentagreementid = pro3.parentagreementid
and r.topagreementid = pro3.topagreementid
and pro3.kind = 'PERSONSEX'
inner join property pro4
on r.topactualid = pro4.topactualid
and r.actualid = pro4.parentactualid
and r.parentagreementid = pro4.parentagreementid
and r.topagreementid = pro4.topagreementid
and pro4.kind = 'CERTIFICATETYPE'
inner join property pro5
on r.topactualid = pro5.topactualid
and r.actualid = pro5.parentactualid
and r.parentagreementid = pro5.parentagreementid
and r.topagreementid = pro5.topagreementid
and pro5.kind = 'CERTIFICATECODE' and pro5.value is not null
left join endorsement e
on p.endorsementid = e.endorsementid
where p.productcode = '00070002'
and p.currentflag = 'Y'
and (p.uniquecode like '013100%' or p.uniquecode like '011000%')
and ((p.policystatus = '$$900001103001') or
(e.endorsementstatus = '$$900002106001' and
e.ISSUEDATE > to_date('20160411', 'YYYYMMDD')))

执行计划:

Plan hash value: 3936231819

------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 336 | 124K (1)| 00:24:55 |
| 1 | HASH UNIQUE | | 1 | 336 | 124K (1)| 00:24:55 |
| 2 | NESTED LOOPS | | 1 | 336 | 124K (1)| 00:24:55 |
| 3 | NESTED LOOPS | | 1 | 284 | 124K (1)| 00:24:55 |
| 4 | NESTED LOOPS | | 1 | 232 | 124K (1)| 00:24:55 |
| 5 | NESTED LOOPS | | 51 | 9180 | 124K (1)| 00:24:50 |
| 6 | NESTED LOOPS | | 14950 | 1868K| 11388 (1)| 00:02:17 |
|* 7 | FILTER | | | | | |
| 8 | NESTED LOOPS OUTER | | 701 | 58183 | 6559 (1)| 00:01:19 |
|* 9 | TABLE ACCESS FULL | POLICY | 2661 | 129K| 5834 (1)| 00:01:11 |
| 10 | TABLE ACCESS BY INDEX ROWID | ENDORSEMENT | 1 | 33 | 1 (0)| 00:00:01 |
|* 11 | INDEX UNIQUE SCAN | ENDORSEMENT_PK | 1 | | 0 (0)| 00:00:01 |
|* 12 | TABLE ACCESS BY INDEX ROWID | ROLE | 21 | 945 | 25 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN | TC_ROLE66 | 453 | | 4 (0)| 00:00:01 |
|* 14 | TABLE ACCESS BY INDEX ROWID | PROPERTY | 1 | 52 | 124K (1)| 00:24:50 |
| 15 | BITMAP CONVERSION TO ROWIDS | | | | | |
| 16 | BITMAP AND | | | | | |
| 17 | BITMAP CONVERSION FROM ROWIDS| | | | | |
|* 18 | INDEX RANGE SCAN | TC_PROPERTY_PARENT | 12 | | 3 (0)| 00:00:01 |
| 19 | BITMAP CONVERSION FROM ROWIDS| | | | | |
|* 20 | INDEX RANGE SCAN | TC_PROPERTY24 | 12 | | 3 (0)| 00:00:01 |
|* 21 | TABLE ACCESS BY INDEX ROWID | PROPERTY | 1 | 52 | 13 (0)| 00:00:01 |
|* 22 | INDEX RANGE SCAN | TC_PROPERTY_PARENT | 12 | | 3 (0)| 00:00:01 |
|* 23 | TABLE ACCESS BY INDEX ROWID | PROPERTY | 1 | 52 | 3 (0)| 00:00:01 |
|* 24 | INDEX RANGE SCAN | TC_PROPERTY_PARENT | 12 | | 3 (0)| 00:00:01 |
|* 25 | TABLE ACCESS BY INDEX ROWID | PROPERTY | 1 | 52 | 3 (0)| 00:00:01 |
|* 26 | INDEX RANGE SCAN | TC_PROPERTY_PARENT | 12 | | 3 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------------ Predicate Information (identified by operation id):
--------------------------------------------------- 7 - filter("P"."POLICYSTATUS"='$$900001103001' OR "E"."ENDORSEMENTSTATUS"='$$900002106001' AND
"E"."ISSUEDATE">TIMESTAMP' 2016-04-11 00:00:00')
9 - filter("P"."PRODUCTCODE"='00070002' AND ("P"."UNIQUECODE" LIKE '013100%' OR "P"."UNIQUECODE"
LIKE '011000%') AND "P"."CURRENTFLAG"='Y')
11 - access("P"."ENDORSEMENTID"="E"."ENDORSEMENTID"(+))
12 - filter("R"."KIND"='INSURANCECERTIFICATELIST')
13 - access("P"."TOPACTUALID"="R"."TOPACTUALID")
14 - filter("PRO5"."VALUE" IS NOT NULL AND "PRO5"."KIND"='CERTIFICATECODE' AND
"R"."PARENTAGREEMENTID"="PRO5"."PARENTAGREEMENTID" AND "R"."TOPAGREEMENTID"="PRO5"."TOPAGREEMENTID")
18 - access("R"."ACTUALID"="PRO5"."PARENTACTUALID")
20 - access("R"."TOPACTUALID"="PRO5"."TOPACTUALID")
21 - filter("PRO2"."KIND"='CUSTOMERNAME' AND "R"."TOPACTUALID"="PRO2"."TOPACTUALID" AND
"R"."PARENTAGREEMENTID"="PRO2"."PARENTAGREEMENTID" AND "R"."TOPAGREEMENTID"="PRO2"."TOPAGREEMENTID")
22 - access("R"."ACTUALID"="PRO2"."PARENTACTUALID")
23 - filter("PRO4"."KIND"='CERTIFICATETYPE' AND "R"."TOPACTUALID"="PRO4"."TOPACTUALID" AND
"R"."PARENTAGREEMENTID"="PRO4"."PARENTAGREEMENTID" AND "R"."TOPAGREEMENTID"="PRO4"."TOPAGREEMENTID")
24 - access("R"."ACTUALID"="PRO4"."PARENTACTUALID")
25 - filter("PRO3"."KIND"='PERSONSEX' AND "R"."TOPACTUALID"="PRO3"."TOPACTUALID" AND
"R"."PARENTAGREEMENTID"="PRO3"."PARENTAGREEMENTID" AND "R"."TOPAGREEMENTID"="PRO3"."TOPAGREEMENTID")
26 - access("R"."ACTUALID"="PRO3"."PARENTACTUALID")

分析:

1)执行计划中 id = 15 关键字为BITMAP CONVERSION TO ROWIDS,此关键字在此之前都未遇见过,于是谷歌下,有了以下解释:

1)出现这样的情况,是因为表中存在不适当的索引,这些索引列的唯一度不高,oracle就有可能选择两个这样的索引转为bitmap来执行

2)根据这两个索引的值再确认共同有的ROWID,最后再通过ROWID回表提取符合条件的数据。

2) 可以使用/*+ opt_param('_b_tree_bitmap_plans','false') */hint 在sql级消除bitmap

3) 也可以删除选择率低的索引,建立复合索引进行改善

4) 根据执行计划的谓词信息,我建立了如下索引:

create index IDX_POLICY_01 on POLICY (PRODUCTCODE, CURRENTFLAG, UNIQUECODE);

create index IDX_PROPERTY_TEST02 on PROPERTY (KIND, PARENTACTUALID, TOPACTUALID, PARENTAGREEMENTID, TOPAGREEMENTID, VALUE) nologging;

5)建立索引后的执行计划:

Plan hash value: 2001935116

-----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 336 | 10938 (1)| 00:02:12 |
| 1 | HASH UNIQUE | | 1 | 336 | 10938 (1)| 00:02:12 |
| 2 | NESTED LOOPS | | 1 | 336 | 10937 (1)| 00:02:12 |
| 3 | NESTED LOOPS | | 1 | 284 | 10934 (1)| 00:02:12 |
| 4 | NESTED LOOPS | | 1 | 232 | 10931 (1)| 00:02:12 |
| 5 | NESTED LOOPS | | 1 | 180 | 10928 (1)| 00:02:12 |
| 6 | NESTED LOOPS | | 875 | 109K| 8301 (1)| 00:01:40 |
|* 7 | FILTER | | | | | |
| 8 | NESTED LOOPS OUTER | | 300 | 24900 | 6500 (1)| 00:01:19 |
|* 9 | TABLE ACCESS FULL | POLICY | 2776 | 135K| 5751 (1)| 00:01:10 |
| 10 | TABLE ACCESS BY INDEX ROWID| ENDORSEMENT | 1 | 33 | 1 (0)| 00:00:01 |
|* 11 | INDEX UNIQUE SCAN | ENDORSEMENT_PK | 1 | | 0 (0)| 00:00:01 |
|* 12 | TABLE ACCESS BY INDEX ROWID | ROLE | 3 | 135 | 6 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN | TC_ROLE66 | 62 | | 3 (0)| 00:00:01 |
|* 14 | INDEX RANGE SCAN | IDX_PROPERTY_TEST02 | 1 | 52 | 3 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | IDX_PROPERTY_TEST02 | 1 | 52 | 3 (0)| 00:00:01 |
|* 16 | INDEX RANGE SCAN | IDX_PROPERTY_TEST02 | 1 | 52 | 3 (0)| 00:00:01 |
|* 17 | INDEX RANGE SCAN | IDX_PROPERTY_TEST02 | 1 | 52 | 3 (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id):
--------------------------------------------------- 7 - filter("P"."POLICYSTATUS"='$$900001103001' OR "E"."ENDORSEMENTSTATUS"='$$900002106001' AND
"E"."ISSUEDATE">TIMESTAMP' 2016-04-11 00:00:00')
9 - filter("P"."PRODUCTCODE"='00070002' AND ("P"."UNIQUECODE" LIKE '013100%' OR
"P"."UNIQUECODE" LIKE '011000%') AND "P"."CURRENTFLAG"='Y')
11 - access("P"."ENDORSEMENTID"="E"."ENDORSEMENTID"(+))
12 - filter("R"."KIND"='INSURANCECERTIFICATELIST')
13 - access("P"."TOPACTUALID"="R"."TOPACTUALID")
14 - access("R"."ACTUALID"="PRO4"."PARENTACTUALID" AND "R"."TOPACTUALID"="PRO4"."TOPACTUALID"
AND "R"."PARENTAGREEMENTID"="PRO4"."PARENTAGREEMENTID" AND
"R"."TOPAGREEMENTID"="PRO4"."TOPAGREEMENTID" AND "PRO4"."KIND"='CERTIFICATETYPE')
15 - access("R"."ACTUALID"="PRO3"."PARENTACTUALID" AND "R"."TOPACTUALID"="PRO3"."TOPACTUALID"
AND "R"."PARENTAGREEMENTID"="PRO3"."PARENTAGREEMENTID" AND
"R"."TOPAGREEMENTID"="PRO3"."TOPAGREEMENTID" AND "PRO3"."KIND"='PERSONSEX')
16 - access("R"."ACTUALID"="PRO2"."PARENTACTUALID" AND "R"."TOPACTUALID"="PRO2"."TOPACTUALID"
AND "R"."PARENTAGREEMENTID"="PRO2"."PARENTAGREEMENTID" AND
"R"."TOPAGREEMENTID"="PRO2"."TOPAGREEMENTID" AND "PRO2"."KIND"='CUSTOMERNAME')
17 - access("R"."ACTUALID"="PRO5"."PARENTACTUALID" AND "R"."TOPACTUALID"="PRO5"."TOPACTUALID"
AND "R"."PARENTAGREEMENTID"="PRO5"."PARENTAGREEMENTID" AND
"R"."TOPAGREEMENTID"="PRO5"."TOPAGREEMENTID" AND "PRO5"."KIND"='CERTIFICATECODE')
filter("PRO5"."VALUE" IS NOT NULL)

优化后

建立索引后,sql从原来的450s降低到20s,buffers 消耗也显著降低。

当执行计划中出现BITMAP CONVERSION TO ROWIDS关键字时,需要注意了。的更多相关文章

  1. SQL Server 2000中的并行处理和执行计划中的位图运算符

    SQL Server 2000中的并行处理和执行计划中的位图运算符 摘抄自:SQLServer 2000并行处理和位图简介 刘志斌 并行查询介绍Degree of Parallelism(并行度) 一 ...

  2. 浅析SQL SERVER执行计划中的各类怪相

    在查看执行计划或调优过程中,执行计划里面有些现象总会让人有些疑惑不解: 1:为什么同一条SQL语句有时候会走索引查找,有时候SQL脚本又不走索引查找,反而走全表扫描? 2:同一条SQL语句,查询条件的 ...

  3. [转载] EXPLAIN执行计划中要重点关注哪些要素

    原文: https://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ==&mid=400738936&idx=1&sn=2910b4119b9 ...

  4. SQL Server 执行计划中的扫描方式举例说明

    SQL Server 执行计划中的扫描方式举例说明 原文地址:http://www.cnblogs.com/zihunqingxin/p/3201155.html 1.执行计划使用方式 选中需要执行的 ...

  5. 执行计划中常见index访问方式(转)

    近期有朋友对于单个表上的index各种情况比较模糊,这里对于单个表上,单个index出现的大多数情况进行了总结性测试,给出了测试结果,至于为什么出现这样的试验结果未做过多解释,给读者留下思考的空间.本 ...

  6. MySQL 执行计划中Extra(Using where,Using index,Using index condition,Using index,Using where)的浅析

      关于如何理解MySQL执行计划中Extra列的Using where.Using Index.Using index condition,Using index,Using where这四者的区别 ...

  7. 解读EXPLAIN执行计划中的key_len(转)

    原文:http://imysql.com/2015/10/20/mysql-faq-key-len-in-explain.shtml 导读 EXPLAIN中的key_len一列表示什么意思,该如何解读 ...

  8. EXPLAIN执行计划中要重点关注哪些要素(叶金荣)

    原文:http://mp.weixin.qq.com/s/CDKN_nPcIjzA_U5-xwAE5w 导读 EXPLAIN的结果中,有哪些关键信息值得注意呢? MySQL的EXPLAIN当然和ORA ...

  9. EXPLAIN执行计划中要重点关注哪些要素

    MySQL的EXPLAIN当然和ORACLE的没法比,不过我们从它输出的结果中,也可以得到很多有用的信息. 总的来说,我们只需要关注结果中的几列: 列名 备注 type 本次查询表联接类型,从这里可以 ...

随机推荐

  1. Access operations

    Access operations Accessing elements inside tensors Suppose we have the following tensors: > t = ...

  2. java基础类型数据与String类包装类之间的转换与理解

    数据类型转换一般分为三种: 在java中整型,实型,字符型视为简单数据类型,这些数据类型由低到高分别为:(byte,short,char--int-long-float-double) 简单数据类型之 ...

  3. BZOJ2006 超级钢琴

    Description ​ 给定一个长度为n的区间,询问前k大的区间和,区间长度\(\in [L, R]\). $ n, k <= 500000$ Solution ​ 首先求前缀和.把一个区间 ...

  4. OSW

    OSWatcher 工具 下载文档 :Metalink Doc ID 301137.1 Oswatcher 主要用于监控主机资源,如CPU,内存,网络以及私有网络等.其中私有网络需要单独配置. 需要说 ...

  5. 移动端rem单位用法

    1.rem(font size of the root element)是指相对于根元素的字体大小的单位,em(font size of the element)是指相对于父元素的字体大小的单位.它们 ...

  6. ASP.NET MVC+Bootstrap个人博客之修复UEditor编辑时Bug(四)

    我的个人博客站在使用百度富文本编辑器UEditor修改文章时,遇到了一些问题,(不知是bug,还是我没有配置好).但总算找到了解决方法,在此记录下来. 遇到的问题: 正常来讲,进入文章修改页,只需将U ...

  7. net start iisadmin报错:系统找不到指定的文件

    IIS Admin Service不能启动 ,直接启动或命令(net start iisadmin)都不成功.导致IIS站点访问异常. 最终参考网上解决方案: 这是大多是由于windows\syste ...

  8. 组合模式和php实现

    组合模式(有时候又叫做部分-整体模式): 将对象组合成树形结构以表示“部分整体”的层次结构.组合模式使得用户对单个对象和组合对象的使用具有一致性.它使我们树型结构的问题中,模糊了简单元素和复杂元素的概 ...

  9. LN : leetcode 123 Best Time to Buy and Sell Stock III

    lc 123 Best Time to Buy and Sell Stock III 123 Best Time to Buy and Sell Stock III Say you have an a ...

  10. sh/bash/csh/Tcsh/ksh/pdksh等shell本质区别

    sh/bash/csh/Tcsh/ksh/pdksh等shell本质区别 1. Shell脚本的书写 在写Shell脚本时,往往第一行要注明用什么解释器来解释这个脚本. 如#!/bin/bash即用/ ...