いくつかのより複雑なクエリを実行し、コレクションを自由に使用するsprocがいくつかあります。
私のDBAは、メモリ内のTEMPテーブルスペースのS＃$％tonを消費することがあると不満を言っています。
クエリの最適化を実行できますが、できるだけ非侵襲的にしたいと考えています。これを行うには、変更がTEMPテーブルスペースに与える影響を確認する必要があります。
質問：
クエリがTEMPテーブルスペースにかかるコストを確認するにはどうすればよいですか？
考慮すべきことの1つは、DBAアクセスがないことです。
前もって感謝します。
クエリが一時的に持つコストの意味によって異なります。
v$tempseg_usage から選択できる場合は、temp で消費しているスペースの量を確認できます。DEV データベースでは、DBA がそのビューへのアクセスを許可しない理由はありません。
gpeche で述べたように - autotrace は、temp から実行している IO の数についての良いアイデアを提供します - そのため、スペース使用量と組み合わせると、何が起こっているかについての良いアイデアが得られます。
大規模なコレクションは、一般に悪い考えです。他のすべてのセッションで共有される PGA (TEMP とは大きく異なります) で多くのメモリを消費します。これは、DBA が懸念することです。どのくらい大きいかは、システムによって異なります。数千の小さなレコードはおそらくそれほど悪くはありませんが、コレクション内に数百の数千または数百万のレコードがあると心配になります。
あらゆる種類の興味深いクエリやトリックを実行する前に、フィルタリング後にソートする必要があるデータ量を見積もります。これがソート領域に収まるものよりも大きい場合、ソートはブロックをメモリから一時に移動し、後でそれらを読み取ります。生データのサイズに多少のオーバーヘッドを追加します。30% のオーバーヘッドを使用します。これにより、必要なソート サイズの合計を適切に見積もることができます。
コレクションにも同じ戦略を使用します。どこかにデータ用のスペースが必要です。データ量を小さくする魔法/圧縮はありません。最大1000行のメモリがあり、1000.000行で使用しようとすると、収まりません。その場合は、データベース管理者に相談して解決策を見つけてください。ワークロードを分割することになる可能性があります。
クエリの実行中にv$sql_workarea_activeをクエリするか、実行後にv$sql_workareaをクエリできます。
これらは、使用されたメモリ、使用されたディスクスペース、および（最も重要な）パス数（スペース使用量は問題の一部にすぎません-マルチパスソートは非常に高価です）の観点から一時テーブルスペースの使用量を示し、使用量を説明計画のステップ。
次に、メモリ管理を変更することで、使用される絶対スペースとパス数の両方の観点から、一時表領域の使用量を削減できるかどうかを検討できます。
DBA アクセス権がなければ、AUTOTRACEを試してみます。TEMP テーブルスペースの消費量はわかりませんが、クエリのチューニングに役立つ多くの情報を得ることができます (論理読み取り、ディスクへの並べ替えの数、再帰 SQL、再実行の消費、ネットワーク ラウンドトリップ)。AUTOTRACE を使用するにはいくつかの権限が必要ですが、完全な DBA 権限は必要ありません。