2

一部のサーバーでは、ハッシュ結合、group by および order by のコストが実際のコストに比べて低すぎるようです。つまり、多くの場合、インデックス レンジ スキャンを使用した実行計画は前者よりも優れていますが、実行計画ではコストが高くなります。

さらにいくつかの注意事項:

  1. 私はすでにoptimizer_index_cost_adjを20に設定していますが、それでも十分ではありません. 純粋な全テーブル スキャンのコストを増やしたくありません。実際、オプティマイザがコストを削減してもかまいません。
  2. pga_aggregate_targetが CBO コストの見積もりに影響を与えることに気付きましたが、十分な RAM があるため、このパラメーターを下げたくありません。
  3. 個々のクエリでオプティマイザ ヒントを使用するのではなく、設定をグローバルにしたいと考えています。

編集 1: 動的サンプリングを試してみることを考えていますが、これが全体的なパフォーマンスにどのように影響するか、つまり実行計画が変更される頻度を予測するのに十分な詳細な知識がありません。私は間違いなく非常に安定したものを好みます。実際、最大のクライアントの一部では、すべての統計をロックするポリシーがあります (これは Oracle 11g SQL Plan Management で変更されます)。

4

1 に答える 1

2

インデックス レンジ スキャンを使用した実行計画が、フル スキャン + ソートまたはハッシュ結合を使用した実行計画よりも優れていることがよくありますが、CBO はフル スキャンを選択しています。これは、オプティマイザーが、実際に実際に得られるよりも多くの一致する結果が見つかると信じているためです。

つまり、オプティマイザーが、テーブル A から 100 万行、テーブル B から 1000 行を取得すると判断した場合、フル スキャン + ソート マージまたはハッシュ ジョインを選択する可能性が非常に高くなります。ただし、実際にクエリを実行したときに、テーブル A から 1 行しか取得できない場合は、インデックス レンジ スキャンの方が優れている可能性があります。

まず、パフォーマンスの低いクエリをいくつか見て、述語の選択性を分析し、オプティマイザーが各テーブルの行数を適切に見積もっているかどうかを判断します。

編集:カーディナリティの推定値が正しくないと述べました。これが問題の根本原因です。ハッシュ結合とソートのコストは、おそらくまったく問題ありません。場合によっては、データがどの程度相関しているかがわからないため、オプティマイザーが間違った見積もりを使用している可能性があります。一部の列のヒストグラムが役立つ場合があります (まだ取得していない場合)。場合によっては、関数ベースのインデックスを作成し、非表示の列の統計を収集して、オプティマイザーにさらに優れたデータを提供できます。

結局のところ、満足のいくパフォーマンスを得るには、クエリでさまざまなテーブルのカーディナリティを指定するトリックが必要になる場合があります。

于 2009-07-14T09:18:15.423 に答える