简介：这份文档面向需要实施DB2数据库异机恢复的DBA与备份运维人员，围绕NetBackup环境下的DB2备份恢复流程展开。内容涵盖DB2 Agent配置、用户出口程序db2uext2部署、userexit与logretain等参数调整，以及增量备份所需的trackmod设置；同时讲解db2_backup脚本中客户端、服务器、策略、计划与全量、累积、差异备份变量的含义，并说明db2.conf里数据库与归档日志备份策略、ARCFUNC和RETDIR的配置方法。压缩包仅含1个doc文件，约314KB，篇幅紧凑，适合按要点查阅。已有340人学习，可作为异机恢复前的配置核对清单与排错参考。
1. 异机恢复不是“换个机器 restore”：一次日志接不上的现场
“DB2 异机恢复”这几个字，多数人是被事故推进门里的：原库所在的机器还能开机但盘已经不稳，手上只有 NBU 里那几份备份和一台配置相近的备用机。此时最反直觉的一点是——备份成功不等于能恢复，能恢复也不等于能在这台新机器上恢复。异机恢复要在 Master Server 上开一个开关、在 db2.conf 里补一行源客户端名、在 restore 时补to或into，缺一个就是具体的 SQL 错误码。这篇把 DB2 + NBU 这条链路从 Agent 配置、日志参数、备份脚本、db2.conf 一路拆到 restore 与 rollforward 的完整命令，适合正在做恢复演练或救急的 DBA 与备份中控工程师照着走。
2. 备份侧先把地基打好：Agent 配置与三个日志参数的先后顺序
备份侧的问题往往在半年后才暴露，而且全部堆在恢复那一步。异机恢复能不能成，80% 取决于当初备份时日志归档链路有没有真正跑通，而不是恢复时那几条命令敲得漂不漂亮。所以先把备份侧拆开看。
2.1 db2_config 做了什么：db2uext2 必须落到 sqllib/adm
DB2 的 Agent 装完之后，不做这一步，后面的userexit on就是给自己挖坑。Agent 安装程序会在 NBU 的 bin 目录下留一个db2_config脚本，它的作用是把你实例环境里的用户出口程序配好，核心动作只有一个：把 NBU 提供的db2uext2复制到<db2instance>/sqllib/adm下，并且赋予执行权限。
# 以 DB2 实例用户身份执行，脚本是交互式的，会问你实例名、安装路径 /usr/openv/netbackup/bin/db2_config # 在 DB2 一侧确认落位结果 ls -l $HOME/sqllib/adm/db2uext2 # 期望：-r-xr-xr-x 属主为实例用户，大小非 0 # 顺手确认 NBU 侧的库文件和脚本模板是否都在 ls -l /usr/openv/netbackup/bin/nbdb2.so* ls -l /usr/openv/netbackup/bin/db2_backup这段命令的逻辑很直白：db2_config负责搬运，ls负责验收。db2uext2是 DB2 需要归档日志时回调的那个程序，DB2 不知道 NBU 的存在，它只会执行这个出口程序；出口程序再通过 NBU 的 user-exit 接口把日志推给 Master Server 上的存储单元。这个文件缺失或者不可执行，现象是userexit on之后归档日志一直堆在 ACTIVELOG 目录里不消失，直到日志目录写满、数据库挂起。
参数上要注意两点：一是nbdb2.so与nbdb2.so64的区别，32 位实例对应前者、64 位实例对应后者，AIX/HPUX 上则是.sl和.sl64，选错了备份和恢复都会报库加载失败；二是执行db2_config必须用实例用户，不要用 root 跑完再把文件 chown 过去，权限链容易出问题。脚本跑完会顺带生成备份脚本模板，后面第 2.3 节就是在它基础上改。
提示：
db2_config在生产上不要重复乱跑，它可能会覆盖你改过的脚本模板。改过的db2_backup单独备份一份，放在实例用户可读的目录里。
2.2 userexit、logretain、trackmod：三个参数的顺序与生效条件
这三个参数是最容易“改完以为生效了”的地方。先说结论：userexit和logretain决定日志往哪里去，trackmod决定能不能做增量备份，三个参数改完都必须满足“没有应用连接”这一条，否则 DB2 只会记下变更请求，等你下次重新激活数据库时才真正切过去。
su - db2inst1 # 1) 断开所有连接，否则参数变更不会立即生效 db2 force applications all db2 list applications for db APP_DB show detail # 确认已清空 # 2) 日志归档：userexit 走用户出口，logretain 打开归档日志模式 db2 update db cfg for APP_DB using userexit on db2 update db cfg for APP_DB using logretain on # 3) 增量备份开关 db2 update db cfg for APP_DB using trackmod yes # 4) 校验实际值 db2 get db cfg for APP_DB | grep -Ei 'userexit|logretain|trackmod|logarchmeth|log path' # 5) 改完必须做一次全备，否则库处于 backup pending，应用连不上 db2 backup db APP_DB to /tmp逻辑说明：force applications all是为了让参数变更立即落地，这一步不做，get db cfg里可能已经显示 on，但数据库还在用旧的循环日志模式跑，属于典型的“看着生效其实没生效”。第 5 步的全备份不是可选项——trackmod yes一旦生效，数据库立即进入备份挂起状态，此时任何应用连接都会拿到 SQL1116N，这不是故障，是 DB2 在等你做基线全备。
参数含义与后果对照：
| 参数 | 取值 | 作用 | 改完不做的后果 |
|---|---|---|---|
userexit | on / off | 启用用户出口程序归档日志，日志交给db2uext2再进 NBU | 归档日志堆积在 ACTIVELOG，日志满后库挂起 |
logretain | on / off | 打开归档日志模式，保留日志用于前滚 | 只能恢复到最近一次全备的时间点，做不了 point-in-time |
trackmod | yes / no | 记录页级变更，允许增量备份 | 增量备份直接报错，只能全备 |
还有一个顺序问题：先userexit on再logretain on，或者反过来，结果一样，但两次变更之间如果插入了应用连接，第二次变更就会排队不生效。实操上我一般把三条 update 连着敲完，中间不切窗口，然后一次性 force 一次、做一次全备。
2.3 db2_backup 脚本：变量、库文件与返回码
NBU 的 DB2 备份不是自己拼db2 backup命令，而是通过 bphdb 调用一个 shell 脚本，把本次作业的类型通过环境变量传进来，脚本再决定拼全备还是增量。这个脚本默认叫db2_backup，Agent 安装时会生成模板，需要按环境改三处：库文件路径、实例名/库名、实例用户。
#!/bin/sh # 由 NetBackup 的 bphdb 调用，环境变量已由上层注入 echo "DB2_CLIENT = $DB2_CLIENT" echo "DB2_SERVER = $DB2_SERVER" echo "DB2_POLICY = $DB2_POLICY" echo "DB2_SCHED = $DB2_SCHED" echo "DB2_FULL = $DB2_FULL" # 1 表示全备 echo "DB2_CINC = $DB2_CINC" # 1 表示累积增量 echo "DB2_INCR = $DB2_INCR" # 1 表示差异增量 # 厂商库：Linux 64 位用 nbdb2.so64，32 位用 nbdb2.so MY_LIB=/usr/openv/netbackup/bin/nbdb2.so64 MY_USER=db2inst1 # 作业类型到 DB2 关键字的映射，注意第三个分支不能留空 if [ "$DB2_FULL" = "1" ] ; then MY_SCHED="" elif [ "$DB2_CINC" = "1" ] ; then MY_SCHED="INCREMENTAL" elif [ "$DB2_INCR" = "1" ] ; then MY_SCHED="INCREMENTAL DELTA" else MY_SCHED="" fi RC=0 for MY_DB2 in APP_DB DWDB ; do CMD_LINE="db2 BACKUP DATABASE $MY_DB2 ONLINE $MY_SCHED LOAD $MY_LIB" echo "Executing: $CMD_LINE" su - $MY_USER -c ". ~/sqllib/db2profile; $CMD_LINE" if [ $? -ne 0 ] ; then RC=1 fi done exit $RC逻辑说明：上层通过DB2_FULL/DB2_CINC/DB2_INCR三个互斥变量告诉脚本本次是哪种备份，脚本翻译成 DB2 的INCREMENTAL和INCREMENTAL DELTA关键字。原始模板里elif [ "$DB2_INCR" = "1" ]后面是空分支，差异增量作业跑起来会退化成一次全备或者直接失败，这个坑值得单独提一句。
参数说明：ONLINE表示在线备份，要求数据库已经是归档日志模式（也就是第 2.2 节那两个参数已打开）；LOAD $MY_LIB告诉 DB2 走厂商库而不是写本地磁盘，这个关键字不能换成TO，写成TO /usr/openv/...会直接报路径不可写；su - $MY_USER -c里的-会重新加载登录环境，但不同发行版的实例 profile 不一定自动 sourcedb2profile，所以命令里显式加. ~/sqllib/db2profile;，能省掉一大类db2: command not found。
返回码这一段是血泪经验：多库备份时不要exit $?直接退出，第一个库成功、第二个库失败，脚本返回 0，NBU 控制台上显示作业绿色，半年后恢复才发现第二个库压根没备上。用RC累计，任一库失败就返回非 0，作业才会在 NBU 里标红。
2.4 策略与 Schedule 类型：DB2 策略加 Standard 日志策略
脚本写好只是客户端侧的事，服务端还要建策略。DB2 的备份策略类型选DB2，归档日志单独建一条Standard类型的策略——这一点常被忽略，因为日志不走 DB2 策略，走的是标准文件备份通道。
建策略的步骤：
- 在管理控制台展开 NetBackup Management → Policies，新建策略，名称按“库名 + 频率 + 介质”命名，便于后续 bplist 排查。
- Policy type 选
DB2，指定 Storage unit 与 Volume pool。 - Clients 页填入 DB2 主机名，必须与
db2.conf里的CLIENT_NAME、以及bplist -C用的名字完全一致。 - Backup Selections 页填入脚本绝对路径，例如
/usr/openv/netbackup/bin/db2_backup。 - Schedules 页按需建三种：
Automatic Full Backup、Automatic Cumulative Incremental Backup、Automatic Differential Incremental Backup，各自配 Start Window 与 Retention。 - 再建一条
Standard策略，Schedule 类型选User Backup或对应的用户归档类型，用于接收归档日志。
Schedule 类型与脚本里环境变量的对应关系要记住，排查时靠它判断作业到底跑了什么：
| Schedule 类型 | 脚本收到的变量 | 实际执行的 DB2 命令片段 |
|---|---|---|
| Automatic Full Backup | DB2_FULL=1 | db2 backup db ... online load ... |
| Automatic Cumulative Incremental Backup | DB2_CINC=1 | ... online incremental load ... |
| Automatic Differential Incremental Backup | DB2_INCR=1 | ... online incremental delta load ... |
| Default-Application-Backup | 用户手动触发 | 由命令行直接调用脚本 |
在线备份的场景下，归档日志策略必须先于数据库策略存在，否则第一次日志切换就会因为找不到可用的日志策略而卡住。常见做法是先建 Standard 日志策略、手工触发一次日志归档验证通过，再建 DB2 策略跑第一次全备。顺序反过来也能成，但排查时你分不清是库的问题还是策略的问题。
3. db2.conf 的写法：两段 OPER 块与异机恢复才需要的 CLIENT_NAME
db2.conf是整条链路里最不起眼、又最容易写错的文件。它不属于 DB2，属于 NBU 的 DB2 客户端，由db2uext2和备份脚本共同读取。文件里用OPER分隔成若干段，每段描述“某个数据库的某类对象，走哪个策略、哪个 Schedule”。同机恢复时它几乎不用动；异机恢复时，成败就在那几行。
3.1 DATABASE 段：OBJECTTYPE、POLICY、SCHEDULE 的对应关系
先看数据库备份这一段，四行核心配置，每一行都要和 Master Server 上的策略严格对齐。
# 数据库备份段：描述“备份/恢复这个库时，去哪个策略里找镜像” DATABASE APP_DB OBJECTTYPE DATABASE POLICY DB2_Backup SCHEDULE Default-Application-Backup ENDOPER逻辑说明：DATABASE指定库名，一个主机上多个库就写多段；OBJECTTYPE DATABASE表示这段描述的是数据库备份对象，与后面的OBJECTTYPE ARCHIVE区分；POLICY必须是 Master Server 上真实存在且类型为 DB2 的策略名；SCHEDULE必须是该策略下真实存在的 Schedule 名。
参数上最容易被忽略的是DATABASE的省略语义。这个字段在备份时不是必选项，省略表示“匹配本机所有数据库”，恢复时省略则表示“任意库名都套用这段配置”。单库环境省略没问题，多库环境省略会埋雷：恢复 A 库时，配置可能匹配到 B 库的策略上，报出来的错误是策略不存在或者镜像找不到，排查方向完全被带偏。我的习惯是无论单库多库，一律显式写库名。
POLICY和SCHEDULE的对应关系还有一层：恢复时 NBU 是按“策略 + Schedule + 客户端 + 时间戳”四元组去定位镜像的。备份时用的是哪个 Schedule，恢复时db2.conf里就要写哪个 Schedule，写错了不是报“找不到备份”，而是报一个更含糊的返回码，看日志才能发现是 Schedule 不匹配。
3.2 ARCHIVE 段：ARCFUNC SAVE 与 COPY 的选择
归档日志那一段决定前滚能不能做成。前滚需要日志，日志要么在带库上，要么在本地目录里，ARCFUNC就是选这个的。
# 归档日志段：决定日志推到 NBU 还是落在本地目录 DATABASE APP_DB OBJECTTYPE ARCHIVE POLICY DB2_Log SCHEDULE UserBackup ARCFUNC SAVE #ARCFUNC COPY #ARCDIR /db2/APP_DB/arcdir #RETDIR /db2/APP_DB/arcdir ENDOPER逻辑说明：ARCFUNC SAVE表示日志通过 NBU 归档到存储单元，恢复时也从 NBU 取回，这是异机恢复必须选的模式；ARCFUNC COPY表示日志只复制到本地目录，由ARCDIR指定目标、RETDIR指定恢复时的源目录，这种模式在异机恢复里基本没用，因为目标机上根本没有那份本地目录。
参数说明：POLICY这里对应的是 Standard 类型的日志策略，不是 DB2 策略，写错类型会在日志归档时直接失败；SCHEDULE对应日志策略下的用户备份 Schedule。选COPY的时候ARCDIR与RETDIR才生效，选SAVE时这两行注释掉即可，留着不影响但容易误导后来人。
一个实际取舍：本地盘够大、RTO 要求极短的场景，有人会同时配SAVE和定期把日志COPY到本地做双份，前滚时优先读本地、缺失再回 NBU。这个做法在恢复演练里确实快，但要注意本地目录的清理策略，别让日志把数据盘撑满——这是另一个方向的翻车。
3.3 异机开关：No.Restrictions 与 CLIENT_NAME
同机恢复不需要任何额外配置，异机恢复需要两处同时放开，缺一处就报未授权。
第一处是 Master Server 上的授权文件。默认情况下 NBU 只允许备份源主机自己发起恢复，跨主机恢复要被显式放行：
# 方式一：放开全部（演练环境图省事，生产慎用） touch /usr/openv/netbackup/db/altnames/No.Restrictions chmod 644 /usr/openv/netbackup/db/altnames/No.Restrictions # 方式二：精确授权，文件名是源客户端，内容里写允许的目标客户端 echo "nbk-tgt02" > /usr/openv/netbackup/db/altnames/nbk-src01 chmod 644 /usr/openv/netbackup/db/altnames/nbk-src01逻辑说明：altnames目录下的文件是 NBU 判断“能不能换机器恢复”的依据。No.Restrictions是个空文件，存在即代表不限制；第二种写法更细，文件名写备份源客户端名，文件内容一行一个允许恢复到的目标客户端名。演练环境用第一种省事，生产上按库、按主机逐个授权，出事时能查出是谁放开的。
第二处是目标机上的db2.conf，两段 OPER 里都要加CLIENT_NAME，指向备份源客户端，而不是本机：
DATABASE APP_DB OBJECTTYPE DATABASE POLICY DB2_Backup SCHEDULE Default-Application-Backup CLIENT_NAME nbk-src01 ENDOPER DATABASE APP_DB OBJECTTYPE ARCHIVE POLICY DB2_Log SCHEDULE UserBackup CLIENT_NAME nbk-src01 ARCFUNC SAVE ENDOPER逻辑说明：不加CLIENT_NAME，NBU 会拿本机名去匹配镜像，结果当然是找不到——因为镜像属于源客户端。加上之后，restore 和前滚取日志都会去源客户端的镜像集合里找。数据库段和归档段都要加，只加一段的典型现象是 restore 成功、前滚卡住。
3.4 改完 conf 怎么验证生效
改完别急着敲 restore，先做两件低成本验证。
# 1) 权限与语法：实例用户必须能读，文件里不能有多余的空白行打乱 OPER 配对 ls -l /usr/openv/netbackup/db2.conf grep -c '^ENDOPER' /usr/openv/netbackup/db2.conf # 段数应与 DATABASE 段数一致 # 2) 从目标机用源客户端名查镜像，能列出来说明授权和命名都通了 /usr/openv/netbackup/bin/bplist -C nbk-src01 -t 18 -R -l /逻辑说明：第一条查文件可读性和 OPER 配对，ENDOPER数量少于DATABASE数量说明有段落没闭合，这种错误在 restore 时的表现是“配置解析失败”，报错信息不会告诉你少了个 ENDOPER。第二条是真正的连通性测试：从目标机执行bplist -C 源客户端名，能列出镜像路径说明 Master 的授权、网络、客户端名大小写全对；列不出来，问题一定在altnames或CLIENT_NAME上，此时不必往 restore 那里走。
4. restore 与 rollforward 的完整走法：离线、在线、到点三类场景
恢复侧要分清三种情况：离线备份恢复到最新、在线备份恢复到最新、在线备份恢复到某个时间点。三者的命令骨架一样，差别在without rolling forward加不加、taken at带不带、后面跟不跟rollforward。
4.1 先定位备份镜像：bplist 的正确用法
不知道有哪些镜像就敲 restore，等于闭眼抽奖。DB2 备份在 NBU 里的镜像类型是 18，用bplist按客户端和时间范围列出来：
# 列源客户端所有 DB2 备份镜像 /usr/openv/netbackup/bin/bplist -C nbk-src01 -t 18 -R -l / # 只列某个时间段，缩小范围 /usr/openv/netbackup/bin/bplist -C nbk-src01 -t 18 -R -l -s 02/01/2025 -e 03/01/2025 /逻辑说明：-C是客户端名，必须和db2.conf里的CLIENT_NAME一字不差；-t 18是 DB2 的备份镜像类型，不加这个参数会混进文件备份的镜像；-R递归列目录；-l长格式带上时间与大小。
输出里那串路径是有信息量的，典型形态是/DB2/APP_DB/node0000/20250226120711/APP_DB.0.db2inst1.node0000.642.20250226120711.4。中间那段 14 位数字就是taken at要用的时间戳，前面的APP_DB是库名，后面的数字是镜像分段序号——一个大库切成多段，恢复时缺一段就前滚不了。恢复前把目标时间点的镜像段数数清楚，是个好习惯。
4.2 离线备份的恢复：without rolling forward 为什么必须加
离线备份（备份时数据库没有连接）本身是一致的，恢复完直接可用，不需要前滚。但 DB2 不知道你恢复的是离线还是在线镜像，默认行为是恢复完把库置为前滚挂起状态。所以要显式告诉它“别前滚”。
su - db2inst1 # 恢复到最新一份离线备份 db2 restore db APP_DB load /usr/openv/netbackup/bin/nbdb2.so64 \ without rolling forward without prompting # 恢复到指定版本 db2 restore db APP_DB load /usr/openv/netbackup/bin/nbdb2.so64 \ taken at 20250226120711 without rolling forward without prompting # 目标机上库不存在时，必须指定新路径 db2 restore db APP_DB load /usr/openv/netbackup/bin/nbdb2.so64 \ to /db2data/APP_DB without rolling forward without prompting逻辑说明：load后面跟厂商库绝对路径，表示数据从 NBU 读，不能写成from；taken at后面是 14 位数字时间戳，来自bplist输出；without rolling forward抑制恢复后的前滚挂起；without prompting抑制交互确认，作业化脚本里必须加，否则命令会卡在等待输入上。
参数取舍：to只在目标机路径与备份源路径不一致时才需要。异机恢复的路径几乎一定不一致，所以这条基本是必加项。不加的表现是恢复直接失败，报容器路径不可用；有时候目标机恰好有同名路径但空间不够，恢复跑到一半失败，反而更麻烦——先确认目标路径的剩余空间，再敲命令。
4.3 在线备份的恢复：restore 之后必须 rollforward
在线备份期间数据库有写入，镜像本身不一致，恢复完必须用归档日志前滚到某个一致点。少了rollforward，数据库永远打不开。
su - db2inst1 # 第一步：恢复最近的在线镜像，不加 without rolling forward db2 restore db APP_DB load /usr/openv/netbackup/bin/nbdb2.so64 without prompting # 第二步：确认处于前滚挂起状态 db2 rollforward db APP_DB query status # 第三步：前滚到日志末尾并结束 db2 rollforward db APP_DB to end of logs and complete # 恢复到指定时间点 db2 restore db APP_DB load /usr/openv/netbackup/bin/nbdb2.so64 \ taken at 20250226120711 without prompting db2 rollforward db APP_DB to 2025-02-26-12.07.11 using local time and complete逻辑说明：rollforward query status是恢复过程中最有价值的一条命令，它会告诉你当前库是不是处于前滚挂起、已经前滚到哪个日志点、还需要多少日志。第三步的to end of logs and complete表示一路前滚到日志尽头并结束前滚，库恢复可连接状态。
参数说明：时间点前滚的时间格式是YYYY-MM-DD-HH.MM.SS，注意小时与分钟之间是点不是冒号，写冒号在部分版本上直接语法错误；using local time表示按本地时区解释这个时间，有些版本没有这个选项，那就得手动把系统时区差算进去——操作系统时间与标准时间有偏差时，你要填的时间 = 目标时间 ± 时差，这一步算错，前滚会“成功”但数据停在错误的时间点，比失败更难发现。
前滚还有个中间态值得知道：to end of logs and stop表示前滚到日志末尾但保持挂起，用于还需要继续应用日志或者做检查的场景，检查完再执行rollforward db APP_DB complete收尾。演练环境里我常用and stop停一下，先做一致性检查再决定要不要 complete。
4.4 异机改路径与改名：to、into 与 redirect 脚本
异机恢复真正的难点不是“恢复”，是“恢复到一个库名不同、表空间容器路径也不同的环境”。表空间容器路径写在镜像里，直接恢复到新主机大概率因为路径不存在而失败。这时候要用重定向恢复。
# 生成重定向脚本，不真正执行恢复 db2 restore db APP_DB load /usr/openv/netbackup/bin/nbdb2.so64 \ taken at 20250226120711 into APP_DB_RST \ redirect generate script /tmp/rst_APP_DB.sql without prompting # 编辑脚本，改表空间容器路径与日志路径 # SET TABLESPACE CONTAINERS FOR 3 USING (PATH "/db2data/APP_DB_RST/ts1") # SET TABLESPACE CONTAINERS FOR 4 USING (PATH "/db2data/APP_DB_RST/ts2") # 执行脚本，再前滚 db2 -tvf /tmp/rst_APP_DB.sql db2 rollforward db APP_DB_RST to end of logs and complete逻辑说明：into APP_DB_RST让恢复落到一个新库名上，源库不受影响；redirect generate script让 DB2 只生成 SQL 脚本不执行，脚本里包含 restore 语句和SET TABLESPACE CONTAINERS语句，你把路径改成目标机真实存在的目录，再整体执行。表空间编号从db2 list tablespaces show detail里查，不要凭记忆写。
参数说明：redirect与前滚是配合关系，重定向恢复后库同样处于前滚挂起，必须rollforward ... complete；into要求目标库名在实例里不存在，存在就先db2 drop db，但生产上别随手 drop，先确认那不是一个还在用的库。这套流程走下来，一次典型的跨机恢复大概 20 分钟，其中 15 分钟花在确认路径和权限上——这才是异机恢复的真实耗时分布。
5. 避坑清单：五条从现场抄回来的排查记录
以下五条都是能复现的，写的时候尽量保留原始报错特征，方便对号入座。
5.1 应用连不上库，报 SQL1116N
现象：改完trackmod yes之后，应用立刻大面积报错，连接数据库时返回 SQL1116N，提示数据库处于备份挂起状态。
原因：trackmod打开后 DB2 要求有一次基线全备，在完成之前数据库不允许新的连接。很多人以为参数改完就完事，跳过了全备这一步。
解决：立刻执行一次全备，db2 backup db APP_DB to /tmp或者走 NBU 脚本，备份完成挂起状态自动解除。如果磁盘紧张，用db2 backup db APP_DB to /dev/null也能解除，但这样就没有基线镜像，后续增量备份不可用，只适合演练环境救急。
5.2 归档日志不消失，ACTIVELOG 越堆越大
现象：userexit已经是 on，但归档日志一直留在 ACTIVELOG 目录，日志目录写满后库挂起。
原因：三个常见来源——db2uext2没复制到sqllib/adm；db2.conf的 ARCHIVE 段策略名或 Schedule 写错，出口程序调用失败；参数修改时还有应用连接，变更没真正生效。
解决：先ls -l $HOME/sqllib/adm/db2uext2确认文件在且可执行；再手工触发一次日志归档看返回信息；最后db2 get db cfg确认参数值并检查是否有残留连接。三步走完基本能定位。
5.3 restore 报库加载失败，提示无法加载厂商库
现象：db2 restore db ... load /usr/openv/netbackup/bin/nbdb2.so64直接失败，报无法加载指定库。
原因：32 位实例用了 64 位库，或者反过来；也可能是库文件权限不对，实例用户没有执行权限。
解决：先确认实例位数，再选对应的nbdb2.so/nbdb2.so64；然后ls -l看权限。顺带说一句，db2.conf本身也要求实例用户可读，权限 600 且属主是 root 时，restore 阶段的报错同样指向库加载，方向容易被带偏。
5.4 异机恢复报未授权，换机被拒
现象：源机上同样的命令能恢复，目标机上执行直接报未授权或找不到镜像。
原因：Master Server 上没建altnames授权文件，或者db2.conf里没加CLIENT_NAME，NBU 认为你在恢复别人的备份。
解决：按第 3.3 节建授权文件，两段 OPER 都补CLIENT_NAME，然后用bplist -C 源客户端名从目标机验证。能列出镜像再敲 restore，别在 restore 里反复试。
5.5 前滚到一半日志链断，报 SQL4970N
现象：restore 成功，rollforward to end of logs报日志链中断，无法到达指定时间点。
原因：时间窗内的归档日志没有全部备份到 NBU，通常是日志策略的 Start Window 有空档，或者某天作业失败没人跟进；也可能是ARCFUNC COPY模式下的本地目录被清理过；还有一种是前滚时间戳格式写错（冒号写成了 DB2 不认的格式），报错信息看起来像日志缺失。
解决：先看rollforward query status给出的已到达日志点，与目标时间比对，判断缺的是哪一段；再用bplist按时间范围查该时段的归档日志镜像是否存在。确认日志缺失的话，只能前滚到最近的可用点，接受数据损失——这也说明日志备份作业的告警不能关。
6. 把恢复做成可演练的动作：验收项与一个好用的兜底脚本
恢复命令跑完不等于交付。数据库能连、表能查、索引没坏、序列没回退，这几项才算过线。我一般按下面这张表逐项打勾，任何一项不过就不宣布恢复完成。
| 检查项 | 命令 | 通过标准 |
|---|---|---|
| 库状态 | db2 list db directory/db2 connect to APP_DB | 能连接，无前滚挂起 |
| 表空间 | db2 list tablespaces show detail | State 为 0x0000，无 quiesce |
| 对象数量 | db2 "select count(*) from syscat.tables where tabschema not like 'SYS%'" | 与源库同量级 |
| 索引有效性 | db2rbind APP_DB -l /tmp/rbind.log all | 日志中无失败条目 |
| 统计信息 | db2 "call sysproc.admin_cmd('RUNSTATS ON DATABASE')" | 执行成功 |
| 页一致性 | 停库后db2dart APP_DB /CHK | 无错误页报告 |
前五项在线可做，最后一项要停库，放在窗口末尾执行。db2dart这一条在恢复演练里价值很高，它查的是页级物理一致性，比应用层跑几条 SQL 更能说明问题。
恢复后的自检，我习惯用一个小脚本串起来，避免手工漏项：
#!/bin/bash # 用法：./post_restore_check.sh APP_DB DB=$1 su - db2inst1 -c " . ~/sqllib/db2profile db2 connect to $DB > /dev/null || { echo 'FAIL: connect'; exit 1; } echo '--- tablespaces ---' db2 list tablespaces show detail | grep -E 'Name|State' echo '--- user tables ---' db2 \"select count(*) from syscat.tables where tabschema not like 'SYS%'\" echo '--- rollforward status ---' db2 rollforward db $DB query status db2 terminate "逻辑说明：连接失败直接退出，避免后续命令在无连接状态下输出一堆误导信息；表空间状态是恢复后最容易出问题的地方；用户表数量用来快速判断是不是恢复到了一个很老的版本；rollforward query status确认没有残留挂起。这个脚本不能替代完整验收，但能在恢复完成后三十秒内告诉你“要不要往下走”。
最后一个技巧，也是踩过坑之后才养成的习惯：每次恢复前，先把bplist的输出重定向存一份到/tmp/restore_$(date +%Y%m%d%H%M).log。当时是为了留证据，后来发现它真正的价值是——恢复失败时，你能立刻确认“是镜像本身不完整”还是“命令参数写错了”，这两个方向的排查成本差一个数量级。从那以后我每次异机恢复都强制走一遍这个留存动作，连同db2.conf一起打包放进工单附件，事后复盘不用再靠回忆。希望帮到你。
本文还有配套的精品资源，点击获取
