IBM DB2 数据库恢复：症状、原因、方法与难点

DB2 在金融、保险、大型企业和电信存量系统里装机量巨大，国内大量核心业务跑在 DB2 上。它的恢复体系很严谨，但损坏起来的"症状语言"和 Oracle/MySQL 完全不同——先看症状。

DB2 损坏的常见症状

实例级：启动报 SQL1032N（实例未启动，常由底层文件损坏或权限错误引起）、诊断日志 diag.log 里大量 SQL0901N 内部错误。数据库级：SQL0290N（表空间容器不可访问）——容器文件丢失、路径变更、底层存储故障的头号信号；SQL0294N 容器已满导致的写入失败；表空间被置为"脱机/挂起"状态（offline/pending），数据库能连但表查不出。数据页级：查询报"bad page"、损坏页、校验和错误，某些表访问即实例崩溃。日志级：crash recovery 挂起不动、rollforward 报日志链断裂。备份级：backup 命令直接失败——很多客户是"备份做不了"才发现库已经坏了。

DB2 损坏的常见原因

硬件层：磁盘/RAID 故障、内存坏条导致页写脏、存储控制器缓存掉电丢数据。系统层：异常断电、操作系统崩溃时的半写页——日志和校验和能挡住一部分，但底层 IO 不保证原子性照样会破。空间层：日志文件系统写满——事务挂着、库被强制脱机，这是 DB2 现场最常见的"人祸"。人为层：操作系统层直接动文件（mv/cp 容器文件、改路径）、force applications 强杀大事务、误 drop tablespace、升级脚本中断、版本和补丁不一致。

DB2 的恢复方法

自动崩溃恢复：重启时 DB2 用日志做 crash recovery，日志没断时这一步自己能完成。备份还原+前滚：从离线/在线备份还原后，用归档日志 db2 rollforward db ... to end of logs and complete 滚到故障前一刻——DB2 恢复的主流程，前提是从备份点开始的日志链完整。表空间级恢复：整库太大只救单个表空间，restore tablespace + rollforward tablespace，效率高。误删表恢复：开了 DROPPED TABLE RECOVERY 的库，被 drop 的表会留在回收历史里，可用 RECOVER TABLE ... TO END OF LOGS 把表结构连同数据从日志里"重放"出来——DB2 独有的强项，很多误删表案不用备份就能救。页级抢救：db2dart 做页诊断和修复、按 extent 检查容器映射，配合单页导出抢救还能读的页面。

DB2 恢复的难点

日志链连续性：rollforward 差一环就停，归档日志散在多个目录、备份带、带库里是常态，凑齐链条本身就是工程。容器映射：表空间重定向恢复（redirected restore）里容器路径、大小、文件系统的映射关系重建，错一个就报错重来。db2dart 级别的底层诊断：无备份无日志的场景要进页结构做取证式抢救，工具原生、文档稀少，全靠经验。版本矩阵：v9.7/10.1/10.5/11.1/11.5 之间备份不可乱用，编码、地域代码页不一致还会把数据读出乱码。分布式环境：DPF 多分区和 pureScale 集群的恢复，节点间一致性校验复杂。

补天时代在 DB2 恢复上的优势

承接过金融、保险行业的 DB2 生产库抢救，熟悉 v9.7 到 11.5 的完整版本矩阵和跨版本迁移恢复；日志链拼凑、表空间重定向、db2dart 底层页修复是常规操作；误删表走 RECOVER TABLE 通道的成功率高于行业均值。评估时明确告知：有备份+日志链走前滚，无备份走页级取证，两条路线的成功率与工期一次讲清，不成功分文不收。