Oracle 11g高IO等待

Question

Oracle Version: 11.1.0.7.0

我們的一個Oracle RAC實例中有更高的IO等待

一個SQL的執行時間很長-每次執行1452.57s。 這一天突然開始發生。 以前，查詢20k（：v4參數）記錄最多需要3-4分鍾

subscriptioninfo記錄：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來自subscriptioninfo o的.faultCode，收費r，其中（o.monthbillid =：v1）和（（（o.state =：“ SYS_B_00”）和（o.nextchargetime <：v2）和（（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”和o.nextchargetime！=：“ SYS_B_08”）或（ r.chargemode =：“ SYS_B_09”和r.activetype <>：“ SYS_B_10”）或（r.chargemode> =：“ SYS_B_11”和r.chargemode <=：“ SYS_B_12”和r.basecharge> =：“ SYS_B_13” ）或（r.chargemode =：“ SYS_B_14”）或（r.chargemode =：“ SYS_B_15”）或（r.chargemode =：“ SYS_B_16”））和（o.failtimestamp <=：v3）和（rownum <= ：v4）

根據AWR報告，前5個定時前景事件

直接路徑讀取[平均等待時間：22 s，％DB時間：50.75％] DB文件順序讀取[平均等待時間：15 s，％DB時間：38.00]

由於受限，我將無法發布完整的AWR報告。 因此，請詢問我將發布的詳細信息

請在下面找到說明計划：

ID Exec Ord操作轉到更多窺視綁定Capt綁定Cost2估計卡LAST開始LAST輸出行LAST超出/低於估計1 PStart PStop工作區0 7選擇語句
23335 1 2577 1 6計數停止鍵[+] [+]
[+] 23335 1 2577 2 5。 哈希聯接[+] [+]
[+] 23335 20001 1 2577 8x over [+] 3 1 ..表訪問完全充電[+] [+] 68 3035 1 3036 1x 4 4 ..分區列表單[+] 23266 25223 1 2577 10x over KEY KEY 5 3 ...通過本地索引行預訂信息訪問表[+] [+] [+]
[+] 23266 25223 1 2577 10x KEY KEY 6 2 ....索引范圍掃描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

郵編111.05 161.69 43.96 2723201251 740429949

---

我們為monthbillid，nextchargetime和failtimestamp創建了一個索引...盡管它的基數提高了1/6，但成本卻提高了4-5倍。 但是oracle默認使用新索引

在subscriptioninfo（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工作，是否可以僅對某些表或某些索引啟用相同的功能。 這可能嗎？

Answer 1

問題是該語句導致了超過50000次磁盤讀取。 這可能是由於使用cursor_sharing引起的。 如果在不使用綁定變量的情況下對應用程序進行編碼，則通常使用此參數（非常糟糕。請不要走動，運行以修復該應用程序）。 可能甚至將cursor_sharing設置為force，這可能會產生不良影響，如所描述的那樣，並且在大多數情況下，偷看光標也不起作用。

您可以通過指定提示來避免全表掃描，以解決此問題，具體取決於您是否在所需表上具有索引。 如您所沒有描述的那樣，就不可能給您任何具體的建議。

Answer 2

解決的問題.....使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時間（ms）：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”。在執行計划的ID 5行使用的“ NEXTCHARGETIME” <>：B1是索引列“ NEXTCHARGETIME”上的不等式條件。 這種不相等條件會阻止優化器有效地使用表“ IMUSE01”。“ SUBSCRIBEINFO”上的索引。

建議---------------將謂詞重寫為等效形式以利用索引。

基本原理---------如果謂詞是不相等條件，或者在索引列上存在表達式或隱式數據類型轉換，則優化器將無法使用索引。