DB2备份文件恢复失败求助：SQL2071N、SQL2079N错误排查

先理清楚你遇到的核心问题：在AIX 7.1 TL4环境下用DB2 9.7恢复备份时，接连碰到压缩库访问失败、初始化失败的错误，甚至用db2ckbkp检查备份也无法通过媒体头验证。结合你的环境信息和报错，我整理了具体的排查解决步骤，以及判断备份是否损坏的依据：

一、逐步排查解决压缩库相关错误 #

1. 先搞定压缩库的基础问题（权限、架构、完整性） #

第一个错误SQL2071N的原因码2，通常指向文件不存在、权限不足或者架构不匹配：

• 先确认目标实例用户db2inst3对报错路径里的libdb2compr.a有读权限，同时路径上的每一层目录都得有执行权限。可以用这两条命令快速验证：

  ls -l /resgrp463/db2inst3/db2inst3/NODE0000/SQL00001/4371/libdb2compr.a
  su - db2inst3 -c "test -r /resgrp463/db2inst3/db2inst3/NODE0000/SQL00001/4371/libdb2compr.a && echo '权限没问题'"
  

• AIX上DB2 9.7的压缩库分32位和64位，目标实例是64位的话，必须用sqllib/lib64/下的库，别混用32位版本。你后来指定的/resgrp463/db2inst1/sqllib/lib64/libdb2compr.a，要确认是DB2 9.7版本的，且和目标实例位数一致。
• 尽量用目标实例db2inst3自身的压缩库，避免跨实例调用。如果db2inst3的sqllib/lib64/libdb2compr.a不存在，说明你的DB2安装不完整，需要重新安装对应补丁包，确保压缩组件被正确部署。

2. 匹配源端DB2的补丁级别 #

SQL2079N返回码104大概率是压缩算法版本不兼容——源端备份用的DB2补丁比目标端高，目标端的压缩库无法解析源端的压缩格式：

• 你已经试过GA、FP1、FP11，建议直接升级到DB2 9.7的最新补丁（比如FP15，这是9.7的最后一个补丁包），后续补丁对压缩兼容性做了不少优化。
• 如果能联系到源端，最好把源端的libdb2compr.a复制到目标端对应路径（先备份目标端原库），替换后再尝试恢复，这样能保证压缩库版本完全匹配。

3. 调整恢复命令的细节 #

• 不要用from .，明确指定备份文件所在的绝对路径，避免当前目录解析出错。
• 加上without prompting参数跳过交互，防止隐性的配置或权限提示打断恢复流程：

  db2 restore db <db-name> from <备份文件绝对路径> taken at 20151229234633 comprlib /resgrp463/db2inst3/sqllib/lib64/libdb2compr.a without prompting
  

4. 深挖db2diag日志的细节 #

从你提供的日志里，重点关注这些内容：

• 是否有Could not load library或Symbol not found的信息，这能直接判断是库加载失败还是符号不兼容。
• 是否有备份文件校验和不匹配的报错，这能指向备份文件本身的损坏。

二、判断备份文件是否损坏的核心依据 #

如果出现以下情况，基本可以确定备份文件已经损坏：

1. db2ckbkp无法验证媒体头：你执行db2ckbkp *时报错Failed to verify media header，媒体头是备份文件的核心标识，连这个都验证不了，说明备份文件的头部已经损坏，DB2根本无法识别它。
2. 更换匹配库和补丁后仍报错：即使你用了和源端同版本的压缩库、升级到了最新补丁，db2ckbkp还是报错，恢复也失败，大概率是备份文件的压缩数据块已经损坏。
3. 源端验证也失败：如果能在源端用db2ckbkp检查这个备份文件，源端也报同样的错误，说明备份在生成时就已经损坏。
4. db2diag日志出现校验和不匹配：日志里如果有Checksum mismatch相关的错误，说明备份文件在传输或存储过程中数据被篡改。

内容的提问来源于stack exchange，提问作者Yuvraj Gupta