Oracle Version: 11.1.0.7.0
OracleRACインスタンスの1つでIO待機が高くなっています
1つの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 from subscribeinfo o、chargerate r where（o.monthbillid =：v1）and（（（o.state =： "SYS_B_00"）and（o.nextchargetime <：v2）and（（o.IsAutoExtend <>： "SYS_B_01 "）または（（o.IsAutoExtend =：" SYS_B_02 "）and（o.extendflag <>：" SYS_B_03 "））））または（o.subFlag =：" SYS_B_04 "and o.state =：" SYS_B_05 "and o .retryenddatetime>：v2））and（o.ChargeClassForSub = r.chargeclassidx）and（（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"）または（r.chargemode> =： "SYS_B_11" and r.chargemode <=： "SYS_B_12" and 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秒、％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 Work Area 0 7 SELECT STATEMENT
23335 1 2577 1 6 COUNT STOPKEY [+] [+]
[+] 23335 1 257725。ハッシュ結合[+][+]
[+] 23335 20001 125778xオーバー[+]31..テーブルアクセスフルチャージ[+][+]68 3035 1 3036 1x 44..パーティションリストシングル[+]23266.. 25223 1 2577 10x over KEY KEY 53...ローカルインデックスによるテーブルアクセスROWIDSUBSCRIBEINFO[+] [+] [+]
[+] 23266 25223 1 2577 10x over KEY KEY 62....インデックス範囲スキャンIDX_FAILTIMESTAMP_NEW[+][+] [+] [+] 243512100765キーキー
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（monthbillid、nextchargetime、failtimestamp）ローカルテーブルスペースIMUSE_INDEXにインデックスIDX_MONTHBILLQUERYを作成します。
dbms_stats.gather_index_stats（'IMUSE01'、'IDX_MONTHBILLQUERY'）;
AWRレポートにはハード解析=0があります。また、cursor_sharing=FORCEを変更しました
現在、IOは制御下にあります。まだ感じていますが、これは根本的な原因ではありません。また、インスタンスをこのクエリ専用にしました。これは1時間に10回以上発生し、2万件のレコードを取得するのに約100秒かかります。
オプティマイザーモードをfirst_rowsとして使用するか、ヒントfirst_rows（20000）を使用するかを選択するのが適切かどうか、誰かが提案できますか。
現在、統計ジョブを無効にしていますが、一部のテーブルまたは一部のインデックスに対してのみ同じことを有効にできますか？これは可能ですか？