在 DB2 for i 6.1 中分析 SQE 的使用

核心提示：从 V5R2 开始，在每个操作系统发行版中，在 DB2 for i 6.1 中分析 SQE 的使用，DB2 for IBM i 都在不断地将更多的查询从 Classic Query Engine（CQE）转换为 SQL Query Engine（SQE），对于 IBM i 6.1，使用本文描述的增强和工具，理解 CQE

从 V5R2 开始，在每个操作系统发行版中，DB2 for IBM i 都在不断地将更多的查询从 Classic Query Engine（CQE）转换为 SQL Query Engine（SQE）。对于 IBM i 6.1，SQE 方面有进一步的增强，这次又增加了以下 SQE 支持：

National Language Sort Sequence（NLSS）支持

CCSID 转换支持，包括 UPPER 和 LOWER 函数

CASE 增强

User Defined Table Function（UDTF）支持

Lateral Correlation

本文解释如何收集 SQL 性能监视器，以及理解很多 SQL 查询在如何使用 SQE，为什么其他 SQL 语句继续使用 CQE。SQE 是 DB2 for i 上的战略性查询引擎，具有更好的性能、可伸缩性和工具，例如 SQL Plan Cache。

收集数据

可以从 System i Navigator 中收集和分析 SQL 性能监视器。另一种方法是使用 Start Database Monitor（STRDBMON）和 End Database Monitor（ENDDBMON）命令来收集数据，并构造查询来分析产生的监视器输出文件。本文着重介绍使用 System i Navigator 方法收集和分析数据。不管使用何种方法，收集数据时都需要 *JOBCTL 用户特殊权限，因为这个例子将收集所有任务的监视器详细信息。如果 SQL 性能监视器目标任务是一个特定的任务，并且该任务是由当前用户启动的，那么不需要 *JOBCTL 用户特殊权限。

从 System i Navigator 中，展开 databases 区，右键单击 SQL Performance Monitors，选择 New。

命名新的监视器，并为数据选择一种模式（库）。

在多个 SQL 性能监视器预过滤器之间进行选择。预过滤器限制收集的数据的数量，这对于性能和监视器输出的规模有重要影响。对于我的例子，我选择 minimum estimate query runtime，并将值设为 0，因为我想避免收集非查询 SQL 语句的详细信息。

对于我的例子，我监视整个系统上的所有任务（包括已有的和将来的任务）。

这时出现一个确认屏幕，表明我们可以开始激活监视器。

新的监视器被自动添加到 SQL Performance Monitors 列表中。当监视器启动时，将收集用于所监视任务的符合预过滤器标准的 SQL 语句。在监视器上单击右键，可以看到一些可用选项。然后，可以在监视器正在运行或者结束（被关闭）之后对监视器进行分析。

用户注意事项

在繁忙的计算机上，公共监视器（例如本例使用的监视器）可能收集到大量的数据。在决定 SQL 性能监视器的收集时机和持续时间时，要谨慎对待。

如果选择了 Analyze 选项，那么将看到一个概述屏幕。概述包含有用的监视器总结信息，包括使用 SQE 和 CQE 的查询的数量。一种分析方法是针对 CQE 查询选择 Summary 选项。这将有助于理解为什么那些查询使用 CQE。

默认视图显示每个监视器列。建议使用 View 下拉菜单中的 Columns 选项，以限制和整理这些列。对于较大的监视器，这个技巧可以提高 System i Navigator 性能。而且，对于任何监视器，这个技巧都使数据分析变得更容易。

对于本例，我选择 Operation，以便查询命令或 SQL 名称，另外还有 CQE Reason。usage count 和 average runtime 将为理解查询的性能影响提供必要的上下文。

例子数据显示，有些查询在使用非 SQL 接口（RUNQRY 命令、OPNQRYF 命令和 QQQQRY() API），还有一条 INSERT with VALUES 语句在使用 CQE。INSERT with VALUES 是一个特例，因为它无法从通过 SQE 执行中受益，因为该语句没有选择标准、分组或排序。

使用 CQE 的原因

概述信息有助于确定 CQE 与 SQE 的使用对于环境或应用程序的重要性。对 CQE 的使用进行分析后，可以根据使用 CQE 的不同原因来判断是否可以采取行动将更多查询引擎工作转换为 SQE。

表 1 列出在 IBM i 6.1 上使用 CQE 的其他原因。中间的列显示在分析 SQL 性能监视器时观察到的值，最后一列定义输出的监视器文件中 QVC43 列显示的值。QVC43 值只对直接使用监视器输出文件而不是使用 System i Navigator 中的分析特性感兴趣。

表 1.

使用 CQE 的原因	SQL 性能监视器的值	QVC43 列值（当 QQRID=3014 时）
简单的插入	INSERT_VALUES_OR_INSERT_TARGET	'IO'
查询中有太多的表	GREATER_THAN_256_TABLES	'NF'
不是 SQL 查询，或者查询没有通过 SQL 接口执行	NON_SQL_INTERFACE	'NS'
查询中有一个分布式的表	DISTRIBUTED_TABLE	'DF'
查询的表上定义了一个读触发器	READ_TRIGGER	'RT'
查询中有一个程序描述文件	IDDU_LINKED_DEFINITION	'PD'
分区表上使用了 WHERE CURRENT OF	COMPLEX_UPDATE_WHERE_CURRENT_ON_PARTITIONED_TABLE	'WC'
分区表上使用了 WHERE CURRENT OF	COMPLEX_UPDATE_WHERE_CURRENT_ON_PARTITIONED_TABLE	'WC'
查询定义中指定了一个 DDS 逻辑文件	DDS_LOGICAL_FILE	'LF'
发现一个包含派生键的 DDS 逻辑文件，或者所查询的表上存在选择/忽略标准	DERIVED_KEY_OR_SELECT_OMIT_LOGICAL_FILE	'DK'

一个特例

这个表中的最后一个原因比较特殊，因为有一个操作控制，允许当一个逻辑文件包含派生键或者一个表上存在选择/忽略标准时仍使用 SQE。

计数是如何进行的

DB2 for i 6.1 最近的一个增强使得理解在 SQL 性能监视器中 SQL 语句级使用优化器成为可能。上面的例子场景便依赖于这个增强。对于偏爱直接使用数据库监视器输出文件的人来说，本节提供的详细信息比较有用。

1000 记录（QQRID=1000）中的 QQSMINT5 列表显示优化器的使用。这个列有 5 个可能的值。

null = 数据库监视器文件早于这个增强

0 = 不应用于该语句，因为两种查询引擎都不需要，或者没有用到

1 = 使用 SQE（SQL Query Engine）

2 = 使用 CQE（Classic Query Engine）

3 = 使用 CQE direct（例如 INSERT WITH VALUES 之类的语句）

对于活动的任务，包括那些重用 Open Data Path（ODP）和 SQL 游标的任务，QQSMINT5 值是准确的。为了理解使用 CQE 的原因，需要查看相关的 3014 记录。3014 记录是在 SQL 游标完全打开期间生成的，该记录解释为什么对于重用模式的 SQL 语句，使用 CQE 的原因比较模糊。

要使用这个对 QQSMINT5 字段的增强，必须装载下面的 V6R1 PTF。

SI33874

SI33875

SI33876

SI34001

SI34002

转换到 IBM i 6.1 后，应该花时间分析 CQE 和 SQE 的使用。DB2 for i 的投入主要集中于 SQE，在 6.1 上应该可以看到对 SQE 的更广泛的使用。有些安装可能使用 IGNORE_DERIVED_INDEX 配置已有的 QAQQINI 查询文件选项，并将 IGNORE_DERIVED_INDEX 设为 “*NO”。使用本文描述的增强和工具，理解 CQE 活动的范围，并考虑克服一切障碍转为使用 SQE。