前两天有个朋友半夜给我打电话，说他刚把 DB2 数据库的一个表空间搞崩了，数据全写乱了，问我怎么恢复。电话那头的声音都带着哭腔，甚至连备份放哪儿都不知道。我一边骂他手贱，一边让他先别慌，把日志文件路径发给我。其实很多人对 DB2 恢复命令的理解，还停留在“run a backup, do a restore”这个层面，真遇上事了，连 和 的区别都说不清楚。今天索性把这件事掰开揉碎，聊一聊从最基础的命令到实战坑点，全部给你倒出来。
先说最基础也是最核心的命令：。这条命令的作用是把备份文件里保存的数据块，原封不动地写回数据库文件里。比如你有个全量备份放在 目录下，跑一句 就行。注意 参数后面跟的是备份的时间戳，而不是随便写的日期。很多人第一次用时，以为 是备份文件名里的时间，结果写成了 这种格式，DB2 直接报错不认。正确格式是连续数字 ，没有分隔符。还有个常见坑是恢复路径，默认情况下 DB2 会把数据恢复到备份时所在的路径。如果你换了磁盘或改过目录，就需要加 参数指定新路径，否则恢复后数据库启动不了。
光恢复数据库还不够，生产环境下通常还要执行 。这个命令的作用是把归档日志里记录的事务重放到指定的恢复时间点。比如你凌晨 2 点做了全量备份，下午 4 点数据库崩了，只恢复备份的话，数据只能到 2 点，之间 14 小时的业务数据全丢了。这时需要先 ，再 到 4 点之前。命令大致是：。这里最烦的是时间格式，必须使用 这种带点和短横的格式，而且 表示恢复到指定时间点后自动停止。如果不写 ，它默认进入 状态，数据库仍然连不上，需要再跑一次 手动结束。
说到恢复策略，很多人以为有全量备份就万事大吉。实际上全量备份的频率往往是一天一次甚至一周一次，期间产生的数据只能靠增量备份和归档日志来补。DB2 的增量备份分两种： 和 。 是累积式，只备份上一次全量备份之后变动的数据页； 是差异式，只备份上一次任何备份之后变动的数据页。恢复时，如果只有全量加增量，就必须先恢复全量，再依次恢复每个增量备份，才能 。顺序不能乱，否则数据页会错位。我见过一个案例，运维同事图省事，把增量备份当成全量来恢复，结果数据库能启动，但查询出来的数据全是乱的，客户直接投诉到老板。
还有一个容易被忽视的命令是 ，主要用于表空间重定向恢复。什么意思呢？就是备份时的磁盘是 100 GB，但新服务器只有 80 GB，或者想把数据文件分散到不同磁盘上。这时直接 肯定报空间不足，必须先用 模式恢复元数据，然后手动重新定义每个表空间的容器路径。大致流程是：，接着用 挨个指定新路径，最后执行 完成恢复。这一步最考验耐心，因为生产库的表空间可能有几十个，需要一个一个配，配错了恢复后数据库都起不来。
聊完命令，来看看实战中容易翻车的点。第一是日志文件不完整。很多人在恢复完数据库后开始 ，结果报错提示某个日志文件找不到。通常是归档日志被删了或没备份。解决办法是加 参数，指向日志的备用目录。如果日志真的丢了，只能加 参数，直接恢复到备份时间点，但会丢失之后的所有数据。第二个坑是版本不兼容。DB2 的备份文件只能恢复到同版本或更高版本的实例上，例如 10.5 的备份不能恢复到 10.1 的实例，反之可以。跨版本恢复时，还得先 再运行 命令升级数据库结构。第三个坑是表空间状态。恢复完成后，有时某些表空间会处于 状态，必须手动跑一次全量备份才能解除，否则数据库只能以只读模式运行。
说到这里，你可能觉得 DB2 恢复命令挺繁琐。但它之所以设计成两步，是有逻辑支撑的。DB2 的恢复模型基于“先恢复数据文件，再重放日志”的步骤，目的是保证事务的原子性和持久性。 负责把数据文件恢复到某个时间点的静态快照， 则把快照之后的所有已提交事务应用到数据库里。这两步缺一不可，尤其在金融、电商等对数据一致性要求极高的场景下，少一个步骤就可能导致账目不平或订单丢失。
说点实在的。如果你现在负责维护 DB2 数据库，我建议你做三件事：第一，定期测试恢复流程。别光备份，备份文件能不能用、恢复出来的数据对不对，必须真跑一遍才知道。第二，把归档日志也备份，而且最好放在与全量备份不同的位置。日志丢了，恢复能力直接砍半。第三，写一个恢复脚本，把命令和参数固化下来，包括日志路径、时间格式、表空间重定向规则。真出事了，人一紧张、手一抖，参数写错一个，恢复时间可能多花好几个小时。DB2 恢复命令本身不复杂，复杂的是我们对数据的敬畏心。别等崩了再学，现在就把命令敲一遍，保存下来。
