num_log_span是DB2数据库中一个容易被忽视但非常实用的配置参数，它的作用是限制一个事务（工作单元）在主日志和次级日志中总共能够写入的日志数量。当一个事务产生的日志量超过这个限制时，DB2会强制回滚该事务并返回SQL0964C错误。很多数据库管理员在遇到日志空间不足的问题时，只知道调整LOGPRIMARY和LOGSECOND，却不了解num_log_span同样在背后起作用，导致调参后问题依旧存在。本文将从原理、配置和排查三个层面，把这个参数彻底讲清楚。
num_log_span参数的含义与工作原理
在DB2中，事务日志分为两大部分：主日志（由LOGPRIMARY指定数量）和次级日志（由LOGSECOND指定数量）。每个日志文件的大小由LOGFILSIZ参数决定。事务在执行过程中，所有增删改操作都会先写入日志文件，这是DB2保证事务原子性和持久性的基础。
num_log_span的含义是：一个工作单元（也就是一个尚未提交的事务）允许同时"横跨"多少个日志文件。举例来说，如果LOGPRIMARY为10、LOGSECOND为20，那么系统最多有30个日志文件。若num_log_span设置为25，则表示任何单个事务最多只能占用25个日志文件的空间，哪怕总日志空间还有剩余。
p>这个设计的目的是防止一个失控的大事务把整个日志空间吃光，从而影响其他并发事务的正常运行。DB2在判断是否允许事务继续写日志时，会比较当前事务已经跨越的日志文件数和num_log_span的值，一旦超限就回滚事务。因此它本质上是一个针对单事务的"保险丝"机制。num_log_span与LOGPRIMARY、LOGSECOND的关系
理解num_log_span的关键在于理解它与日志空间参数的配合关系。DB2的默认策略比较特殊：如果不显式设置num_log_span，它的实际生效值等于LOGPRIMARY加上LOGSECOND中较小的那个计算结果，即系统会用num_log_span = min(LOGPRIMARY, LOGSECOND)的方式约束事务。这种默认值在很多场景下是合理的，但当LOGSECOND设置得比LOGPRIMARY还小时，就可能提前触发SQL0964C。
举个例子，假设LOGPRIMARY为20，LOGSECOND为40，LOGFILSIZ为1000页。此时总日志空间为60个日志文件，但默认num_log_span可能只有20。也就是说，一个事务用到第20个日志文件时就会被回滚，即使还有40个次级日志文件完全空闲。这就是很多管理员疑惑"明明次级日志还没用完为什么还报日志满"的根本原因。
合理的设置思路是：如果业务上确实存在大型批处理事务（比如批量DELETE、大规模数据加载、大量INSERT的ETL作业），应该将num_log_span设置为一个小于等于LOGPRIMARY与LOGSECOND之和的值，并且要保证这个值对应的日志空间足以容纳最大事务。查看当前设置可以使用如下命令：
db2 get db cfg for sample | grep -i "log span" -- 输出示例： -- Number of log spans (num_log_span) = 20
如何调整num_log_span及排查SQL0964C错误
调整num_log_span参数非常简单，使用update db cfg命令即可，修改后需要重启数据库或等待所有连接断开后生效，具体取决于参数是否标注为online modifiable。示例如下：
-- 将日志跨度限制设置为50 db2 "UPDATE DB CFG FOR sample USING num_log_span 50" -- 同时合理规划日志空间参数 db2 "UPDATE DB CFG FOR sample USING logprimary 20 logsecond 40 logfilsiz 8192"
当出现SQL0964C错误时，排查思路建议分三步走。第一步确认报错事务的类型：是正常的业务大事务，还是程序忘记提交导致的失控事务。第二步通过数据库快照查看日志使用情况，重点关注最高并发日志跨度数：
db2 get snapshot for database on sample | grep -i "log" -- 重点关注： -- Log space available to the database (Bytes) -- Maximum number of active log spans
第三步才是调参。如果是失控事务（比如应用侧连接长时间不commit），优先修复应用逻辑，必要时可以结合max_log和阻止未提交事务占用过多资源的监控手段；如果是合理的业务大事务，则应该整体评估日志空间，同时增大LOGPRIMARY、LOGSECOND、LOGFILSIZ和num_log_span，并考虑将大事务拆分成小批量提交，避免日志压力过大影响备份和崩溃恢复时间。
需要注意，num_log_span并不是越大越好。放开限制意味着一个大事务理论上可以耗尽全部日志空间，一旦日志写满，所有需要写日志的事务都会阻塞甚至失败。对于生产环境，建议结合快照中统计到的历史最大日志跨度值来设置，一般设置为该值的1.5倍左右并保留一定余量，既保证大事务能跑完，又保留兜底保护能力。
总结与实践建议
num_log_span是DB2日志管理体系中针对单个事务的约束机制，它与LOGPRIMARY、LOGSECOND共同决定了日志空间的分配策略。实践中建议做到三点：一是定期通过快照监控日志使用峰值，掌握业务事务的真实日志需求；二是调大日志空间时不要忘记同步评估num_log_span，避免参数之间互相制约；三是从应用设计上避免超大事务，小批量提交永远是比无限扩日志更优雅的方案。掌握这些要点后，SQL0964C这类日志满问题就能做到有据可查、有法可解。
DB2 num_log_span日志跨度事务日志修改时间：2026-09-02 19:53:39