使用db2look 重新创建优化器访问计划

       35
 TABLE: SKAPOOR
      STAFF

该示例显示，如果在表上发生 WRITE 活动时运行 RUNSTATS，统计数据就可能与本示例中的不一致。因此，用于更新统计数据的 UPDATE 语句可能失败并产生 SQL1227N 错误消息。所有的 UPDATE 语句都运行成功十分重要，如果存在不一致性，就应该进行修理并重新运行。本例中，解决方案是将 KEYCARDS 和 NUMRIDS 从 37 重新修改为 35。 
[page_break]示例 3：
您需要在单分区的环境中模拟生产中的整个数据库以进行测试。
注意：如果测试中的数据库名与生产中的不同，那么可能需要修改每个 db2look 输出中的数据库名。
步骤 1：使用 -l 选项收集 db2look，以收集表空间/缓冲池/数据库节点组信息。

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

修改表空间信息以适应您的测试环境。例如，在生产中，您具有下列表空间：

------------------------------------
-- DDL Statements for TABLESPACES --
------------------------------------

CREATE REGULAR TABLESPACE DMS1 IN DATABASE PARTITION GROUP IBMDEFAULTGROUP 
PAGESIZE 4096 MANAGED BY DATABASE
         USING ( FILE ’/data/dms1’20000,
                 FILE ’/data/dms2’20000,
  FILE ’/data/dms3’20000)
         EXTENTSIZE 32
         PREFETCHSIZE 32
         BUFFERPOOL IBMDEFAULTBP
         OVERHEAD 12.670000
         TRANSFERRATE 0.180000
         DROPPED TABLE RECOVERY ON;

如果测试上没有设置相同的路径，那么就要修改上面的位置。如果您仅仅计划模拟环境，而不要复制整个数据，那么就减小文件的大小，并在必要时使用较少容器。如果没有创建相同的缓冲池，那么您还可能修改缓冲池名称。缓冲池必须具有相同的页面大小（pagesize）。不要修改表空间的页面大小。一旦处理了这些并创建了数据库，就运行 storage.out 文件：

db2 -tvf storage.out

如果需要，就重新定向输出以确保都成功运行了。例如：
    
db2 -tvf storage.out > storage_results.out

步骤 2：从生产中收集配置和环境变量信息，并在测试系统上运行它：

db2look -d sample -f -fd -o config.out

请记住，在 MPP 环境中，这将为运行该命令的节点收集该信息。如果不同的数据库分区上的 DB2 注册表和数据库以及数据库管理器配置不同，您将需要为每个节点分别收集该信息。然而，如果测试中无法具有与生产中相同的分区，那么就从生产中执行该查询的节点中收集该信息，然后在测试中使用该信息。
请注意，如果测试中具有不同的分区数目，那么您的模拟将有所欠缺。
在测试系统上，运行 config.out 文件，如下： 
db2 -tvf config.out 

上面考虑到优化器将使用 db2fopt 信息来查看所分配的总的缓冲池和排序堆，现在将成为测试环境中的设置。而且，这也是在测试中由于内存约束而不具有与生产中相同的缓冲池以及排序堆时所使用的技术。同时，本文前面所讨论的配置参数以及环境变量也将进行更新。
步骤 3：当模拟整个数据库时，从生产中收集所有对象的 DDL 信息，并在测试中运行 db2look。

在生产中：

db2look -d sample -e -a -m -o db2look.out

在测试中：

db2 -tvf db2look.out

为了看到输出结果，可发出：

db2look -tvf db2look.out > db2look.results

一旦完成了以上步骤，就请确保在测试中将 dbheap 数据库配置参数设置为与生产中相同的值。
步骤 4：使用 db2exfmt 从测试和生产中获得访问计划，并确保下列内容与生产中的相同：

     Database Context:
----------------
        Parallelism:            None
        CPU Speed:              4.762804e-07
        Comm Speed:             100
        Buffer Pool size:       128500
        Sort Heap size:         128
        Database Heap size:     5120
        Lock List size:         12250
        Maximum Lock List:      10
        Average Applications:   4
        Locks Available:        78400

Package Context:
---------------
        SQL Type:               Dynamic
        Optimization Level:     3
        Blocking:               Block All Cursors
        Isolation Level:        Cursor Stability


---------------- STATEMENT 1  SECTION 201 ----------------
        QUERYNO:                1
        QUERYTAG:               CLP
        Statement Type:         Select
        Updatable:              No
        Deletable:              No
        Query Degree:           1

现在，查看访问计划。如果它们是相同的，那么您就成功地重新创建了访问计划。还请注意，您还应查看 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 是一个功能极其强大的实用程序，可以用于重新创建访问计划问题以及编译器问题，如本文中所讨论的那些。一旦重新创建了该问题，您就可以测试许多可以影响性能的变量，如修改优化级别，尝试注册表变量和更新不影响生产的统计数据，以及测试新的补丁包级别。您将发现这个方便的实用程序可用于调试问题和提高查询性能。

关键词：运用db2look 重新创建优化器访问计划