现在进行修改：向测试环境添加相同数目的逻辑分区之后，测试环境看上去将像原始的生产设置了，如下表所示。
生产设置:
数据库分区（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 中的 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 TAB1
TAB2 TAB3 -o db2look.out一旦收集了所有这些信息并修改了表空间/缓冲池信息，就在测试环境中执行 db2look 输出文件，并且重新从生产和测试中获取 db2exfmt 输出并进行比较。
这是一个关于在表上进行活动时在哪里收集 RUNSTATS 信息的经典示例。您将获得 SQL1227N 错误消息，并且将无法重新创建该问题，除非手工修改统计数据。
保留地址 http://www.qqread.com/db2/u351949.html
更多内容请看系统优化大全、DB2、DB2中的数据处理专题，或进入讨论组讨论。
相关图文阅读
频道图文推荐
健 康 咨 询
时 尚 咨 询
相关专题
- 讲解一个标准规则的集合──DB2优化器 (0次浏览)
- 利用VS2005构建针对DB2的应用程序和Web站点 (0次浏览)
- 聚焦 DB2 的XML能力 (0次浏览)
- 教你提高商业智能环境中的DB2查询性能 (0次浏览)
- 用DB2 VS2005 .Net插件进行XML数据验证 (0次浏览)
- 针对VS2005 的IBM数据库插件概述 (0次浏览)
- DB2 “Viper 2”助力IT敏捷性 (0次浏览)
- DB2和Visual Studio .NET开发慨述 (0次浏览)
- 在WebLogic集群环境中使用DB2 Alphablox (0次浏览)
- Oracle与DB2、MySQL取前10条记录的对比 (0次浏览)
