现在进行修改：向测试环境添加相同数目的逻辑分区之后，测试环境看上去将像原始的生产设置了，如下表所示。

 

生产设置:

 

数据库分区（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 错误消息，并且将无法重新创建该问题，除非手工修改统计数据。

 

 

来自: 新客网(www.xker.com) 详文参考：http://www.xker.com/page/e2007/0806/29235.html