YOLOv5打电话行为检测实战：从数据集标注到PyQt界面部署
2026/10/11 20:42:51
简介：文档围绕DB2异机恢复场景展开，面向需要借助NetBackup实现数据库迁移与灾难恢复的DBA及运维工程师，重点解决备份后在异机重建DB2数据库的配置与实操问题。资源为doc格式，仅1个文件，压缩包314KB，内容精炼但覆盖完整。正文从DB2 Agent的配置入手，说明运行db2_config将用户出口程序db2uext2复制到实例目录，并开启userexit、logretain、trackmod三个参数以进入归档日志与增量备份模式；同时强调在线备份前需断开所有应用连接并先完成一次全备份。随后重点分析备份脚本db2_backup中的环境变量含义，以及db2.conf中对数据库备份和归档日志备份各自的策略设定，包括OBJECTTYPE、POLICY、SCHEDULE以及ARCFUNC、RETDIR等关键项，其中ARCFUNC用于指定归档日志保存方式，RETDIR用于设定保存目录，并给出可直接参考的示例配置。目前已有335人学习下载，适合作为DB2异机恢复从环境准备到策略落地的参考资料。
1. DB2 异机恢复：为什么备份能成功、恢复却总卡在 NBU 的身份校验上
DB2 异机恢复，通俗讲就是在一台新机器上，用 NetBackup 里已有的备份把源库完整还原出来。很多 DBA 的第一反应是「把备份文件拷过来再 db2 restore 不就行了」，真动手才发现，卡点几乎都不在 DB2 命令本身，而在 NBU 的客户端识别机制上：它默认不允许非源客户端发起恢复请求，这一条就能拦住绝大多数人。这份资源是一整套 NBU for DB2 的备份恢复操作手册，从 Agent 配置、DB2 参数调整、备份脚本、策略创建，到 offline/online 恢复和异机恢复全都覆盖了，正是生产环境里从零搭备份系统的完整路径。适合正在做 DB2 备份方案、或者手里有 NBU 备份但从没验证过异机恢复的运维和 DBA。即使你现在用的是 DB2 10.5 或 11.1，这套接入逻辑也基本没变。
我在实际项目里见过不少团队，同机恢复跑通了就以为万事大吉，直到机房迁移、备机接管那天才发现异机恢复根本没验证过。这类演练最好在备份系统上线时就完整走一遍，等真要用再排错，压力完全不同。下面按「配置 → 备份 → 恢复 → 异机 → 验证」的顺序，把每一步的命令和容易踩的坑都标出来。
2. 恢复前的两份关键配置：三个 DB2 参数与 db2.conf 的每一行
2.1 三个 DB2 参数：userexit、logretain、trackmod 为什么必须一起改
DB2 默认跑在循环日志模式下，日志写满就覆盖，这种模式只能做 offline 备份，更谈不上把归档日志送到 NBU。要做在线备份和可靠的日志归档，必须先把三个参数一起打开。很多人只改了 logretain，忘了 userexit，结果日志还是没进 NBU；或者只开前两个、没开 trackmod，等配增量备份策略时才发现数据库根本不支持。
db2 update db cfg for sample using userexit on db2 update db cfg for sample using logretain on db2 update db cfg for sample using trackmod yes db2 terminate这三行命令执行的顺序无所谓，但建议全部执行完以后跑一次db2 terminate，确保没有连接挂在上面。参数要等所有应用和连接都断开后才会真正写入配置文件并生效，这也是新手最容易忽略的：执行完命令马上查配置，发现还是 off，就以为命令写错了。
| 参数 | 默认值 | 作用 | 不开启的后果 |
|---|---|---|---|
| userexit | off | 启用用户出口程序，日志归档交给 NBU | 归档日志无法写入 NBU |
| logretain | off | 切换为归档日志模式 | 无法做 online 备份 |
| trackmod | off | 跟踪页级修改，支持增量备份 | 增量备份策略不可用 |
注意trackmod这个参数在多数 DB2 版本里接受的值是yes，写成on会直接报参数无效。改完参数后，必须对数据库做一次全备份，否则数据库会处于不可连接状态，这是归档日志模式切换的正常行为，不是故障。
2.2 db2_config 脚本与用户出口程序 db2uext2 的落位
Agent 装完后，NBU 会要求运行/usr/openv/netbackup/bin/db2_config，它的核心工作是把用户出口程序db2uext2复制到实例目录<db2instance>/sqllib/adm/下。DB2 的 userexit 机制就是靠这个可执行文件在日志归档和取回时被调用，没有它，logretain 和 userexit 开了也白开。
/usr/openv/netbackup/bin/db2_config ls -l $HOME/sqllib/adm/db2uext2如果机器上有多个 DB2 实例，建议在执行前先把DB2INSTANCE环境变量指到目标实例，否则 db2_config 可能把文件装到最后一个实例的目录下。跑完后确认db2uext2存在且带可执行权限，顺便看下db2.conf和db2_backup是否自动生成到了 NBU 的安装目录里，后面两节要改的就是这两个文件。
2.3 db2.conf 两段配置：DATABASE 段与 ARCHIVE 段的每一行含义
db2.conf 是 NBU 执行备份和恢复时读取的配置文件，内容分两段：DATABASE 段管数据库本身的备份与恢复，ARCHIVE 段管归档日志。每段都以DATABASE开头、ENDOPER结尾。异机恢复时，关键就在这两段里都要加一行CLIENT_NAME，这个问题后文会展开，这里先把结构说清楚。
DATABASE BI OBJECTTYPE DATABASE POLICY DB2_Backup SCHEDULE Default-Application-Backup CLIENT_NAME gdccas670 ENDOPER DATABASE BI OBJECTTYPE ARCHIVE POLICY User_Backup SCHEDULE UserBackup ARCFUNC SAVE CLIENT_NAME gdccas670 ENDOPER| 配置行 | 作用 | 常见错误 |
|---|---|---|
| DATABASE | 指定要恢复的数据库名 | 写成源库实例名 |
| OBJECTTYPE | DATABASE 或 ARCHIVE，区分备份对象 | 两段都写 DATABASE |
| POLICY | 对应 NBU 里创建的策略名 | ARCHIVE 段误用 DB2 类型策略 |
| SCHEDULE | 对应策略下的备份计划名 | 与策略不匹配 |
| ARCFUNC | SAVE 保存日志到 NBU；COPY 保存到本地目录 | 不写则日志不归档 |
| CLIENT_NAME | 指定源客户端主机名，异机恢复必填 | 漏写导致恢复找不到备份 |
ARCFUNC SAVE表示归档日志保存到 NBU 存储；COPY模式会把日志复制到ARCDIR指定目录。多数生产环境用 SAVE，日志直接进 NBU，异机恢复时才能从 NBU 取回。如果你用了ARCFUNC COPY且把ARCDIR和RETDIR写在注释状态，恢复时日志链路大概率是断的。
3. 备份侧落地：db2_backup 脚本改造与 NBU 策略创建
3.1 db2_backup 脚本：NBU 注入的环境变量决定备份类型
Agent 装好后会自动生成一个备份脚本db2_backup，NBU 的bphdb进程执行它时，会往环境变量里塞入DB2_FULL、DB2_CINC、DB2_INCR，值分别是 1 或 0。脚本靠这几个变量判断当前跑的是全备、累积增量还是差异增量。这几个变量的值由策略里的 Schedule 类型决定，不用手动改。
echo "DB2_FULL = $DB2_FULL" # 1 表示全备份 echo "DB2_CINC = $DB2_CINC" # 1 表示累积增量备份 echo "DB2_INCR = $DB2_INCR" # 1 表示差异增量备份脚本下发时，这些 echo 会写进 NBU 的任务日志。排错时先看任务日志里这几个变量的值，能快速判断是不是 Schedule 类型配错了。比如策略配的是全备份 Schedule，但日志里DB2_FULL=0，那问题一定出在策略与 Schedule 的对应关系上。
MY_LIB是另一个必须改的变量，它指定 NBU 提供的 vendor 库文件。不同平台、不同位数，库文件名完全不一样，选错会在备份命令执行时报“load library failed”。
| 平台 | 库文件名 |
|---|---|
| Solaris / Linux 32 位 | nbdb2.so |
| Solaris 64 位 | nbdb2.so64 |
| AIX / HP-UX 32 位 | nbdb2.sl |
| AIX / HP-UX 64 位 | nbdb2.sl64 |
3.2 按备份类型拼接 CMD_LINE：全备、增量与多数据库
脚本的核心逻辑是把 DB2 备份命令拼成一行，再以指定用户身份执行。这里给出一个改造后的骨架，我在生产环境里一般会保留原脚本结构，只改参数和追加数据库：
MY_LIB=/usr/openv/netbackup/bin/nbdb2.sl MY_DB2=DWDB MY_USER=dwccbxm if [ "$DB2_FULL" = "1" ]; then MY_SCHED="" elif [ "$DB2_CINC" = "1" ]; then MY_SCHED="INCREMENTAL" elif [ "$DB2_INCR" = "1" ]; then MY_SCHED="INCREMENTAL" else MY_SCHED="" fi CMD_LINE="db2 BACKUP DATABASE $MY_DB2 ONLINE $MY_SCHED LOAD $MY_LIB" echo "Executing: $CMD_LINE" su - $MY_USER -c "$CMD_LINE" RETURN_STATUS=$? exit $RETURN_STATUS逻辑说明：脚本根据 NBU 注入的三个环境变量，决定MY_SCHED是空还是INCREMENTAL。空字符串表示全备，INCREMENTAL表示增量备份。生成的CMD_LINE由db2 BACKUP DATABASE、库名、ONLINE、增量关键字和LOAD $MY_LIB组成，LOAD后面接的是 vendor 库路径，DB2 通过它把备份流写进 NBU。su - $MY_USER -c保证备份命令以 DB2 实例用户身份执行，避免权限问题。
参数说明：如果做 offline 备份，要删掉ONLINE关键字。$MY_USER必须有该数据库的 dbadm 或更高权限。同一脚本里要给多个库做备份，就多复制几行 CMD_LINE，逐个su执行，不要合并成一条命令，否则一个库失败会影响后面所有库。
3.3 NBU 策略创建：DB2 类型策略 + Standard 日志策略
备份脚本准备好后，要在 NetBackup Administration Console 里建策略。常规做法是：先建一个类型为 DB2 的策略，负责数据库备份；如果做在线备份，再建一个 Standard 类型的策略，负责归档日志备份。只有 DB2 策略而没有日志策略，日志不会自动进 NBU，在线恢复时日志链路是断的。
创建 DB2 策略的完整步骤是：右键 Policies 选择 New，输入策略名；Policy type 选 DB2；指定存储单元和卷池；Clients 里添加数据库主机；Backup Selections 里填 db2_backup 脚本的绝对路径，注意这里填的是脚本路径，不是数据库路径；最后在 Schedules 里创建备份计划。
Schedule 类型和备份动作的对应关系如下：
| Schedule 类型 | 对应备份 |
|---|---|
| Automatic Full Backup | 全备份 |
| Automatic Differential Incremental Backup | 差异增量备份 |
| Automatic Cumulative Incremental Backup | 累积增量备份 |
| User Backup | 手动触发，日志归档策略用 |
在线备份时另建的 Standard 策略，关键是 Schedules 里要配一个 User Backup 类型的计划，名字要和 db2.conf 的 ARCHIVE 段里SCHEDULE一致。这一步配错不会在备份时报错，而是在恢复时日志取不回来，属于典型的隐性坑。
4. 同机恢复先跑通：bplist 定位、restore 与 rollforward 的边界
4.1 用 bplist 定位备份版本：时间戳就是 restore 的 taken at 参数
恢复前第一件事是确认恢复哪个备份版本。NBU 的命令行工具bplist可以列出指定客户端、指定类型的所有备份记录，输出里那个长数字就是备份的精确时间点，后面 restore 命令直接用它做taken at参数。
bplist -C gdccas670 -t 18 -R //DB2/BI参数说明：-C指定源客户端主机名；-t 18表示按 DB2 备份类型过滤，18 是 NBU 对 DB2 备份的类型编码；-R是递归列出路径。输出里类似20050226120711的目录名就是备份时间戳，格式是年月日时分秒。如果输出为空，先确认策略类型是不是 DB2，再确认客户端名大小写，NBU 对主机名大小写敏感。
4.2 OFFLINE 备份恢复：without rolling forward 为什么不能省
Offline 备份得到的数据库文件本身是一致的，恢复后不需要做日志前滚。命令里必须带without rolling forward，告诉 DB2 这是完整还原，否则即使备份是一致的，DB2 也会进入 rollforward pending 状态，应用无法连接。
su - db2inst1 db2 restore db bi load /usr/openv/netbackup/bin/nbdb2.sl without rolling forward without prompting参数说明：load后面接 NBU 的 vendor 库路径，DB2 通过它从 NBU 存储读取备份流；without rolling forward跳过日志前滚；without prompting避免恢复过程交互式询问。如果目标机上数据库不存在，要加to /db_dir指定数据目录，否则会报路径错误。恢复到指定版本时，命令改成：
db2 restore db bi load /usr/openv/netbackup/bin/nbdb2.sl taken at 20050226120711 without rolling forward without promptingtaken at的时间戳就是 bplist 查到的目录名，注意保持 14 位数字完整，少一位 DB2 会直接报语法错误。
4.3 ONLINE 备份恢复：restore 之后必须 rollforward
Online 备份在备份过程中日志是活跃的，备份文件内部时间点不一致，所以恢复后必须做日志前滚，把数据库推到一致状态。这也是 online 和 offline 恢复流程上最大的区别：online 恢复永远带着 rollforward，offline 恢复永远带着 without rolling forward。
db2 restore db bi load /usr/openv/netbackup/bin/nbdb2.sl taken at 20050226120711 db2 rollforward db bi to end of logs and complete第一行 restore 用taken at指定版本，第二行 rollforward 把日志前滚到末端并结束。如果只需要恢复到某个时间点，用：
db2 rollforward db bi to 2005-02-26-12:07:11 using local time and complete这里有个血泪经验：部分 DB2 版本不支持using local time选项，报错后直接去掉即可，但此时要求操作系统时间与标准时间一致；如果系统时间有偏差，做时间点恢复时要手动把目标时间减去时差，否则恢复出来的数据会是错的，而且这个错误不会报出来，只能靠数据核对发现。
5. 异机恢复实战与避坑清单：No.Restrictions、CLIENT_NAME 和五个翻车点
5.1 异机恢复的启用开关：No.Restrictions 空文件
NBU 默认只允许发起备份的源客户端执行恢复操作，这是它的客户端身份校验机制。异机恢复前，必须在 Master Server 上用 root 权限创建一个空文件/usr/openv/netbackup/db/altnames/No.Restrictions，作用是放行所有主机对备份的访问请求。
touch /usr/openv/netbackup/db/altnames/No.Restrictions chmod 644 /usr/openv/netbackup/db/altnames/No.Restrictions创建后不需要重启 NBU 服务，立即生效。No.Restrictions是全局放行，如果担心安全边界，可以在同一目录下创建以源客户端主机名为文件名、内容写入目标主机名的文件，实现单对单放行。我一般在内网环境直接用 No.Restrictions，跨网段或安全要求高的环境用单对单方式。这个文件缺失时，恢复命令不会报“文件不存在”，而是报找不到备份或权限错误，非常容易误判。
5.2 目标机准备与 db2.conf 加 CLIENT_NAME
异机恢复的目标机，需要提前装好与源库版本一致或更高的 DB2，以及 NBU client，并运行过db2_config。实例名尽量与源机保持一致，因为备份记录里包含实例路径信息，实例名不同会直接影响 restore 的路径映射。db2.conf 的关键改动是：DATABASE 段和 ARCHIVE 段中都要增加一行CLIENT_NAME，值为源客户端主机名。
DATABASE BI OBJECTTYPE DATABASE POLICY DB2_Backup SCHEDULE Default-Application-Backup CLIENT_NAME gdccas670 ENDOPERCLIENT_NAME的作用是告诉 NBU：虽然发起恢复的是本机，但数据源来自 gdccas670 这台主机。漏写这一行，restore 命令会去当前主机找备份，结果自然是空的。如果目标机数据库名与源库不同，restore 命令里要加to指定目录，同时确认目标机磁盘路径可用且空间充足。
5.3 异机恢复完整命令序列
这里给出一套可照抄的命令序列，前提是假设源库的最后一个备份是 online 备份，需要前滚日志：
# Master Server 上以 root 执行一次 touch /usr/openv/netbackup/db/altnames/No.Restrictions # 目标机切换为 DB2 实例用户 su - db2inst1 # 从 NBU 读取备份并还原到指定目录 db2 restore db bi load /usr/openv/netbackup/bin/nbdb2.sl taken at 20050226120711 to /db_dir replace existing # 前滚日志到一致状态 db2 rollforward db bi to end of logs and complete逻辑说明：replace existing用于目标机存在同名库的情况，等价于先 drop 再 restore，省一步操作；to /db_dir是异机恢复里最常用的路径重定向参数，因为目标机文件系统布局通常与源机不同。整套序列执行下来，比同机恢复多出来的只有三处：Master Server 的空文件、db2.conf 的 CLIENT_NAME、restore 命令里的to路径。
参数说明：如果源备份是 offline 备份，去掉 rollforward 那行，并在 restore 行加上without rolling forward。如果不知道备份时间点，先bplist -C gdccas670 -t 18 -R //DB2/BI查出来再填。命令顺序不能反过来，restore 没完成就 rollforward 会直接报数据库处于 restore pending 状态。
5.4 五个常见翻车点
1. 现象：restore 报找不到请求的备份，或提示客户端无权限。原因：Master Server 上没有创建 No.Restrictions 文件，或 db2.conf 漏写 CLIENT_NAME。解决：确认ls /usr/openv/netbackup/db/altnames/No.Restrictions存在，确认两段配置里都有CLIENT_NAME gdccas670，然后重跑 restore。
2. 现象：restore 报 SQL2526N，提示目标数据库已存在且与备份不匹配。原因：目标机上已经有同名数据库。解决：要么db2 drop db bi后重跑，要么在 restore 命令加replace existing。注意 drop 前确认目标库没有需要保留的数据，这一步没有后悔药。
3. 现象：rollforward 一直停在 waiting for log 状态，或者报日志文件缺失。原因：ARCHIVE 段的日志归档策略配置不对，归档日志根本没进 NBU，或者RETDIR指向的本地目录里没有日志。解决：先查 db2.conf 的 ARCHIVE 段是否配了ARCFUNC SAVE，再确认 Standard 策略和 User Backup Schedule 的名字与配置一致。
4. 现象：备份脚本执行时报 load library 失败。原因：MY_LIB的平台库选错，32 位系统配了 64 位库，或反过来。解决：按第 3.1 节的平台对应表核对，AIX 上最常见的是把 nbdb2.sl44 和 nbdb2.sl64 搞混。
5. 现象：异机恢复后应用连接报错，SQL6031N 或类似错误。原因：目标机 DB2 版本低于源机，或实例路径不同导致 db2nodes.cfg 不匹配。解决：目标机 DB2 版本必须不低于源机，恢复完成后用db2rbind重新绑定所有包，这个命令能解决大部分跨主机恢复后的应用连接问题。
6. 恢复后的三层验证与一个能救命的技巧
6.1 验证恢复结果：连接、表空间、日志序号
恢复命令返回成功，不代表数据能直接用。我每次恢复完都按下面三层验证，缺一不可。第一层是应用层验证，用业务账号连一次库，执行简单查询，确认库可用；第二层是表空间状态验证，重点看是否有表空间处于 restore pending 状态。
db2 connect to bi db2 list tablespaces show detail db2pd -logsdb2 list tablespaces show detail的输出里，State 字段应该显示0x00000000，表示正常。如果显示0x00001000之类的值，说明表空间还在 pending 状态，通常是 rollforward 没做完整。第三层看日志序号：db2pd -logs输出当前日志文件和时间点，对照恢复前记录的源库日志序号，能确认前滚是否真的追到了目标时间，这一步是时间点恢复后核对数据最直接的手段。
6.2 把恢复过程脚本化
生产环境的恢复往往要重复多遍，尤其是验证阶段。我习惯把 restore 和 rollforward 封装成一个带参数的脚本，避免每次手敲命令敲错时间戳：
#!/bin/sh DBNAME=$1 TAKEN_AT=$2 TARGET_DIR=$3 VENDOR_LIB=/usr/openv/netbackup/bin/nbdb2.sl db2 "restore db $DBNAME load $VENDOR_LIB taken at $TAKEN_AT to $TARGET_DIR replace existing" if [ $? -eq 0 ]; then db2 "rollforward db $DBNAME to end of logs and complete" fi调用时执行sh restore.sh bi 20050226120711 /db_dir即可。脚本里对 restore 的返回码做了判断，只有 restore 成功才执行 rollforward，避免在 restore 失败时把数据库推到更糟的状态。从那以后，我每次做异机恢复演练都强制走一遍这套流程：先查 No.Restrictions 是否在位，再核对 db2.conf 的 CLIENT_NAME，restore 完必查表空间和日志序号。这套习惯帮我挡掉过至少三次备机接管的翻车现场，希望也能帮到你。
本文还有配套的精品资源，点击获取