DB2 数据库配置参数详解：从 GET DB CFG 看懂内存、日志、锁与自动维护

一、这篇文章要解决什么问题

DB2 出现内存占用高、锁等待、日志空间不足、备份无法前滚或 SQL 执行计划异常时，经常会先执行：

# SAMPLEDB 是脱敏后的示例数据库名，使用时替换成现场数据库别名
DB_NAME="SAMPLEDB"
db2 get db cfg for "${DB_NAME}"

问题是，GET DB CFG 会一次输出近百个字段。如果只把输出保存下来，却不知道每个字段属于建库属性、运行状态还是可调整参数，后续很容易误判。

本文以一份脱敏后的 DB2 9.7 数据库配置为例，逐项说明这些参数控制什么、当前值意味着什么，以及修改时要注意哪些边界。

本文已做以下脱敏：

• 数据库名统一写成 SAMPLEDB。
• 主机名、IP、业务系统名称和真实实例用户不出现。
• 在线日志、镜像日志和备份目录统一使用变量或占位路径。
• 不包含密码、备份文件名、时间戳和生产容量信息。

二、先学会读 DB CFG 输出

1. AUTOMATIC(数值) 不能照抄括号里的数值

例如：

Size of database shared memory (4KB) (DATABASE_MEMORY) = AUTOMATIC(941860)

真正的配置方式是 AUTOMATIC。括号里的 941860 是 DB2 根据当前机器资源和运行状态计算出的当前值。

迁移到另一台机器时，应保留 AUTOMATIC，不能直接写成：

# 错误示例：把一台机器的自动计算结果固定到另一台机器
db2 update db cfg for "${DB_NAME}" using DATABASE_MEMORY 941860

2. (4KB) 参数需要换算

计算方式：

实际字节数 = 参数值 × 4 KiB

例如 UTIL_HEAP_SZ=524288：

524288 × 4 KiB = 2 GiB

3. 输出里不全是可修改参数

DB CFG 输出包含三类信息：

• 建库属性：代码页、字符集、territory、排序序列和默认页大小，通常不能在线修改。
• 配置参数：可以通过 UPDATE DB CFG 修改，但部分参数需要数据库重新激活才能生效。
• 状态字段：例如 backup pending、rollforward pending，只表示当前状态，不能把它们当成普通参数修改。

三、当前示例配置的关键结论

在逐项展开前，先把最值得关注的地方列出来：

1. 数据库为 GBK / CN / 4 KiB，属于建库属性。
2. 已开启归档日志，但第一归档方式是 LOGRETAIN，没有真正的独立归档目录。失活日志可能长期滞留在在线日志区域。
3. 单个日志文件约 39.06 MiB，50 个主日志约 1.91 GiB，最多 100 个辅助日志约 3.81 GiB。
4. 配置镜像日志后，在线日志和镜像日志会各保存一套。若两个目录位于同一个文件系统，无法防护整个磁盘或逻辑卷故障。
5. UTIL_HEAP_SZ=2 GiB，在小内存实验机上执行 BACKUP、RESTORE、LOAD、REORG 时需要观察内存压力。
6. LOCKTIMEOUT=-1 表示锁可以无限等待。
7. MAXLOCKS=98 允许单个应用使用接近整个锁列表后才触发锁升级。
8. 自动备份和自动清理均关闭，备份文件、恢复历史和归档日志需要人工管理。
9. HADR 参数没有配置，数据库角色是普通的 STANDARD。

四、版本、字符集和建库属性

五、SQL 编译和优化器

六、备份、恢复和一致性状态

这些是状态字段，不是普通调优参数。

七、数据库内存

八、锁和死锁

排查锁问题时可以使用：

# 查看应用连接，重点确认 Application Handle、状态和数据库名
db2 list applications show detail

# 查看锁持有和等待关系
db2pd -db "${DB_NAME}" -locks

九、页面清理、预取和 I/O

十、表空间默认值和连接规模

十一、活动日志

为避免暴露现场目录，以下使用变量表示路径：

# 按现场规划替换，在线日志和镜像日志最好位于不同故障域
ONLINE_LOG_DIR="/path/to/online-log"
MIRROR_LOG_DIR="/path/to/mirror-log"

日志容量应按最坏情况计算：

单套最大日志空间 ≈ LOGFILSIZ × 4 KiB × (LOGPRIMARY + LOGSECOND)
配置镜像日志后，再乘以 2

十二、HADR 高可用

十三、日志归档

如果实验环境不要求严格复刻 LOGRETAIN，可以考虑把归档日志写入独立备份卷：

# ARCHIVE_LOG_DIR 必须替换为现场规划的归档目录
ARCHIVE_LOG_DIR="/path/to/db2-archive/SAMPLEDB"
# 下面两个值是脱敏占位值，必须替换为现场 DB2 实例属主和管理组
DB2_INSTANCE_USER="your_db2_instance_user"
DB2_INSTANCE_GROUP="your_db2_instance_group"

mkdir -p "${ARCHIVE_LOG_DIR}"
chown "${DB2_INSTANCE_USER}:${DB2_INSTANCE_GROUP}" "${ARCHIVE_LOG_DIR}"
chmod 750 "${ARCHIVE_LOG_DIR}"

db2 update db cfg for "${DB_NAME}" using LOGARCHMETH1 "DISK:${ARCHIVE_LOG_DIR}"

上面示例中的 DB2_INSTANCE_USER、DB2_INSTANCE_GROUP、DB_NAME 和 ARCHIVE_LOG_DIR 都是必须按现场替换的变量。改变归档模式后还要确认数据库是否进入 backup pending，并及时做一次完整备份。

十四、崩溃恢复、索引和恢复历史

十五、TSM 备份参数

这些字段为空时，不能据此判断本地文件系统备份是否存在，只能说明 DB CFG 没有配置对应 TSM 参数。

十六、自动维护

十七、自动重验证、并发语义和 XML

十八、监控数据采集

十九、其他可选参数

二十、DB CFG 看不到什么

GET DB CFG 只覆盖数据库级参数。下面这些信息必须从其他位置检查：

# 实例级配置：服务端口、认证、最大连接等
db2 get dbm cfg

# DB2 注册表变量：DB2COMM 等
db2set -all

# 实际缓冲池配置
db2 "select bpname, pagesize, npages from syscat.bufferpools"

# 表空间状态
db2 list tablespaces show detail

# 将 0 换成上一步输出的实际数字 ID
TBSP_ID=0
db2 list tablespace containers for "${TBSP_ID}" show detail

# 当前数据库内存使用
db2pd -db "${DB_NAME}" -memsets

# 当前日志使用和恢复链
db2pd -db "${DB_NAME}" -logs

# 当前应用和锁
db2 list applications show detail
db2pd -db "${DB_NAME}" -locks

其中 TBSP_ID=0 只是示例值，执行前必须替换为目标表空间的实际数字 ID。

二十一、建议的巡检顺序

以后拿到一份陌生数据库的 CFG，可以按下面顺序判断：

1. 先看代码页、页大小和排序序列，确认建库属性是否符合应用要求。
2. 看 backup pending、rollforward pending 和 restore pending，确认数据库是否处于特殊恢复状态。
3. 看 DATABASE_MEMORY、缓冲池、排序堆和工具堆，判断内存配置是否与主机资源匹配。
4. 看 LOCKLIST、MAXLOCKS、LOCKTIMEOUT 和死锁监控，判断阻塞问题是否容易被发现。
5. 计算 LOGFILSIZ、LOGPRIMARY、LOGSECOND 和镜像日志的最大磁盘占用。
6. 确认 LOGARCHMETH1 是否有真正的归档目标，以及归档日志由谁清理。
7. 确认备份是否自动执行、恢复历史保留多久、旧文件是否自动删除。
8. 最后结合 DBM CFG、db2set、表空间、缓冲池和实时 db2pd 数据判断，不能只凭一份静态 DB CFG 下结论。

二十二、总结

GET DB CFG 的价值不在于保存一份长输出，而在于建立参数之间的联系：

• 内存参数决定数据库能在内存里完成多少工作。
• 锁参数决定并发冲突如何等待、升级和暴露。
• 活动日志决定事务峰值能撑多久。
• 归档日志和备份共同决定能恢复到什么时间点。
• 自动维护和监控参数决定问题能否提前发现。

真正做配置迁移时，还要特别区分“固定配置值”和 AUTOMATIC(当前值)。只有配置方式可以复用，当前运行值必须让目标机器重新计算。