一、pckcachesz 控制的内存区域与作用

pckcachesz 是 DB2 数据库配置参数，表示包缓存大小，单位是 4KB 页。它对应的内存区域记录已经编译好的 SQL 访问计划、包信息和分区信息。数据库接到一条 SQL 时，会先解析 SQL 文本，然后查找包缓存中是否存在可以复用的执行计划。如果命中，就跳过编译阶段直接执行；如果没有命中，则需要进行权限检查、语义分析、优化器生成计划、写入缓存等一系列动作。因此包缓存既影响 CPU 消耗，也影响高并发下的响应时间。

需要明确的是，包缓存不属于缓冲池。缓冲池负责缓存表和索引的数据页，而 pckcachesz 管理的是数据库共享内存中的执行计划缓存。两者混淆后容易做出错误调整，例如数据页频繁换出时增大包缓存，并不会改善 I/O 压力。默认情况下，DB2 从 V9.5 开始支持 AUTOMATIC 值，让数据库根据工作负载自动调整。自动管理虽然省事，但在负载剧烈变化或内存本身紧张的环境中，仍然需要人工核对其上下限。

包缓存中的对象以包名、schema、版本、路径等维度区分。对于动态 SQL，DB2 还会根据 SQL 文本做哈希匹配。如果应用使用绑定变量，相同 SQL 文本可以被反复命中；如果应用每次拼出不同的条件值，即使逻辑相同，也可能被认为是不同语句而生成多个包，这会迅速占满缓存。

二、合理设置前的监控与计算

判断是否需要调整 pckcachesz，首先要看包缓存命中率。次要指标包括包缓存最大使用量、插入次数、未命中次数以及数据库共享内存剩余空间。通过 db2pd 或 MON_GET_DATABASE 表函数可以拿到这些数据。下面语句查看数据库级别的包缓存命中情况：

SELECT
  PKG_CACHE_LOOKUPS,
  PKG_CACHE_INSERTS,
  CASE WHEN PKG_CACHE_LOOKUPS = 0 THEN 0
       ELSE DECIMAL((1 - (FLOAT(PKG_CACHE_INSERTS) / FLOAT(PKG_CACHE_LOOKUPS))) * 100, 5, 2)
  END AS PKG_CACHE_HIT_RATIO
FROM TABLE(MON_GET_DATABASE(-2))

上述查询中的 PKG_CACHE_LOOKUPS 表示数据库从包缓存尝试查找的次数，PKG_CACHE_INSERTS 表示未命中后新插入执行计划的次数。命中率低于 95% 时，在高频 OLTP 系统中通常意味着响应时间会被编译开销拖累。不过要特别注意，监控周期不能太短。业务低峰期连接少、SQL 类型固定，命中率可能接近 99%；高峰期如果降到 90% 以下，才更有调整价值。

另一个有效指标是包缓存高水位。通过 db2pd -db sample -dbcfg 查看当前大小，再用 db2pd -db sample -memsets 查看实际使用内存。若当前设置是 AUTOMATIC，可以看到已自动调整到多少页。如果使用量长期逼近上限，同时命中率下降，说明缓存空间不足。计算初始值时，可以先按并发活动 SQL 数乘平均执行计划大小估算。一个简单办法是：高峰期抓取 MON_GET_PKG_CACHE_STMT 结果，统计近 30 分钟内不同 EXECUTABLE_ID 数量，再乘每条计划约 40KB 到 100KB 的经验值，换算成 4KB 页数。

系统内存也要同步考虑。包缓存属于数据库共享内存的一部分，如果实例内存和数据库内存上限已经接近物理内存，继续调大只可能导致操作系统换页。此时应先调整 database_memory、instance_memory 或降低 bufferpool 大小，再增加包缓存。

三、调整 pckcachesz 的完整步骤

调整前建议先记录当前值，并确认连接状态。以下命令查看当前数据库包缓存配置：

db2 get db cfg for sample | grep -i "Package cache"
db2pd -db sample -dbcfg | grep -i pckcachesz

假设当前值为 AUTOMATIC(8192)，表示初始为 8192 页，即 32MB，数据库可以自动调高。如果监控发现高峰期命中率不理想，可以先固定为一个更大的值，例如 16384 页，即 64MB。执行更新时需要加上 immediate，让参数在连接活跃时生效：

db2 connect to sample
db2 update db cfg for sample using pckcachesz 16384 immediate
db2 terminate

调完后不要立即判断效果。需要经过至少一到两个完整业务周期，再查看 PKG_CACHE_HIT_RATIO、PKG_CACHE_INSERTS 和高水位变化。推荐在业务高峰期采集两次快照，间隔 15 到 30 分钟。若插入次数下降、命中率提升，说明调整方向正确；若插入次数下降但内存使用没有增长，说明问题可能不在包缓存空间，而是 SQL 文本完全一致的情况下可以复用。

如果设置了非自动值，之后又想恢复自动管理，可以使用 db2 update db cfg for sample using pckcachesz AUTOMATIC。自动模式允许数据库在负载增长时扩展缓存，但自动扩展有延迟。极端的批量作业突然涌入时，仍可能出现阶段性编译抖动。因此很多生产系统会设置一个固定下限，避免从很小的值开始自动增长。

四、常见误区与参数联动

第一个常见误区是把包缓存命中率低全部归结为 pckcachesz 太小。实际上，如果应用没有使用参数标记，而是拼接了不同的常量，例如 WHERE CUSTOMER_ID = 1001 和 WHERE CUSTOMER_ID = 1002，DB2 会生成不同的包缓存条目。即使把缓存调到几百 MB，也只是延缓了高水位达到时间，并不能从根本上减少编译数量。这时应优先推动应用改为参数标记，或评估 stmt_conc、pckcachesz 之外的 SQL 标准化能力。

第二个误区是只看参数数值大小，忽略包缓存的内存归属和交互。比如启用 DFP 或 pureScale 架构时，每个成员或节点的包缓存设置应当一致，并且要考虑全局内存。另一个联动参数是 maxappls。并发连接数越多，每个应用可持有的游标和执行计划越多，包缓存压力也随之增加。如果同时调大了 maxappls 却没有增加包缓存，可能造成缓存频繁换出。

还需要区分包缓存和排序堆、临时表空间使用的内存。排序堆 sortheap 是每个代理私有的内存，包缓存是数据库共享内存。遇到 SQL 性能问题时，优先看执行计划和 I/O，确认是编译压力还是运行压力。可以通过 db2 get snapshot for all databases 查看 Package cache overflows 等指标辅助判断。超过 0 通常意味着包缓存发生了过期淘汰。

最后，使用 db2fodc -db sample -memsets 或 db2mtrk -i -d -v 查看内存块分配是否正常。如果出现 Memory allocation failure，不要继续上调，应当降低其他内存参数。包缓存大小的调优是迭代过程，不是一次性配置。