SQL高可用メモリ

Question

Oracle BBDDに問題があります。 BBDDがORA-04031エラーを出し始めるまで、問合せは多くのSGAを消費し、リセットする必要があります。

AWRでは、「SQLが共有可能なメモリによって順序付けられた」というクエリを見ることができます。クエリは、このセクションに多くの時間を表示され、それぞれに異なる "またはの" ずつ、例：

クエリ1：

...My Query... WHERE (inc.ID =:"SYS_B_131" 
    OR inc.ID     =:"SYS_B_132" 
    OR inc.ID     =:"SYS_B_133" 
    OR inc.ID     =:"SYS_B_134") 

クエリ2：

...My Query... WHERE (inc.ID =:"SYS_B_131" 
    OR inc.ID     =:"SYS_B_132" 
    OR inc.ID     =:"SYS_B_133" 
    OR inc.ID     =:"SYS_B_134" 
    OR inc.ID     =:"SYS_B_135" 
    OR inc.ID     =:"SYS_B_136" 
    OR inc.ID     =:"SYS_B_137" 
    OR inc.ID     =:"SYS_B_138") 

等など

私の質問は、「4つのクエリ」または「アイテムには3MBのメモリ消費量があり、500のクエリまたは「アイテムには1GBのメモリ消費量があります。これは正常ですか？

Answer 1

問題が見つかりました。 Oracle Bugです。 Oracle BBDDの私のバージョンでは、クエリに多くのバインド変数がある場合、クエリ実行プランは多くのSGAを消費します（クエリのみに対して1.2Gbまで）。

私はサブクエリーによって値の "IN"リストを置き換えるクエリを書き直して、問題を解決しました。

Answer 2

私はそれをバグと呼んでいません。貴重なSGAメモリーの大部分を1つの問合せに入れないようにすることは、オラクル社が設定した賢明な制限です。 500の "IN"リスト述語を適用することは、単に練習（バインドの有無にかかわらず）ではありません。さらに、サブクエリだけで500の "IN"リスト述語をプッシュするだけでは、ここでは役に立ちません。 は、私たちは小さなテーブル内のすべてのこれらの500の奇数のIDを格納し、FKをインデックス化し、サブクエリのようにEXISTS適用されるべきである - あなたが変更され、クエリ/サブクエリを共有しているしていないが、それはあなたが行っている必要があります何

SELECT <col list> FROM MainTable inc 
WHERE EXISTS (SELECT 1 FROM 500_IDTable inc2 inc.ID = inc2.ID); 

、私は推測します。

@ ibre5041 - 上記のクエリはすでにbind varを使用しています。実際、バインド変数が多すぎます。

Ildelian - CURSOR_SHARING = FORCEは絶対に使用しないでください。代わりに 'EXACT'を使用する必要があります。デフォルトはCURSOR_SHARING = EXACTです。 https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:4608916500346512056

CURSOR_SHARING =力の使用は、そのライブラリ・キャッシュに（すなわち、非リエントラントSQL）リテラルに悩まさデータベースの利点を示している理由

を参照してください。

あなたの場合、CURSOR_SHARING = FORCEは、バインド変数をすでに使用しているように見えるので意味がありません。

CURSOR_SHARING = EXACTも変更することを検討してください。