3

2 つのクエリがあり、そのうちの 1 つはクエリにパーティション分割されたテーブルを含み、もう 1 つのクエリはパーティション分割されていない同等のテーブルを含むことを除いて同じです。元の (パーティション化されていないテーブル) クエリは、パーティション化された対応するクエリよりもパフォーマンスが優れています。この問題を特定する方法がわかりません。実行プランを見ると、使用されているインデックスが 2 つのクエリで同じであり、新しいクエリの実行プランに PARTITION RANGE 句が表示されていることがわかります。これは、パーティションのプルーニングが行われていることを意味します。クエリは次の形式です:-

Select rownum, <some columns> 
from partTabA 
inner join tabB on condition1
inner join tabC on condition2
where partTabA.column1=<value> and <other conditions>
and partTabA.column2 in (select columns from tabD where conditions)

ここで、partTabA はパーティション分割されたテーブルで、partTabA.column1 はパーティション分割キー (レンジ パーティション) です。元のクエリでは、これは同じテーブルのパーティション化されていない同等のものに置き換えられます。新しいクエリのパフォーマンスが悪い理由を調べるには、どのパラメーターを調べる必要がありますか。私が持っているツールは Oracle SQL Developer です。

4

2 に答える 2

2

PARTITION RANGE ITERATORパーティションのプルーニングが行われているとは限りません。どのパーティションが使用されているかを確認するために、Explain PlanのPstartとも確認する必要があります。Pstop

同じデータを読み取っていても、パーティション分割されたクエリが遅くなるいくつかの潜在的な理由があります。(パーティション分割されたクエリが適切にプルーニングされておらず、テーブル全体から読み取っていると仮定します。)

  1. 複数のローカル インデックスからの読み取りは、単一のより大きなインデックスからの読み取りよりもはるかに効率が悪い場合があります。
  2. 大きな初期セグメント サイズ、多数のパーティションなどから多くの無駄なスペースがある可能性があります。セグメント サイズをこれと比較してください。select * from dba_segments where segment_name in ('PARTTABA', 'TABA'); それが問題である場合は、テーブルスペースの設定を調べるか、遅延セグメント作成を使用することをお勧めします。
于 2012-10-03T18:10:47.220 に答える
1

パーティション化されたテーブルがある場合、オラクルは最初にスキャンするパーティションを見つける必要があります。

両方の実行計画をここに貼り付けていただけますか? テーブルの大きさは？ここで使用されるインデックスはどの程度選択的ですか?

統計を収集しようとしましたか?

また、トレース ファイルを調べて、何が起こっているかを確認することもできます。

于 2012-10-03T18:04:59.657 に答える