現在進行修改：向測試環境添加相同數目的邏輯分區之後，測試環境看上去將像原始的生產設置了，如下表所示。
生產設置:
數據庫分區（DBPARTITION
ALLNODES（在節點 1 到 64 上）
NODE1（節點 1 上所定義的 db 分區）
NODE2（節點 5 上所定義的 db 分區）
表空間（TABLESPACE）
TABSPACE1（DMS 使用數據庫分區 ALLNODES 中定義的設備）
TABSPACE2（DMS 使用數據庫分區 NODE1 中定義的 SMS）
TABSPACE3（DMS 使用數據庫分區 NODE2 中定義的 DMS）
表
TABSPACE1 中的 TAB1
TABSPACE2 中的 TAB2
TABSPACE3 中的 TAB3
MQT：
TAB3 上定義的 MQT
視圖：
定義的 VIEW1，包含兩個表 TAB1 和 TAB2
請確保在發出查詢的節點上使用 -f 和 -fd 收集 db2look，以確保從該節點和注冊表設置中獲取前面所討論的緩沖池信息，以及從運行查詢的節點獲取 db cfg 和 dbm cfg。以我的經驗，客戶的所有節點通常具有相同的配置，除了緩沖池這個極其重要的設置之外。
所遵循的步驟：
從生產中收集存儲器信息：
db2look -d <dbname> -l -o storage.out
修改表空間/緩沖池信息以適應這些環境。如果您沒有可用的設備，那麼就使用 DMS 文件容器。同樣，如果您不希望在測試中使用與生產中相同數目的容器，就縮短列表並使用較少容器。但是，您同樣必須確保如果生產中的表空間是 DMS 或 SMS 類型的，那麼在測試中要保留相同的類型。
使用下列命令收集配置信息：
db2look -d <dbname> -f -fd -o config.out
現在，僅僅為我們感興趣的對象收集 db2look 信息。本例中，我們需要所有相關信息，包括表 DLL、視圖以與表相關的 MQT：
db2look -d <dbname> -e -a -m -t TAB1
TAB2 TAB3 -o db2look.out
一旦收集了所有這些信息並修改了表空間/緩沖池信息，就在測試環境中執行 db2look 輸出文件，並且重新從生產和測試中獲取 db2exfmt 輸出並進行比較。
這是一個關於在表上進行活動時在哪裡收集 RUNSTATS 信息的經典示例。您將獲得 SQL1227N 錯誤消息，並且將無法重新創建該問題，除非手工修改統計數據。
