RAC系统，sql I/O有问题，执行计划需要修改

黑豆

1. 在v$sql_plan视图的CPU_COST上显示1432975482
2. 看这个sql语句的执行计划如下：
SQL> r
  1  select t.*
  2    from payment t, casualty_policy t2
  3   where t.insurance_confirm_code is null
  4     and t.insurance_no = t2.insurance_no
  5     and t.create_date > to_date('2012-10-01', 'yyyy-MM-dd')
  6     and t.direction = '-1'
  7     and t.scan_status != '1'
  8   order by t.id desc
  9*

155 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 356225284

---------------------------------------------------------------------------------------------
| Id  | Operation           | Name                  | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |                       |   938 |   146K|  9915   (1)| 00:01:59 |
|   1 |  SORT ORDER BY      |                       |   938 |   146K|  9915   (1)| 00:01:59 |
|   2 |   NESTED LOOPS      |                       |   938 |   146K|  9914   (1)| 00:01:59 |
|*  3 |    TABLE ACCESS FULL| PAYMENT               |   966 |   133K|  7981   (2)| 00:01:36 |
|*  4 |    INDEX RANGE SCAN | CASUALTY_POLICY_INDX3 |     1 |    19 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("T"."INSURANCE_CONFIRM_CODE" IS NULL AND "T"."CREATE_DATE">TO_DATE('
              2012-10-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "T"."DIRECTION"=(-1) AND
              "T"."SCAN_STATUS"<>'1')
   4 - access("T"."INSURANCE_NO"="T2"."INSURANCE_NO")


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      35981  consistent gets
          0  physical reads
          0  redo size
      12351  bytes sent via SQL*Net to client
        602  bytes received via SQL*Net from client
         12  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
        155  rows processed

当前读+一致性读=35981，除于155 大约等于232，这在rac系统上算很耗时了吧

黑豆

索引中的数据

黑豆

dba_indexes

Maclean Liu(刘相兵

只是一点逻辑读 而已 ， 应当是 体现在TABLE ACCESS FULL| PAYMENT

逻辑读不是物理读

如果你要研究SQL 优化 ，给出如下信息：

请使用 sql health check 脚本 分析该SQL 然后上传HTML
http://www.oracledatabase12g.com ... h-check-script.html

黑豆

刘老师，您好。有一份db time在一个小时内达到2000分钟的AWR报告，附件上传，并有根据您提供的脚本跑了其中一个耗时的sql。请您根据AWR报告帮忙分析一下查找问题的思路

目前我的思路是这样的，如有理解不对的请指出：
1. 由于top 5事件中前两个是latch: library cache和latch: shared pool两个latch的等待事件，那么系统的sql应该存在大量的硬解析和软解析，或者sql没有绑定变量，或者sql的绑定变量不合适导致没起作用。
2. 再查看Soft Parse 达到97.90%，每秒的Hard parses只有0.25，这样来看似乎并不会对系统引起latch争用的问题。
3. 继续看Execute to Parse %，在一百次的解析中不用重新解析的次数是60.42，有点高
4. 再查看Time Model Statistics中耗时最高的为sql execute elapsed time，达到61,770.33s，为db time的53.9%，那么就可以肯定了确实是sql引起的系统负载过高。
5. 然后查看SQL ordered by Elapsed Time块中的第二行，Elap per Exec (s) 每次执行耗时669.16s的sql text，但是目前这个sql的版本很多，附件为其中一个版本的sql通过脚本运行后的性能分析html结果。
6. 如果在系统前台页面上的数据检索，使用者都会或多或少的筛选几个选项来选择出自己想要的最小的数据范围，对于这种的要求肯定避免不了在后台通过拼接sql来达到要求，所以导致sql版本比较多。