在DB2的日常运维中，查询性能问题始终是绕不开的话题。当一个SQL语句的执行计划突然变差，而表面上的统计信息、配置参数都看不出异常时，就需要借助更深层次的诊断手段。DB2优化器在编译语句时会经历一系列内部决策，包括扫描方式选择、连接顺序排列、连接方法评估等，这些决策过程默认是不对外暴露的。通过opt_enable_partial_trace这个注册变量，可以打开优化器的部分跟踪功能，把编译期的关键决策信息写入跟踪文件，为排查执行计划问题提供直接证据。
一、opt_enable_partial_trace的工作原理
要理解这个变量的作用，先要弄清楚DB2优化器的工作流程。当一条SQL语句进入数据库后，优化器会基于系统目录表中的统计信息，枚举出多种可能的访问计划，然后通过代价模型计算出每个计划的预估成本，最终选择成本最低的一个。这个过程对用户是黑盒的，一旦选错了计划，从执行计划快照中只能看到结果，看不到选择的原因。
opt_enable_partial_trace属于DB2的注册变量体系，它控制的是优化器在编译语句时是否输出部分级别的跟踪信息。之所以称为部分跟踪，是相对于完整的优化器跟踪而言的。完整跟踪会记录优化器编译过程中的所有细节，产生的数据量极大，对性能影响明显；而部分跟踪只记录关键决策点，比如某个连接顺序被放弃的原因、某个访问路径代价估算的结果，信息密度更高，开销也更可控。
跟踪信息默认写入诊断目录下的跟踪文件中，文件内容以结构化文本形式呈现，可以通过文本工具直接查看。需要注意的是，这个变量属于实例级别的配置，启用后对所有新编译的语句都有效，因此在生产环境使用时要谨慎控制范围。
二、启用与关闭的具体操作步骤
启用该功能需要通过db2set命令设置注册变量。首先确认当前的诊断数据目录位置，跟踪文件会写到 DIAGPATH 指定的路径下。然后执行设置命令并重启实例使配置生效。示例操作如下：
-- 查看当前诊断路径 db2 get dbm cfg show detail | grep -i diagpath -- 启用部分跟踪 db2set DB2_OPTimization_PROFILE=OFF db2set -all -- 设置部分跟踪级别的注册变量 db2set DB2_OPT_ENABLE_PARTIAL_TRACE=ON -- 重启实例使设置生效 db2stop force db2start
实例重启后，可以执行一条测试查询来验证跟踪是否生效。编译完成后，到诊断目录下查看是否生成了新的跟踪文件。如果需要确认变量是否已被识别，可以执行 db2set -all，在输出结果的 [G] 或 [I] 分组中查找该变量。如果变量出现在旁边标有叹号的分组里，说明拼写有误或当前版本不支持，DB2会忽略它。
排查完成后务必及时关闭。关闭的方法同样是通过db2set取消设置，然后重启实例：
-- 取消注册变量 db2set DB2_OPT_ENABLE_PARTIAL_TRACE= -- 验证已清除 db2set -all -- 重启实例 db2stop force db2start
这里要特别提醒一点，实例重启会中断所有现有连接，生产环境操作前必须安排维护窗口，或者考虑在测试环境中先复现问题再采集跟踪。
三、跟踪文件的分析方法与典型应用场景
拿到跟踪文件后，重点要看几个部分。第一是计划枚举的记录，它会列出优化器考虑过的连接顺序组合，以及每个组合的估算代价。如果最优计划明显不是代价最低的那个，可能是优化器搜索空间被剪枝了，这时可以结合 CHEAP 类别的优化级别进一步分析。第二是代价估算的输入参数，包括卡片数估计、过滤因子等，如果这些数字与实际情况偏差很大，问题往往出在统计信息上，比如统计信息过期或者缺少列组统计。
一个典型的应用场景是这样的：某条包含五个表连接的查询，在测试环境跑得很快，到生产环境却选择了完全不同的连接顺序。表面看统计信息都是新的，常规手段查不出原因。这时启用部分跟踪，对比两边的跟踪文件，会发现生产环境对某个中间结果集的基数估计偏小，导致嵌套循环连接被误判为低成本。顺着这条线索，最终定位到是某列的数据分布严重倾斜，收集带分布选项的统计信息后问题解决。
另一个常见场景是配合优化概要文件使用。当需要验证一个优化概要文件的指示是否真正影响了优化器决策时，部分跟踪能直接显示优化器是否按指示调整了计划搜索，这比反复对比执行计划要直观得多。
四、使用中的注意事项与风险控制
虽然部分跟踪的开销比完整跟踪小，但仍然不可忽视。它在语句编译阶段产生额外开销，对于OLTP系统中大量短查询频繁重编译的场景，累积影响可能比较明显。建议只在排查特定问题时临时开启，并且尽量将影响范围缩小到问题语句所在的时间段。
跟踪文件的增长速度也需要关注。对于编译频繁的系统，跟踪文件可能在短时间内占用大量磁盘空间，甚至撑爆诊断所在的文件系统。建议开启前先确认磁盘剩余空间，必要时定期清理旧的跟踪文件。
最后要注意版本差异。不同版本的DB2对这类诊断变量的支持情况有区别，个别版本中行为细节也有变化。在使用前最好查阅对应版本的信息中心文档，确认变量名称和取值格式。如果发现设置后没有任何跟踪文件产生，除了检查拼写，还可以用 db2pd -dbmcfg 确认实例配置是否正常加载。掌握这套方法后，面对难以解释的执行计划问题，就多了一条从优化器决策层面直接取证的路子，比单纯猜测和试错高效得多。
DB2opt_enable_partial_trace优化器跟踪修改时间：2026-09-05 13:08:45