DB2 的优化器在生成执行计划时，会根据统计信息、索引可用性、系统资源状态以及查询语句自身的限制条件来决定如何访问数据。大多数情况下，这个决策过程是可靠的，但一旦出现只返回部分数据、而业务预期是完整结果集的情况，就需要深入分析优化器为什么提前终止了数据扫描。opt_enable_partial_data_troubleshooting 变量正是用于暴露这一内部决策过程的诊断开关。开启之后，优化器会把与部分数据返回相关的判断依据写入诊断日志，让数据库管理员不再只能靠猜测定位问题。
这个变量属于 DB2 注册表变量体系，通过 db2set 命令进行设置。它的作用范围可以是实例级，也可以是数据库级，具体取决于设置时的附加参数。在默认情况下，该变量处于关闭状态，因为开启后会增加优化器生成计划时的日志输出量，对性能有一定影响。因此，建议先在测试环境或业务低峰期验证，确认需要后再谨慎开启生产实例。
认识 opt_enable_partial_data_troubleshooting 变量
opt_enable_partial_data_troubleshooting 的核心作用是让优化器在面临可能返回部分数据的访问路径时，记录更加详细的决策信息。这些信息通常包括：表扫描是否因为某个阈值而被截断、索引扫描是否因为缺少键值而提前结束、并行扫描是否因为分区裁剪异常而漏掉了某些数据分片，以及是否因为内存或 CPU 资源限制而主动降低了数据读取范围。通过这些标记，管理员可以快速区分是统计数据不准确导致的误判，还是系统资源配置触发了保护机制。
需要特别说明的是，该变量本身并不会改变查询结果，也不会强制优化器返回完整数据。它只是一个诊断开关，只负责输出更多内部信息。因此，如果在开启后发现查询行为发生变化，那通常意味着优化器在记录诊断信息时选择了不同的访问路径，或者某些隐藏的优化参数被连带激活。这种情况虽然少见，但在生产环境中仍需保持警惕，避免将诊断行为误解为业务逻辑变更。
从实现角度看，这个变量与 DB2 优化器内部的 partial data 策略紧密相关。优化器在处理大型表或复杂查询时，可能会采用一种折中策略：先返回一部分数据满足前端的快速展示需求，再根据后续请求逐步返回剩余数据。但这种策略并不总是符合业务预期，尤其是当应用层没有正确处理分页或游标时，就会出现所谓只返回部分数据的现象。开启该变量后，优化器会明确标记哪些访问路径被判定为 partial data，从而帮助定位是应用层读取方式的问题还是数据库层主动截断了结果集。
如何开启与关闭该排障变量
开启该变量的标准做法是通过 db2set 命令设置实例级变量。以 Linux 或 Unix 环境为例，使用实例用户执行以下命令即可：
db2set DB2_OPT_ENABLE_PARTIAL_DATA_TROUBLESHOOTING=ON db2set -all
第一条命令将变量值设置为 ON，第二条命令用于确认设置是否生效。需要注意的是，db2set 设置的变量只有在实例重启后才会被 DB2 优化器完整读取。因此，执行完设置后，需要停止并重新启动实例：
db2stop force db2start
关闭变量时，同样通过 db2set 命令将值改为 OFF 并重启实例：
db2set DB2_OPT_ENABLE_PARTIAL_DATA_TROUBLESHOOTING=OFF db2stop force db2start
在 Windows 环境下，命令完全一致，只是执行时需要在 DB2 命令窗口中进行。此外，如果只是想临时测试该变量的影响，也可以在数据库连接级别使用 db2set 的附加参数指定作用范围，但这种方式较少使用，更多情况下直接使用实例级设置足够满足排障需求。生产环境开启前务必评估日志增长情况，诊断日志可能因为大量输出而占用磁盘空间，建议配合日志清理策略使用。
结合执行计划与诊断信息定位部分数据问题
开启变量后，需要重新执行出现问题的查询，并收集执行计划与诊断日志。执行计划可以通过 db2exfmt 工具导出，命令示例如下：
db2 connect to sample db2 set current explain mode explain db2 "SELECT * FROM large_table WHERE status = 'A'" db2 set current explain mode no db2exfmt -d sample -g TIC -w -1 -n % -s % -# 0 -o plan.txt
在导出的执行计划中，需要重点查找带有 partial data 标记的访问节点。例如，某个表扫描节点后面可能会列出 Row Threshold 或 Partial Scan 字样，这表示优化器认为该表只需要读取一部分行就能满足查询需求。如果业务上要求返回全部满足条件的行，那么这里的 partial data 标记就是关键线索。进一步分析该标记下方的诊断信息，可以看到触发阈值的原因，可能是 FETCH FIRST 子句、OPTIMIZE FOR 子句，也可能是优化器基于统计信息估算出的行数远小于实际行数。
除了执行计划，数据库诊断日志中也会记录优化器输出的一部分决策过程。这些日志通常位于实例目录下的 db2dump 文件夹中，文件名以 db2opt 开头。在这些日志里可以搜索 partial data 关键字，查看优化器在哪个阶段做出了截断决策。如果日志中显示是因为某个表的统计信息过旧，导致优化器认为该表只有少量满足条件的行，那么更新统计信息后再执行查询往往就能恢复正常。如果日志显示是因为系统资源监控触发了保护机制，则需要调整数据库内存参数或降低查询并发度。
实际案例分析：一次部分数据返回的排查
假设某业务系统中的一个报表查询突然开始只返回前几百行数据，而过去一直返回完整结果集。开发人员检查应用代码未发现问题，SQL 语句也没有变更。数据库管理员通过 db2set 开启 opt_enable_partial_data_troubleshooting 变量并重启实例后，重新执行了该报表查询。在导出的执行计划中，发现一个关键表扫描节点被标记为 Partial Scan，诊断日志中给出了原因：优化器认为该表的统计信息显示满足过滤条件的行数只有约 300 行，因此采用了提前终止扫描的策略。
管理员进一步检查该表的统计信息更新时间，发现距离上次收集已经过去三个月，期间该表数据量增长了数倍。由于统计信息未及时更新，优化器严重低估了返回行数。随后执行 RUNSTATS 命令更新统计信息：
db2 runstats on table myschema.large_table with distribution and detailed indexes all
更新完成后，再次执行报表查询，返回结果恢复到完整行数。此时执行计划中的 Partial Scan 标记消失，诊断日志中也显示优化器重新评估了行数并选择了全表扫描。这个案例说明，opt_enable_partial_data_troubleshooting 变量的价值在于快速暴露优化器内部截断决策的依据，让管理员能够准确判断是统计信息问题还是其他因素导致的异常，从而避免盲目调整参数或重写 SQL。
使用该变量的注意事项
首先，该变量不适合长期开启。诊断信息输出会增加优化器生成计划的时间，并且诊断日志体积可能快速膨胀。通常建议在问题稳定复现的时间窗口内开启，收集完执行计划与诊断日志后立即关闭。其次，开启变量前应确认数据库实例的维护窗口和备份策略，因为设置后需要重启实例，会影响当前连接与未提交事务。最好在业务低峰期进行。
另外，部分数据返回问题并不一定由优化器引起。应用层如果使用游标但没有正确遍历，或者使用了中断读取的方式，也会表现出只返回部分数据的现象。因此，在开启该变量之前，应先确认 SQL 语句本身是否包含 FETCH FIRST、OPTIMIZE FOR 等限制性子句，以及应用代码是否完整读取了结果集。只有在排除应用层因素后，再从数据库优化器层面深入分析，才能避免无效的排障工作。
DB2opt_enable_partial_data_troubleshooting部分数据排障修改时间：2026-09-19 11:59:16