一時表領域の見積

質問

納品したWebシステムの性能試験で、SELECT実行時に一時表領域の容量不足というSQLエラーが発生しました。
7.1GBにリサイズしても状況は変わらなかったそうです。
一時表領域は自動拡張なしです。
ユーザからSQLの修正を求められたので、修正して自社環境ではありますが、Webシステムの各機能ごとに一時表領域の拡張を監視して、最終的な最大値を調査しました。
そこで、400MBという結果が出たのですが、Webシステムを複数ユーザで並列に使用することを考慮すると、これが妥当なのかどうかが分かりません。
一時表領域容量の見積は可能なのでしょうか？
見積もれない場合は、ユーザに何と回答したら良いでしょうか？

回答No.2

MZ-80B · ベストアンサー

#1 です
一時表領域を使用する全てのアクセスパスはわかりません
おそらく大量に存在するでしょう。
その仕組み上からインラインビューや分析関数、マージジョインなどが大量消費する代表です。

EXPLAIN PLAN を使って調べればわかります。

回答No.1

MZ-80B

最大400MBというのは１セッションによる調査結果ということですね。
性能評価と同じデータで評価している前提で、かつ、
400MBの一時領域を使用するSQLが同時に呼び出されるのであれば
400MB×平均同時セッション数×データの増加係数
は必要でした・・とユーザに謝ります。
（同時セッション数＝並列に使用するユーザ数）
いつまで拡張なしに稼動できるかはユーザと相談してください。

事前に平均レコード長、総レコード数、増加レコード数
などの容量見積もり作業はしていましたか？
大容量になる場合、いきなり xxx GB必要です。
と数値だけ言われても相手は納得してくれないでしょう。

あと
もし一時表領域の縮小の問題が解決できているのなら
親切にフォローもついていますので放置しておくのはどうかと思います

お礼

回答ありがとうございます。
やはりセッション数に比例するんですね。
予想通りでした。

ユーザが想定する最大同時セッション数は1000だそうで、それだと400GBも必要になります。
ただ、400MBという結果報告に対して、「もう少しSQLを修正して」とか「ではxxxGBにしておきます」のような回答はまだ来ていません。
SQLはもう修正の余地があまり残されていません。
サブクエリを削除してSQLを単純化し、その代わりにSQLの発行回数を増やして、画面で必要なデータを形成するといった方法しかありませんが、それだとシステム全体のパフォーマンスを考慮しなくてはならなくなって、話が大きくなります。

ちなみに、一時表領域が使用される仕組みはご存知でしょうか？
私の場合、メモリソートができないときに使用するとか、サブクエリの結果を展開しておくために使用するくらいしか知りません。
使用量はサブクエリの結果のレコード件数に比例しますか？