現在進行修改：向測試環境添加相同數目的邏輯分區之后，測試環境看上去將像原始的生產設置了，如下表所示。生產設置:數據庫分區（DBPARTITIONALLNODES（在節點 1 到 64 上）NODE1（節點 1 上所定義的 db 分區）NODE2（節點 5 上所定義的 db 分區）表空間（TABLESPACE）TABSPACE1（DMS 使用數據庫分區 ALLNODES 中定義的設備）TABSPACE2（DMS 使用數據庫分區 NODE1 中定義的 SMS）TABSPACE3（DMS 使用數據庫分區 NODE2 中定義的 DMS）表TABSPACE1 中的 TAB1TABSPACE2 中的 TAB2TABSPACE3 中的 TAB3MQT：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 TAB1TAB2 TAB3 -o db2look.out一旦收集了所有這些信息并修改了表空間/緩沖池信息，就在測試環境中執行 db2look 輸出文件，并且重新從生產和測試中獲取 db2exfmt 輸出并進行比較。這是一個關于在表上進行活動時在哪里收集 RUNSTATS 信息的經典示例。您將獲得 SQL1227N 錯誤消息，并且將無法重新創建該問題，除非手工修改統計數據。