Question

Oracle Version: 11.1.0.7.0

我们在一个Oracle RAC实例中有更高的IO等待

一个SQL通过执行具有较长的执行时间 - 每次执行1452.57秒。这种情况有一天突然发生。以前，查询20k（：v4参数）记录需要最多3-4分钟

subscribeinfo记录：5900万（非平行）

充电记录：2k - 3k

SQL低于

选择o.msisdn，o.spid，o.serviceid，o.ChargeReferenceID， o.channelID，o.nextchargetime，o.failtimestamp，o.lastmonfeeday， o.networkId，o.retryEndDateTime，o.trialType，o.subFlag，o.faultCode 来自subscribeinfo o，chargerate r where（o.monthbillid =：v1）和（（（o.state =：“SYS_B_00”）和（o.nextchargetime＆lt;：v2）和（（o.IsAutoExtend＆lt;＆gt;：“SYS_B_01”）或（（o.IsAutoExtend =：“SYS_B_02”）和（o.extendflag＆lt;＆gt;：“SYS_B_03”））））或（o.subFlag =：“SYS_B_04”和 o.state =：“SYS_B_05”和o.retryenddatetime＆gt; ：v2））和（o.ChargeClassForSub = r.chargeclassidx）和（（r.chargemode = ：“SYS_B_06”和r.activetype =：“SYS_B_07”和o.nextchargetime！= ：“SYS_B_08”）或（r.chargemode =：“SYS_B_09”和r.activetype＆lt;＆gt; ：“SYS_B_10”）或（r.chargemode＆gt; =：“SYS_B_11”和r.chargemode＆lt; = ：“SYS_B_12”和r.basecharge＆gt; =：“SYS_B_13”）或（r.chargemode = ：“SYS_B_14”）或（r.chargemode =：“SYS_B_15”）或（r.chargemode = ：“SYS_B_16”））和（o.failtimestamp＆lt; =：v3）和（rownum＆lt; =：v4）

根据AWR报告前5个定时前景活动

直接路径读取[平均等待时间：22秒，％DB时间：50.75％] DB文件顺序读取[平均等待时间：15秒，％DB时间：38.00]

我无法发布完整的AWR报告，因为它受到限制。所以请询问我发布的详细信息

请查看以下解释计划：

ID Exec Ord Operation Go to More Peek Bind Capt绑定Cost2 Estim   卡最后开始最后输出行上/下   Estimate1 PStart PStop工作区0 7选择语句
    23335 1 2577 1 6 COUNT STOPKEY [+] [+]
  [+] 23335 1 2577 2 5。 HASH JOIN [+] [+]
  [+] 23335 20001 1 2577 8x超过[+] 3 1 ..表格访问已满   CHARGERATE [+] [+] 68 3035 1 3036 1x 4 4 ..分区列表   单个[+] 23266 25223 1 2577 10x超过KEY KEY 5 3 ...表   本地索引访问权限订阅[+] [+] [+]
  [+] 23266 25223 1 2577 10x超过KEY KEY 6 2 .... INDEX RANGE SCAN   IDX_FAILTIMESTAMP_NEW [+] [+] [+] [+] 2435 1 2100765 KEY KEY

IOSTAT

Linux 2.6.16.46-0.12-smp（mdspdb01）11/16/12

avg-cpu：％user％nice％system％iowait％steal％idle
       8.41    0.00    9.38   13.25    0.00   67.67
设备：tps Blk_read / s Blk_wrtn / s Blk_read Blk_wrtn

sda 5.71 39.53 121.79 665679995 2051190222

sdb 85.75 178.15 171.12 3000316741 2881953582

sdc 111.05 161.69 43.96 2723201251 740429949

我们为字段monthbillid，nextchargetime和failtimestamp创建了一个索引...尽管它的基数提高了1/6，但它的成本增加了4-5倍。但是oracle默认采用新索引

在subscribeinfo上创建索引IDX_MONTHBILLQUERY（monthbillid，   nextchargetime，failtimestamp）本地表空间IMUSE_INDEX;

dbms_stats.gather_index_stats（'IMUSE01'，'IDX_MONTHBILLQUERY'）;

我们在AWR报告中有硬解析= 0。我们还改变了cursor_sharing = FORCE

现在IO已得到控制。还是觉得，这不是根本原因。而且，我们使实例专用于此查询，每小时发生10次以上，检索20k记录大约需要100秒。

如果我将优化器模式作为first_rows或使用提示first_rows（20000），是否有人可以建议这是一个好的决定。

截至目前，我们已经破坏了统计工作，我们是否可以仅为某些表或某些索引启用相同的功能。这可能吗？

Answer 1

问题是该语句导致超过50000次磁盘读取。这可能是由使用cursor_sharing引起的。如果在不使用绑定变量的情况下对应用程序进行编码，则通常使用此参数（非常糟糕。请勿走，运行以修复该应用程序）。可能你甚至将cursor_sharing设置为强制，这可能会产生不良影响，如上所述，光标偷看在大多数情况下也不起作用。

您可以通过指定提示来避免全表扫描，具体取决于您是否在所需表上有索引。由于您没有描述，因此无法向您提供任何具体建议。

Answer 2

问题解决了......使用cursor_sharing强制...这大大减少了IO。现在IO在所有情况下都是正常的。然后我们为sqltuning顾问推荐的同一查询创建了两个索引并接受了配置文件

2- SQL配置文件查找（请参阅下面的解释计划部分）   -------------------------------------------------- ------这个陈述找到了一个可能更好的执行计划。

推荐（估计收益：80.44％）
考虑接受推荐的SQL配置文件。   执行dbms_sqltune.accept_sql_profile（task_name =＆gt;'my_sqltune_task1'，           task_owner =＆gt; 'IMUSE01'，replace =＆gt; TRUE）;

验证结果------------------ SQL配置文件已经过测试   通过执行其计划和原始计划并测量他们的计划   各自的执行统计。计划可能只是部分计划   如果另一个可以在更短的时间内完成，则执行。
                   Original Plan  With SQL Profile  % Improved
                   -------------  ----------------  ----------   Completion Status:             PARTIAL          COMPLETE   Elapsed
时间（毫秒）：31479 8049 74.43％CPU   时间（毫秒）：5172 1656 67.98％
  用户I / O时间（毫秒）：16367 3422 79.09％
  缓冲区获取：265365 51818 80.47％
  磁盘读取：3227 524 83.76％
  直接写入：0 0行   已处理：0 20000 Fetches：
  0 20000执行：0
  1
3-指数查找（参见下面的解释计划部分）   --------------------------------------------------可以通过创建一个或多个
来改进该陈述的执行计划   指数。

推荐（估计收益：81.1％）



考虑运行Access Advisor以改进物理架构设计   或创建推荐的索引。   创建索引IMUSE01.IDX $$ _ 67E5B0001   IMUSE01.SUBSCRIBEINFO（ “状态”， “SUBFLAG”， “MONTHBILLID”， “RETRYENDDATETIME”）;



考虑运行Access Advisor以改进物理架构设计   或创建推荐的索引。   创建索引IMUSE01.IDX $$ _ 67E5B0002   IMUSE01.SUBSCRIBEINFO（ “状态”， “MONTHBILLID”， “FAILTIMESTAMP”）;

理由---------   创建推荐的指数可以显着改善执行计划   这句话。但是，最好运行“Access Advisor”   使用代表性SQL工作负载而不是单个语句。这个   将允许获得全面的索引建议   帐户索引维护费用和额外的空间消耗。



4-重组SQL查找（参见解释计划部分中的计划1）   -------------------------------------------------- --------------谓词“O”。“NEXTCHARGETIME”＆lt;＆gt;：执行第5行的B1   plan是索引列“NEXTCHARGETIME”的不等式条件。   这种不等式条件会阻止优化器的有效性   使用表“IMUSE01”上的索引。“SUBSCRIBEINFO”。

推荐--------------      - 将谓词重写为等效形式以利用       指数。

理由---------       如果谓词是不等式，则优化器无法使用索引       条件或是否存在表达式或隐式数据类型转换       在索引列上。

Oracle 11g高IO等待

2 个答案:

推荐（估计收益：80.44％）

推荐（估计收益：81.1％）