现在，查看访问计划。如果它们是相同的，那么您就成功地重新创建了访问计划。还请注意，您还应查看 db2exfmt 输出结尾以验证表空间配置是匹配的。 
示例 4： 
生产：MPP，4 个逻辑分区/ 16 个物理分区。 
测试：MPP，4 个逻辑分区，每个逻辑分区中只有 4 台可用的物理机器。 
查询中所涉及的表、视图/MQT。 
本示例中，该模拟可能不会准确工作。测试和生产中的分区数目必须相同。然而，您仍可以尝试重新创建，只是它不会正确。 
因此，您必须向测试环境添加 16*4=64 个分区，以便重新创建正确。测试环境中不需要 16 台物理机器；即您可以具有 4 台物理机器，每台物理机器具有 16 个逻辑分区。这由您来决定，但总共必须有 64 个逻辑分区，与生产中相同。 
因此现在在进行修改向测试环境添加相同数目的逻辑分区之后，测试环境看上去将像原始的生产设置了，如下表所示。 

表 3. 生产设置 
数据库分区（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。以我的经验，客户的所有节点通常具有相同的配置，除了缓冲池这个极其重要的设置之外。 
所遵循的步骤： 
步骤 1：从生产中收集存储器信息： 

db2look -d <dbname> -l -o storage.out 

步骤 2：修改表空间/缓冲池信息以适应这些环境。如果您没有可用的设备，那么就使用 DMS 文件容器。同样，如果您不希望在测试中使用与生产中相同数目的容器，就缩短列表并使用较少容器。但是，您同样必须确保如果生产中的表空间是 DMS 或 SMS 类型的，那么在测试中要保留相同的类型。 

步骤 3：使用下列命令收集配置信息： 

db2look -d <dbname> -f -fd -o config.out 

步骤 4：现在，仅仅为我们感兴趣的对象收集 db2look 信息。本例中，我们需要所有相关信息，包括表 DLL、视图以与表相关的 MQT： 

db2look -d <dbname> -e -a -m -t TAB1 TAB2 TAB3 -o db2look.out 

一旦收集了所有这些信息并修改了表空间/缓冲池信息，就在测试环境中执行 db2look 输出文件，并且重新从生产和测试中获取 db2exfmt 输出并进行比较。 
示例 5： 
这是一关于在表上进行活动时在哪里收集 RUNSTATS 信息的经典示例。您将获得 SQL1227N 错误消息，并且将无法重新创建该问题，除非手工修改统计数据。 
例如，该表具有一百万行记录，一个整型列上定义了主键。您运行带有分布和索引所有选项的 RUNSTATS，从而允许对表进行写访问。在获得表统计数据的时候，有 100,000 条附加记录插入了该表。因此对于表统计数据，CARD 将显示为 1,100,000。但是，在我们开始收集索引统计数据时，例如，对于整型列上所定义的主键，就插入了 10,000 条附加记录，因此，该表中的行数是 1,110,000，而主索引 FIRSTKEYCARD 将是 1,110,000。因此，您可以看到不一致性。表统计数据的 CARD 显示表中应该是 1,100,000 条记录，而主索引统计数据的 FIRSTKEYCARD 显示表中应该是 1,110,000 条记录。对于索引统计数据的更新将失败，并发出 SQL1227N rc=8 错误消息（本例中），因为索引的 FIRSTKEYCARD 大于表的 CARD。您必须手工修复这种不一致性，对于本例，就是使 FIRSTKEYCARD 等于 CARD，均等于 1,100,000，或者反过来 —— 即增加 CARD 到等于 FIRSTKEYCARD，均等于 1,110,000。 
您还可能碰到许多其他的不一致性。请确保在将输出保存为文件的测试中运行带有 -m 选项的 db2look 时，检查所有的不一致性，并进行修复。这里仅仅给出了一个不一致性的例子；您可能会碰到很多其他的不一致性，这将留给用户去修复所有这些不一致性，然后重新运行 db2look，将输出重定向到文件中以确保所有更新的统计数据都运行得很好，没有任何问题。 
示例 6： 
在该示例中，您在生产中获得 SQL0437W rc=1 警告消息，但在测试中没有看到它。本例中，按照上面的示例重新创建该问题。请确保 STMTHEAP 是相同的。如果它是不同的（例如出于某种原因，测试中高于生产中），那么您可能就不会看到相同的警告。同样，我们所讨论的其他参数也很重要。 
SQL0437W rc=2 和其他返回代码也可以按照相同的方法重新进行创建。 
其他错误消息，例如 SQL0101N 和 SQL0901N 也可以使用相同的方法重新进行创建。甚至可以重新创建编译器/优化器领域中的中断。当您处于更老的补丁包级别，并需要尝试最新补丁包级别以查看是否可以避免该问题时，或者当您需要尝试不同的优化级别以查看是否将暂时克服该问题时，这就极其有用。 

结束语 
db2look 是一个功能极其强大的实用程序，可以用于重新创建访问计划问题以及编译器问题，如本文中所讨论的那些。一旦重新创建了该问题，您就可以测试许多可以影响性能的变量，如修改优化级别，尝试注册表变量和更新不影响生产的统计数据，以及测试新的补丁包级别。您将发现这个方便的实用程序可用于调试问题和提高查询性能。