DB2 LUW：一時表領域は他の表領域とバッファープールを共有する必要がありますか？
私たちは、会社が作成したばかりの大規模なアプリケーションを調整している最中です。その調整の一部には、データベースの調整が含まれます。 DB2LUWはAIXで実行します。具体的には、9.7フィックスパック4です（ただし、今年中に10.1フィックスパック2に移行する予定です）。
最初は、データのサイズによってのみ必要なテーブルスペースを構築しました（つまり、すべてのテーブルが4Kテーブルスペースに収まる場合、4Kテーブルスペースのみを作成しました。これは、テーブルスペースを作成して、未使用の場合にディスクを増やす理由であると考えました）。これは、一時表領域でも同じでした。
開発者は、32Kの一時表領域を追加することでパフォーマンスが向上したと語っています。したがって、それらのすべてのテーブルは4K、8K、または16Kのテーブルスペースになります。それでも、彼らは32Kの一時的なもの（独自のバッファープールを持っている）を追加し、アプリケーションのトランザクション時間の一部を半分にしたと主張しています。
考えてみると、それは理にかなっていると思います。オプティマイザーは、32Kスペースを結合/ソートを実行するのに最適な場所と見なしており、32K対4Kで自由に使えるメモリが多いと思います。
私の仲間の同僚は、（上記に関係なく）DBAが常に一時表領域を独自のバッファープールに配置する必要があることをどこかで読んだと述べました。私が彼にそれを読むためのリンクを頼んだとき、彼は思い出せなかった。
疑問に思っています...一時表領域は常に独自のバッファプールを取得する必要がありますか？これは参加/並べ替えのパフォーマンスに役立ちますか？それは良い習慣ですか？
そして第二に、それらの結合/ソートのために常に32Kのバッファープールと32Kの一時表領域を作成することは理にかなっていますか？
まず、テーブルスペースのページサイズと一致するバッファプールが必要です。そのトークンによって、一時テーブルスペースが32Kページサイズの唯一のテーブルスペースである場合、そのテーブルスペースには専用のバッファプールがあります。
ページサイズが32Kの他のテーブルスペースがある場合は、システムパフォーマンスを監視するだけで、個別の一時スペースバッファプールのメリットがあるかどうかがわかります。
_select * from sysibmadm.mon_bp_utilization_を使用してバッファープールのヒット率を確認し、select * from table (mon_get_bufferpool(NULL,NULL))を使用してページクリーナーアクティビティを確認できます（_POOL_NO_VICTIM_BUFFER_および_POOL_DRTY_PG_STEAL_CLNS_は理想的には0である必要があります）。バッファプールのヒット率の低下またはダーティページの高い競合が一時的なスペースの使用と一致する場合（select * from table (mon_get_tablespace(NULL,NULL))の_POOL_TEMP_DATA_L_READS_の急上昇）、適切なサイズの個別のバッファプールを作成します。問題の一時表領域が役立つ場合があります。