0

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 其中 (o.monthbillid = :v1) and (((o.state = :"SYS_B_00") and (o.nextchargetime < :v2) and ((o.IsAutoExtend <> :"SYS_B_01 ") 或 ((o.IsAutoExtend = :"SYS_B_02") 和 (o.extendflag <> :"SYS_B_03")))) 或 (o.subFlag = :"SYS_B_04" 和 o.state = :"SYS_B_05" 和 o .retryenddatetime > :v2)) 和 (o.ChargeClassForSub = r.chargeclassidx) 和 ((r.chargemode = :"SYS_B_06" and r.activetype = :"SYS_B_07" and o.nextchargetime != :"SYS_B_08" ) 或 ( r.chargemode = :"SYS_B_09" 和 r.activetype <> :"SYS_B_10") or (r.chargemode >= :"SYS_B_11" and r.chargemode <= :"SYS_B_12" and r.basecharge >= :"SYS_B_13") or (r.chargemode = :"SYS_B_14") or (r .chargemode = :"SYS_B_15") 或 (r.chargemode = :"SYS_B_16") 和 (o.failtimestamp <= :v3) 和 (rownum <= :v4)

根据 AWR 报告 Top 5 Timed Foreground Events

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

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

请在下面找到解释计划：

ID Exec Ord Operation Go To More Peek Bind Capt Bind Cost2 Estim Card LAST Starts LAST Output Rows LAST Over/Under Estimate1 PStart PStop 工作区 0 7 SELECT STATEMENT
23335 1 2577 1 6 COUNT STOPKEY [+] [+]
[+] 23335 1 2577 2 5 HASH JOIN [+] [+]
[+] 23335 20001 1 2577 8x over [+] 3 1 .. TABLE ACCESS FULL CHARGERATE [+] [+] 68 3035 1 3036 1x 4 4 .. 分区列表单 [+] 23266 25223 1 2577 10x over KEY KEY 5 3 ... 按本地索引 ROWID SUBSCRIBEINFO 访问表 [+] [+] [+]
[+] 23266 25223 1 2577 10x over 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

平均 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

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

在 subscribeinfo(monthbillid, nextchargetime, failtimestamp) 本地表空间 IMUSE_INDEX 上创建索引 IDX_MONTHBILLQUERY；

dbms_stats.gather_index_stats('IMUSE01', 'IDX_MONTHBILLQUERY');

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

现在 IO 得到控制。还是觉得，这不是根本原因。此外，我们为这个查询设置了专用实例，该查询每小时发生超过 10 次，检索 20k 条记录大约需要 100 秒。

谁能建议我是否将优化器模式作为 first_rows 或使用提示 first_rows(20000) 是否是一个好的决定。

到目前为止，我们已经禁用了 stats 作业，我们可以只为某些表或某些索引启用相同的功能吗？这可能吗？

4

2 回答 2

0

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

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

于 2012-11-18T18:34:39.387 回答
0

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

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

推荐（估计收益：80.44%）

  • 考虑接受推荐的 SQL 配置文件。执行 dbms_sqltune.accept_sql_profile(task_name => 'my_sqltune_task1', task_owner => 'IMUSE01', replace => 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 获取：
    0 20000 执行：0
    1

3- 索引查找（请参阅下面的解释计划部分）---------------------------------------- ------------ 该语句的执行计划可以通过创建一个或多个
索引来改进。

推荐（估计收益：81.1%）

  • 考虑运行 Access Advisor 以改进物理模式设计或创建推荐的索引。在 IMUSE01.SUBSCRIBEINFO("STATE","SUBFLAG","MONTHBILLID","RETRYENDDATETIME") 上创建索引 IMUSE01.IDX$$_67E5B0001；

  • 考虑运行 Access Advisor 以改进物理模式设计或创建推荐的索引。在 IMUSE01.SUBSCRIBEINFO("STATE","MONTHBILLID","FAILTIMESTAMP") 上创建索引 IMUSE01.IDX$$_67E5B0002；

    基本原理 --------- 创建推荐索引显着改进了该语句的执行计划。但是，与使用单个语句相比，使用代表性 SQL 工作负载运行“Access Advisor”可能更可取。这将允许获得考虑到索引维护开销和额外空间消耗的综合索引建议。

4- 重组 SQL 查找（请参阅解释计划部分中的计划 1）------------------------------------ ---------------------------- 谓词 "O"."NEXTCHARGETIME"<>:B1 在执行计划的第 5 行使用是索引列“NEXTCHARGETIME”上的不等式条件。这种不等式条件会阻止优化器有效地使用表“IMUSE01”.“SUBSCRIBEINFO”上的索引。

建议 -------------- - 将谓词重写为等效形式以利用索引。

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

于 2012-12-02T03:36:04.213 回答