在 DB2 数据库中，事务日志是保证数据一致性和崩溃恢复的核心组件。每条 INSERT、UPDATE 或 DELETE 操作都会生成相应的日志记录，先写入日志缓冲区，再由日志写入进程刷到磁盘上的日志文件。数据库配置参数 LOGPRIMARY 就是用来控制主日志文件数量的，它决定数据库激活时预先分配多少个日志文件供事务写入使用。理解这个参数需要从日志文件的生命周期和循环复用机制入手，而不能简单认为它只是一个数值。
主日志文件通常位于数据库日志目录中，命名格式为 S0000000.LOG、S0000001.LOG 等，默认情况下日志文件大小由 LOGFILSIZ 控制。当数据库激活时，DB2 会按照 LOGPRIMARY 的值创建这些文件，文件大小统一。预先分配的好处是避免在事务执行过程中动态创建文件造成的延迟和空间分配失败，同时也能确保日志链从起始就是连续的。但它也意味着磁盘空间会被立即占用，如果设置得过大，会带来不必要的空间开销。
一、logprimary 与事务日志的关系
日志文件并不是无限增长的，DB2 采用循环写入的方式管理这些文件。一个事务产生的日志会从当前日志文件的末尾继续追加，当当前文件写满后，数据库会切换到下一个日志文件。如果所有主日志文件都已写满，而旧的日志文件因为某些原因不能复用，例如归档尚未完成或存在长事务持有旧日志，数据库就会尝试分配辅助日志文件。如果辅助日志也不可用，事务就会收到 SQL0964C 错误。
查看数据库当前的日志配置，可以使用如下命令。在 Linux 环境中通常使用 grep 过滤关键参数：
db2 get db cfg for sample | grep -i "LOGPRIMARY\|LOGSECOND\|LOGFILSIZ"
如果是在 Windows 的 DB2 命令行窗口中，管道和 findstr 也能完成类似过滤，但要注意环境变量配置。这个命令输出中会包含当前 LOGPRIMARY 的值。需要特别说明的是，这里显示的是配置值，实际分配的日志文件数量还会受到数据库是否处于归档模式、是否存在辅助日志分配的影响。日志文件路径可以通过 NEWLOGPATH 参数查看，不要与日志归档路径 LOGARCHMETH1 指定的位置混淆。
二、logprimary 与 logsecond 的协作机制
如果把 LOGPRIMARY 看作常备的日志文件池，那么 LOGSECOND 就是按需扩展的临时池。数据库启动时会分配 LOGPRIMARY 个主日志文件，当这些文件写满且无法立即复用时，DB2 会尝试分配辅助日志文件。辅助日志文件的数量由 LOGSECOND 控制，它们在需要时创建，用完且不再需要后可能会被删除，具体行为取决于数据库版本和归档配置。这种设计可以在常规负载下保持较小的磁盘占用，同时在峰值负载时提供一定的弹性。
两者的总可用日志空间可以用表达式 (LOGPRIMARY + LOGSECOND) × LOGFILSIZ × 4KB 来估算。之所以乘以 4KB，是因为 LOGFILSIZ 的单位是 4KB 页，而不是字节。例如 LOGPRIMARY 为 10，LOGSECOND 为 10，LOGFILSIZ 为 1000 时，总日志空间约为 80MB；这在高并发写入场景下可能很快耗尽。很多生产环境习惯把 LOGFILSIZ 设置为 4000 到 10000 页，再配合 20 到 50 个主日志文件。
修改参数的命令并不复杂，但需要谨慎评估。下面命令将主日志文件数调整为 20，辅助日志文件数调整为 10：
db2 update db cfg for sample using LOGPRIMARY 20 LOGSECOND 10 db2 terminate db2 deactivate db sample db2 activate db sample
执行 update db cfg 后通常需要停掉应用连接，重新激活数据库才能让新的日志配置完全生效。仅执行 terminate 可能不够，因为已有连接和缓冲区可能仍然引用旧的日志文件。可以使用 db2 list applications 查看当前连接，必要时通过 db2 force application all 断开所有会话再操作。
三、如何根据事务负载计算合理的 logprimary
没有一种固定的 LOGPRIMARY 值适用于所有业务，必须结合事务量、日志产生速率和归档能力来估算。第一步是采集基础数据：平均每秒事务数、单个事务平均产生的日志字节数、峰值持续时间以及日志归档到磁盘或远程位置所需的时间。DB2 提供了 db2pd 工具，可以查看当前日志使用情况和事务信息。
例如执行 db2pd -d sample -logs 后，可以关注输出中的 Log Full 次数、Archive Log Failures 次数以及当前活动的日志文件编号。如果 Log Full 经常大于 0，说明现有的主日志和辅助日志空间在峰值写入时不够用，需要考虑增大 LOGPRIMARY 或 LOGSECOND。下面是一个监控命令示例：
db2pd -d sample -logs | grep -i "Log Full\|Archive Log Failures"
估算时可以把日志文件视作一个流式缓冲区。假设业务峰值每分钟产生 60MB 日志，单个日志文件大小为 4MB，那么每分钟就需要约 15 个日志文件。如果归档或日志复用需要 3 分钟，则至少需要 45 个日志文件才能平滑度过归档窗口，再加上额外余量，可以考虑设置 LOGPRIMARY 为 50。当然，这个值必须结合磁盘剩余空间来判断，因为主日志文件是预先分配的，设置后立即占用空间。
四、日志满故障排查与优化实践
数据库出现 SQL0964C 错误时，通常意味着事务日志空间已经耗尽。这个错误不一定是因为 LOGPRIMARY 太小，也可能是某个长事务一直没有提交，阻止了旧日志文件的复用。因为日志文件必须保留给事务回滚和崩溃恢复使用，只要有一个事务的日志散落在某个旧文件中，这个文件就不能被覆盖。因此遇到日志满时，首先要定位长事务，而不是盲目调大参数。
可以通过 db2 list applications show detail 查看连接状态和事务开始时间，再用 db2pd -d sample -transactions 查看活动事务的日志空间使用情况。如果发现某个应用长时间处于 UOW Executing 状态，并且写入了大量日志，就需要与应用负责人确认是否可以提交或回滚。必要时可以使用 db2 force application (agent_id) 终止该连接，其中 agent_id 从 list applications 输出中获取。
db2 list applications show detail db2pd -d sample -transactions db2 force application (12345)
在解决了长事务之后，再评估参数是否需要调整。若因为归档目的端磁盘满或网络抖动导致日志无法归档，应该优先恢复归档通道，而不是通过增加 LOGPRIMARY 来掩盖问题。否则日志文件数量再多，也会在归档失败后逐渐耗尽。预防方面，建议把 db2pd -logs 的 Log Full 指标纳入监控，设置合理的告警阈值，并定期分析日志增长趋势，结合业务峰值动态调整 LOGPRIMARY 与 LOGSECOND。对于归档模式数据库，还应当检查 LOGARCHMETH1 的配置和归档目的端的可用空间，确保主日志文件能够及时释放。
DB2 logprimary事务日志数据库参数调整修改时间：2026-10-05 03:24:09