DB2 LUW：臨時表空間是否應該與其他表空間共享緩衝池？
我們正在調整我們公司剛剛編寫的大型應用程序。該調整的一部分包括調整數據庫。我們在 AIX 上執行 DB2 LUW。具體來說，我們使用的是 9.7 Fix Pack 4（儘管我們希望在今年的某個時候遷移到 10.1 Fix Pack 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）。如果您發現緩衝池命中率下降或臟頁爭用率高與臨時空間使用量一致（在POOL_TEMP_DATA_L_READS中出現峰值select * from table (mon_get_tablespace(NULL,NULL))），那麼為相關臨時表空間創建一個適當大小的單獨緩衝池可能會很有用。