問題タブ [optimizer-hints]

データのいくつかのxmlaggsを使用して、いくつかのテーブル/ビューなどを呼び出す関数があります。

何らかの理由で、この追加情報がコードの残りの部分 (キー値のインデックス作成など) で使用されていない場合でも、追加情報を取り込むとパフォーマンスが向上します (再度使用されるキー値のインデックス作成など)。

私は高速および低速のもので tkprof を実行しましたが、いくつかの問題が見られます.

私の主な問題は、さらに下を見ると、ビューの 1 つのコストが高いことがわかります。高速なクエリは基になるテーブルで 3 つのインデックスを使用しているのに対し、低速なクエリは何も使用していません。

ヒントを挿入しようとしました：

ただし、まだ完全なテーブル スキャンを実行しています。オプティマイザーのヒントを間違った場所に配置したり、間違った構文を使用したりしていませんか?

編集-さらに調査を行っていますが、ネストされたループではなくハッシュ結合を行うOracleからのノックオンのようですが、選択は複数のテーブルからのものです-3つすべてでUSE_NLを強制できますか? pl/sql が何度も呼び出されているため、これを引き起こしている領域を知るにはどうすればよいですか。

更新 28/08 - 報奨金が追加されました。追加で必要なものがあれば教えてください。

更新 01/09 -

コメントアウトされた2つの選択があり、どちらかがコメント解除されると、より高速に実行されるクエリになります。t1 と t2 は、クエリの他の場所ではまったく使用されていません。

Update 01/09 実行計画は次のとおりです: 速いhttp://pastebin.com/pbJMSxrB 遅いhttp://pastebin.com/zt3eUYNd

私が修正したいのは86行目からの高コストのものです。これは、ここでのフル スキャンの結果であるか、さらに上の結合の結果である可能性があります。

Oracle データベース 11g Express Edition に、2 つの JOIN SELECT で 2 つの特定のメソッドを使用して JOIN を作成させようとしていますが、USE_MERGE および USE_NL ヒントを使用して実行しようとすると機能しません。私のSELECTは次のようになります。

しかし、私が得ている実際の説明計画は次のとおりです。

私がオラクルから得ている計画を説明してください

私はこれに本当に必死で、すばらしいオラクルのドキュメントを見てきましたが、まだ達成できません。非常によく似たこの例がありますが、私が試している組み合わせでなぜ機能しないのかわかりません。次のコードは、Oracle から提供された例です。

あなたの助けを前もってありがとう:D

私はオラクル11gを使用しています。データベース リンクを使用して、ローカル テーブルをリモート テーブルと結合するクエリがあります。主にリモートテーブルを使用していくつかの行を取得するようにフィルタリングするため、駆動テーブルをリモートテーブルにしたいと考えています。次に、それらをローカルテーブルに結合したいと思います。

問題は、オプティマイザが ORDERED ヒントと INDEX ヒントを無視し、ローカル テーブルのフル テーブル スキャンを実行することです。適切なインデックスを使用しており、統計を生成しています。正しいインデックスを使用する各テーブルでクエリを個別に実行しますが、結合では、ローカル テーブルが常にフル テーブル スキャンを実行し、駆動テーブルとして機能します。

パフォーマンスの問題がある SQL ステートメントがあります。

次のインデックスと、インデックスを使用するための SQL ヒントを追加すると、パフォーマンスが 10 倍向上しますが、その理由はわかりません。BUS_ID は主キー (T1.REF はキーの他の部分) の一部であり、T1 テーブルのクラスター化インデックスです。

T1 テーブルには約 100,000 行あります。BUS_ID には 6 つの異なる値しかありません。同様に、T1.STATUS 列には限られた数の可能性しかありませんが、これらの大部分 (99%) は同じ値になります。

ヒントなしでクエリを実行すると (/*+ INDEX ( T1 T1_IDX1) NO_UNNEST */) 5 秒かかり、ヒントを使用すると 0.5 秒かかります。T1.STATUS がサブクエリの「where」句または「join」句のいずれにも使用されていないため、インデックスがサブクエリにどのように役立つかわかりません。

私は何が欠けていますか？

Explain Plan と index を含めるように編集されました。

インデックスヒントあり

テーブル インデックス

約 50 列のテーブルに約 800 万のレコードがあり、いくつかのレコードを非常に迅速に表示する必要があるため、この目的のために FIRST_ROWS(10) ヒントを使用し、驚くほど高速に動作します。

ただし、ORDER BY の節、たとえば creationtime (そのテーブルの各行のほぼ一意の値) を配置すると、このクエリはすべての列を返すのに時間がかかります。

私が気づいたことの1つは次のとおりです。複数の行に同じ値を持つ VERSION のような列に ORDER BY を配置すると、より良い結果が得られます。

これは、このテーブルORDER BYの列のような一意の列では効率的に機能していません。ID

考慮に値するもう1つのことは次のとおりです。フェッチする列の数を減らすと、たとえば 50 列ではなく 3 列にすると、結果はどういうわけか速くなります。

PS 収集統計はこのテーブルで毎週実行されますが、データは 1 時間ごとにプッシュされます。INSERTこのテーブルではステートメントのみが実行されており、このテーブルではクエリは実行されていDELETEません。UPDATE

また、このテーブルなしで作成された単純なビューがあり、上記のクエリは同じビューで実行されています。

私はオラクルでヒントオプティマイザーを使用するという概念に不慣れで、ヒントFULLを適切に使用しているかどうかを理解したいと思います

質問があります

では、結果が 12345 になったとしましょう

ヒント FULL を使用したい場合、それは以下に書かれているはずですか？

結果も 12345 ですよね？

ありがとうございました