ときどき、オラクルはMERGE JOIN CARTESIAN通常の よりも操作を好むようMERGE JOINです。データを把握し、具体的な実行計画を見ると、結合されたエンティティの 1 つが手元のクエリで正確に 1 つのレコードのみを返すことができるため、通常、この操作は問題にならないことがわかります。
ただし、歴史的な理由から、DBA はデカルト積を一般的に嫌っています。
したがって、私はこれらのケースをよりよく分析し、私の議論で文書化してバックアップしたいと考えています. MERGE JOIN CARTESIANOracle が(または同様の) 操作を好むケースを理解できる、クエリ変換と CBO に関する公式の Oracle ドキュメントはありますか?
この場合、Oracle 11g (11.2.0.2.0) を使用しています。
更新：
これらは同様の質問ですが、オラクルが通常よりも好む理由や時期を説明していません。MJCMERGE JOIN
はい、通常、デカルト結合について言及すると、DBA の心臓がドキドキします。結合条件の欠落によって引き起こされるデカルト結合は、対処するのが非常に面倒です。これらは、一時スペースを「爆発」させ、あらゆる種類のアラームを鳴らす可能性のあるタイプの結合です。
この特定の結合方法に関する Oracle の公式 11g ドキュメントには何も見つかりませんでしたが、サポート DB には問題に関する記事がたくさんありました。過去数週間でこれらのいくつかを追跡しましたが、ここに私が見つけたものがあります.
MJC のソースは CBO 最適化です。MJC は、結合される結果セットのカーディナリティが低い場合に最適に機能する最適化です。この問題は、オプティマイザーが、結合への入力である 1 つ以上の結果セットのカーディナリティを正しく推定していない場合に発生します。推定行数 = 1 (または低い数値) であるが、結果セットの実際の行数が大きい場合、オプティマイザーは依然として MJC を選択する可能性があり、その結果、計画は最適ではありません。そして、それは控えめな表現です。これが発生し、クエリが何日も実行されて終了しないという問題がありました。CBO を軌道に乗せた後、数時間または数日ではなく、数秒で実行できるようになりました。
この推定行数と実際の行数が一致しているかどうかを確認する最善の方法は、クエリを実行し、その実行計画の統計を表示することです。あなたは11gを使用していると述べました-SQL監視機能を使用してください。この機能の出力には、実行計画の各ステップに費やされた時間が表示されます。また、推定行数と実際の行数も表示されます。MJC の入力で、推定行数と実際の行数の大きな相違を探しています。
SQL 監視は、OEM/DB Control から利用できます。または、API を使用することもできます (DBMS_SQLTUNE.REPORT_SQL_MONITOR を検索してください)。クエリで GATHER_PLAN_STATISTICS ヒントを使用し、DBMS_XPLAN でレポートを生成することで、同じ種類の情報を収集できます。詳細はここにあります。
それで、それを取り除く方法は？オブジェクト統計の問題を解決してみてください。CBO は、結合への入力として「1」ではなく数百、数千、または数百万のレコードを実際に処理していることを認識したら、MJC を選択せずに、データ セットにより適した結合方法を選択する必要があります。言うは易く行うは難しですが、このトピックに関する本が書かれていますが、少なくとも基本を確認してください。クエリに関係するすべてのテーブルに少なくとも統計があることを確認してください。where句に複数列の式が適用されている場合は、補足統計も活用できる場合があります。
大きなハンマーが必要な場合は、MJC の使用を許可/禁止する隠しパラメーターがいくつかあります。これらは、データベース レベル、セッション レベル、またはクエリ レベル (ヒントを使用) で実装できます。オラクルの公式のスタンスは、サポートの指示の下でのみ使用する必要があるため、読者の演習としてパラメータ名を省略します。彼らに教えてはいけませんが、オブジェクト統計を取得しようとして失敗した後、 OPT_PARAM ヒントを使用してクエリレベルで MJC を排除することに成功しました。