次の oracle クエリでパフォーマンスの問題があります。
select tab_a.col1,tab_a.col2,tab_b.col1 etc etc from tab_a,tab_b
where
tab_a.AS_OF = TO_DATE ('10-MAY-2013','DD-MON-YYYY')
and val.PORTFOLIO_CODE IN ('91000906', '03352', '22503', '03335', '17369', '960', '04390', '02076', '52998', '02449', '02348', '17389', 'B5000', '17077', '46400',
'B6600', '53068', '52334A', '03363', '94654', 'SOFT2', 'B9000', '17137F', '03593', '04228', '04450', '17372', '52334')
AND tab_a.NEXT_AS_AT =TO_TIMESTAMP ('12/31/9999 12:00:00.000000 AM','MM/DD/YYYY HH:MI:SS.FF6 AM')
AND tab_a.POSITION_INTERVAL_TYPE = 'E'
AND tab_a.POSITION_TYPE = 'T'
and tab_a.row_type = 0
AND tab_b.NEXT_AS_AT(+) = TO_TIMESTAMP ('12/31/9999 12:00:00.000000 AM','MM/DD/YYYY HH:MI:SS.FF6 AM')
AND tab_b.AS_OF(+) <= TO_DATE ('10-MAY-2013','DD-MON-YYYY')
AND tab_b.NEXT_AS_OF(+) > TO_DATE ('10-MAY-2013','DD-MON-YYYY')
AND tab_b.ROW_TYPE(+) = 0
AND tab_a.SECURITY_CODE_PRIMARY = tab_b.SECURITY_CODE_PRIMARY(+)
AND tab_a.SECURITY_CODE_TYPE_PRIMARY = tab_b.SECURITY_CODE_TYPE_PRIMARY(+);
すべてのクエリの動作が異なることを認識しており、できるだけ有益な情報を提供できるように努めます。しかし、この時点で、テーブルの構造または where 句の構造に関する私のアプローチの指針と方向性を見ています。
Env: Oracle 11g 両方のテーブルで、dbms_stats を介して統計が更新されています (インデックス付き列のヒストグラム: method_opt : FOR ALL INDEXED COLUMNS SIZE AUTO)。Tab_a : AS_OF でパーティション分割され、PORTFOLIO_CODE でハッシュ分割 (128) された日次範囲 Tab_b : SECURITY_CODE_PRIMARY で分割されたハッシュ (128 パーティション)入力 as_of および tab_a に関連するその他のフィルター条件の場合: 約 6000
Tab_b には、ローカルに分割されたマルチカラム インデックスがあります - SECURITY_CODE_PRIMARY、SECURITY_CODE_TYPE_PRIMARY、NEXT_AS_AT、NEXT_AS_OF、AS_OF、ROW_TYPE tab_a.portfolio_codes の場合) したがって、インデックスを作成することによる付加価値は見られず、実際にはやり過ぎかもしれません。予想される出力レコード数: 6000
クエリの以下の強調表示された部分は、tab_b から 1 つの行のみが取得されるようにするためのものです (日中のさまざまな時間間隔で日中のデータを取得し、それを保存する必要があるため、レコードを識別するためのタグ付けメカニズムを実装しています)。ただし、SECURITY_CODE_PRIMARY および as_of のレコードの最新の時間間隔のみに関心があります。したがって、以下の部分では、ドライバ テーブル tab_a から入ってくる security_code_primary ごとに 1 つだけ最新のものを取得することが保証されます。この場合、約 5000 の個別の security_code_primary があります。
AND tab_b.NEXT_AS_AT(+) = TO_TIMESTAMP ('12/31/9999 12:00:00.000000 AM','MM/DD/YYYY HH:MI:SS.FF6 AM')
AND tab_b.AS_OF(+) <= TO_DATE ('10-MAY-2013','DD-MON-YYYY')
AND tab_b.NEXT_AS_OF(+) > TO_DATE ('10-MAY-2013','DD-MON-YYYY')
私の質問は次のとおりです。Tab_a は適切なパーティションとインデックス スキームのようです。範囲 (as_of と next_as_of) がある tab_b のような構造を持つテーブルと結合すると、ボトルネックが発生します。現在実施しているパーティション スキーム (およびインデックス) と、パフォーマンスの問題を引き起こす可能性のあるものについて、何らかの方向性を示したいと思います。
また、セカンダリ テーブルと結合されたドライバー テーブルの部分的なクエリのみを提供しました。通常、一部のクエリには、tab_b と同じように最大 8 ～ 10 個のテーブル (強調表示された tab_b のような where 句とまったく同じ) があり、tab_a で外部結合されたままになっています。
クエリには 10 秒未満の応答時間が必要ですが、今日は約 2 分以上かかります。他に何ができるかを確認しようとしています。