简介面向数据库管理员、系统运维与备份容灾工程师的 TSM 6.3 实验测试文档围绕 Mhvtl 虚拟带库、Linux 平台及 Oracle/DB2 备份恢复场景帮助读者验证虚拟带库接入、TSM 策略配置与异机恢复流程。压缩包为 1 个 docx约 1.83MB按四大模块组织Mhvtl 在 CentOS 6.5 上的编译安装与带库可用性测试、基于 tgt 的 iSCSI 映射、TSM 主服务器及机械手/驱动器/卷/备份策略配置、Oracle 的 NUB 客户端备份与异机恢复。文档还给出 RMAN 恢复 spfile、control file、数据文件和归档日志、mount 及打开数据库等关键步骤并附目录、版本修改记录与操作检查点便于对照搭建测试环境、复盘配置顺序、整理故障排查路径和沉淀恢复操作清单。适合具备 Linux 与数据库基础、需要开展备份平台验收或灾备演练的中级读者也可作为企业内部培训与测试记录模板。已有 243 人学习。1. 没有物理带库也能把 TSM 备份链路跑通手里没有物理带库却要练 TSM6.3 的带库备份恢复这是很多人卡住的地方。真机 LTO 带库加机械手动辄几万块个人和小团队玩不起所以大部分讲 TSM 的资料停在截图上一到define path就没了下文。这份 TSM6.3 linux Mhvtl Oracle DB2 备份恢复测试文档想解决的就是这件事用 Mhvtl 在 Linux 上模拟一台 STK L700 机械手加 4 个 LTO 驱动器通过 iSCSI 映射给备份服务器再在这套模拟带库上把 TSM 的文件系统备份、Oracle 在线备份与异机恢复、DB2 备份恢复整条链路走一遍。适合两类人一是准备接手企业备份系统、需要先在实验环境把流程摸熟的运维二是已经装了 TSM却被设备配置和卷管理卡住的实施人员。文档是操作型测试记录不是原理教材价值全在参数和顺序上。2. Mhvtl 编译安装让 lsscsi 里凭空多出两台机械手Mhvtl 的本质是一个 SCSI 低层驱动加一组用户态守护进程它在内核里注册虚拟的 SCSI 目标让操作系统认为总线上真的挂着带库。理解这一点很关键后面所有的排错都围绕「内核模块加载了没有」和「用户态进程起来了没有」这两件事。下面按依赖、编译、验证三段走。2.1 先把依赖和目录规划做掉测试环境用的是 CentOS 6.6 最小化安装离线机器没有外网源第一步是把光盘挂成本地 yum 源同时把防火墙和 SELinux 关掉。SELinux 这一条不是可选项虚拟带库走的是 SCSI 通用设备节点标签不匹配时表现为设备存在但mtx报权限错误排查起来非常费时间。# 挂载光盘并改成本地源离线环境没法直连外网仓库 mount /dev/cdrom /mnt mkdir -p /etc/yum.repos.d/bak mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/bak/ cat /etc/yum.repos.d/CentOS-Media.repo EOF [c6-media] nameCentOS-$releasever - Media baseurlfile:///mnt gpgcheck0 enabled1 EOF # 关掉防火墙与 SELinux避免 SCSI 通用设备被策略拦截 service iptables stop chkconfig iptables off sed -i s/^SELINUX.*/SELINUXdisabled/ /etc/selinux/configbaseurl指向挂载点即可gpgcheck0是为了省掉导入密钥的步骤实验环境够用。改完 SELinux 配置文件必须重启才生效只执行setenforce 0是临时的重启后又会回来这一点在测试机上经常被忽略。接着装编译和调试要用的包。这一串依赖里kernel-devel和kernel-headers的版本必须和当前运行内核完全一致否则编译出来的mhvtl.ko加载会报invalid module formatmtx是操作机械手的命令行工具mt-st是操作磁带驱动器的sg3_utils用来直接发 SCSI 命令做底层验证lsscsi则负责把结果翻译成人能看懂的样子。# 一次性装齐编译工具链与 SCSI 调试工具 yum install -y lsscsi mt-st mtx sg3_utils zlib-devel \ kernel-devel kernel-headers gcc make unzip装完用uname -r和rpm -q kernel-devel对一下版本号不一致就先升级内核再重来别硬着头皮往下走。目录规划上Mhvtl 把「配置」和「数据」分开存放/etc/mhvtl放mhvtl.conf、library_contents.10、device.conf这类定义文件/opt/mhvtl放虚拟磁带的实际数据每一盘假磁带在磁盘上就是一个文件。两个目录都交给专门的vtl用户避免以 root 跑服务。# 服务以 vtl 用户运行配置与数据目录归属要提前改好 useradd vtl mkdir -p /opt/mhvtl /etc/mhvtl chown -R vtl:vtl /opt/mhvtl /etc/mhvtl2.2 编译内核模块与启动服务安装分两段先装发行版打好的 utils 包拿到mhvtl服务脚本、mktape等工具再编译源码里的内核模块。很多人只做了第一段服务能起但lsscsi里什么都看不到原因就在这里。# 第一段用户态工具 rpm -ivh mhvtl-utils-1.5-2.x86_64.rpm # 第二段内核模块 unzip mhvtl-1.5-2.zip cd markh794-mhvtl-d9f6115/kernel make make install # 启动并设为开机自启 service mhvtl start chkconfig mhvtl onmake install干的事是把mhvtl.ko拷到/lib/modules/$(uname -r)/extra/并执行depmod所以编译目录一定要选kernel子目录而不是源码根目录。首次启动时控制台会打印两行提示说找不到library_contents.10和library_contents.30并自动生成默认配置这是正常现象——它默认创建两台带库一台 STK L7004 驱动器、43 槽位一台 STK L804 驱动器、44 槽位。默认配置够用来做验证要改槽位数或驱动器型号再回头编辑这两个文件。2.3 读懂 lsscsi 的输出服务起来之后用lsscsi -g看设备节点。这一步是整个文档里信息密度最高的地方设备名对不上后面全盘皆输。lsscsi -g # [3:0:0:0] mediumx STK L700 0105 /dev/sch0 /dev/sg10 # [3:0:1:0] tape IBM ULT3580-TD5 0105 /dev/st0 /dev/sg2 # [3:0:2:0] tape IBM ULT3580-TD5 0105 /dev/st1 /dev/sg3 # [3:0:3:0] tape IBM ULT3580-TD4 0105 /dev/st2 /dev/sg4 # [3:0:4:0] tape IBM ULT3580-TD4 0105 /dev/st3 /dev/sg5 # [3:0:8:0] mediumx STK L80 0105 /dev/sch1 /dev/sg11要分清两列设备名/dev/sch0是字符设备形式的机械手带库管理软件一般不用它/dev/sg10是 SCSI 通用设备节点TSM 的define path ... desttypelibrary要的就是这个。磁带同理/dev/st0是回绕设备写完自动倒带/dev/nst0是不回绕设备TSM 必须用nst这一套用st会导致定位错乱。这个细节在第一次配 TSM 时坑过不少人。2.4 用 mtx 和 tar 做最小可用性验证在把设备交给 TSM 之前先在本地把「机械手能搬带、驱动器能读写」这两件事验证掉出问题能立刻定位到是 Mhvtl 层还是 TSM 层。# 查看机械手状态确认槽位里有带、驱动器为空 mtx -f /dev/sg10 status # 把 1 号槽位的磁带装进 0 号驱动器 mtx -f /dev/sg10 load 1 0 # 再查一次状态Data Transfer Element 0 应该显示 Full mtx -f /dev/sg10 status # 往驱动器里写一个目录验证读写通路 tar -cvf /dev/st0 /boot tar -tvf /dev/st0 # 用完把带退回槽位 mtx -f /dev/sg10 unload 1 0mtx的两个参数是「槽位号」和「驱动器号」顺序不能反。tar -cvf /dev/st0能成功说明内核模块、虚拟磁带文件、SCSI 命令链路全部打通如果这一步报Cannot open: Input/output error先看dmesg里有没有 SCSI 相关报错再确认vtl用户对/opt/mhvtl有写权限。默认每盘虚拟磁带容量 500MB做数据库备份明显不够改/etc/mhvtl/mhvtl.conf里的CAPACITY单位是 MB改完重启服务生效。# 修改默认磁带容量2046 表示每盘假磁带 2GB grep -n CAPACITY /etc/mhvtl/mhvtl.conf # CAPACITY2046 service mhvtl restart要注意的是容量在磁带首次写入时确定已经写过的带该多大还是多大想改只能重新mktape或换新带。所以配置文件里这个值最好在第一次跑测试之前就定下来。3. iSCSI 映射与 TSM 服务端设备定义Mhvtl 和 TSM 服务端装在同一台机器上最省事但真实场景里带库和备份服务器通常是分开的这份文档选择了更有代表性的做法Mhvtl 跑在一台机器上通过 iSCSI 把机械手和驱动器映射给备份服务器。多走这一层换来的是更接近生产的拓扑代价是设备名会漂移需要额外处理。3.1 服务端用 tgt 把 SCSI 设备挂出去iSCSI 目标端选scsi-target-utils也就是 tgt配置写在/etc/tgt/targets.conf。核心思路是把每一个/dev/sgN和/dev/nstN都当成一个 LUN 挂到同一个 target 下面。yum install -y scsi-target-utils cat /etc/tgt/targets.conf EOF target iqn.2015-04.local.vtl:l700 # LUN 0 是机械手对应本地 /dev/sg10 backing-store /dev/sg10 # LUN 1-4 是四个驱动器对应本地不回绕设备 backing-store /dev/nst0 backing-store /dev/nst1 backing-store /dev/nst2 backing-store /dev/nst3 /target EOF service tgtd start chkconfig tgtd on tgtadm --mode target --op showtgtadm --mode target --op show的输出要确认 target 处于ready状态且 LUN 数量对得上。这里有个现实问题要提前说清楚tgt 对 medium changer 类型SCSI type 8设备的透传并不总是完整部分版本下客户端能认到磁带却认不到机械手。遇到这种情况有两条路一是改用 scst 做目标端二是把 Mhvtl 直接装在备份服务器本地跳过 iSCSI 这一层。文档里选 tgt 是因为配置最简单但它是这套方案里最不确定的一环动手前最好先小范围验证。3.2 客户端发现与登录备份服务器这一侧装iscsi-initiator-utils先看本机 initiator 名字再向目标端发起发现。yum install -y iscsi-initiator-utils # 查看本机 initiator 名称服务端做 ACL 时要用 cat /etc/iscsi/initiatorname.iscsi # 发现目标输出会列出该门户下所有 target iscsiadm -m discovery -t sendtargets -p 192.168.81.6 # 登录指定 target iscsiadm -m node -T iqn.2015-04.local.vtl:l700 -l # 设为开机自动登录否则重启后设备全消失 iscsiadm -m node -T iqn.2015-04.local.vtl:l700 -p 192.168.81.6 \ --op update -n node.startup -v automatic # 确认新设备已经出现 lsscsi -gnode.startup这个参数非常关键。默认是manual重启后 iSCSI 会话不会自动重建/dev/sgN和/dev/nstN全部消失TSM 一启动就报设备不可用。改成automatic之后还要确认iscsid和iscsi两个服务都设了开机自启。3.3 设备名漂移与固定登录之后备份服务器上会多出一台 mediumx 和四个 tape但设备编号是在现有设备之后顺延分配的和 Mhvtl 那台机器上的编号完全没关系。更麻烦的是重启顺序变化会导致编号改变今天st0明天可能变成st1TSM 里写死的define path就全废了。常见做法是用/dev/tape/by-id/下的持久化链接或者自己写 udev 规则按 SCSI 序列号绑定名字。# 查看持久化命名序列号由 Mhvtl 生成重启不变 ls -l /dev/tape/by-id/ # ... - ../../st0 # ... - ../../nst0 # 用持久化路径替代裸设备名做验证 mtx -f /dev/sg10 status dd if/dev/zero of/dev/tape/by-id/scsi-XXXX-nst bs1M count10写成 udev 规则更稳妥比如把所有nst设备按序列号映射成/dev/tsm/drive0到/dev/tsm/drive3这样 TSM 的define path里写的是稳定名字换机器也不用重配。这一层麻烦在初期收益在后期测试环境如果能一次配好后面重启多少次都不用重新对设备号。3.4 TSM 服务端定义库、驱动器和路径TSM 6.3 服务端装好后先做实例初始化dsmserv format db然后用dsmadmc进入管理命令行。设备配置的顺序是死的先设备类再库再库的路径再驱动器最后驱动器的路径。顺序错了会一直报找不到库。dsmadmc-- 定义设备类类型要和虚拟磁带一致LTO5 对应 ULT3580-TD5 DEFINE DEVCLASS VTL_LTO5 DEVTYPELTO FORMATDRIVE LIBRARYVTLLIB -- 定义 SCSI 类型的带库 DEFINE LIBRARY VTLLIB LIBTYPESCSI -- 库的路径DEVICE 必须是机械手的 sg 节点 DEFINE PATH TSM63 VTLLIB SRCTYPESERVER DESTTYPELIBRARY DEVICE/dev/sg10 ONLINEYES -- 定义四个驱动器ELEMENT 是机械手内部的驱动器编号从 1 开始 DEFINE DRIVE VTLLIB DRIVE01 ELEMENT1 ONLINEYES DEFINE DRIVE VTLLIB DRIVE02 ELEMENT2 ONLINEYES DEFINE DRIVE VTLLIB DRIVE03 ELEMENT3 ONLINEYES DEFINE DRIVE VTLLIB DRIVE04 ELEMENT4 ONLINEYES -- 驱动器路径DEVICE 必须用不回绕设备 nst DEFINE PATH TSM63 DRIVE01 SRCTYPESERVER DESTTYPEDRIVE LIBRARYVTLLIB DEVICE/dev/nst0 ONLINEYES DEFINE PATH TSM63 DRIVE02 SRCTYPESERVER DESTTYPEDRIVE LIBRARYVTLLIB DEVICE/dev/nst1 ONLINEYES DEFINE PATH TSM63 DRIVE03 SRCTYPESERVER DESTTYPEDRIVE LIBRARYVTLLIB DEVICE/dev/nst2 ONLINEYES DEFINE PATH TSM63 DRIVE04 SRCTYPESERVER DESTTYPEDRIVE LIBRARYVTLLIB DEVICE/dev/nst3 ONLINEYESELEMENT的编号要和mtx status里Data Transfer Element N的编号对上对不上就表现为q drive时驱动器状态一直LOAD ERROR。另外DEVTYPE一旦定义就不能改选错了只能删掉设备类重来所以定义前先确认虚拟磁带是 LTO4 还是 LTO5。3.5 卷的标签、检入与存储池设备通了还不算完TSM 需要知道槽位里有哪些磁带。这一步用label libvolume和checkin前者把卷标写进磁带后者把卷登记到库的清单里。-- 扫描整台带库给所有未标记的带打上卷标 LABEL LIBVOLUME VTLLIB SEARCHYES LABELSOURCEBARCODE OVERWRITEYES -- 把已标记的卷检入为 scratch 状态供存储池取用 CHECKIN LIBVOLUME VTLLIB STATUSSCRATCH SEARCHYES CHECKLABELBARCODE -- 定义磁带存储池最大 scratch 数按实际卷数设 DEFINE STGPOOL TAPEPOOL VTL_LTO5 MAXSCRATCH20 -- 查看卷清单与驱动器状态 Q LIBVOLUME Q DRIVELABELSOURCEBARCODE表示卷标直接取 Mhvtl 生成的条码比如E01001L4省得手工输入。STATUSSCRATCH是空带可复用状态如果误检成PRIVATE存储池就永远拿不到带表现为备份任务一直排队等卷。文件系统备份的验证可以先用一个简单的客户端策略域跑通定义域、策略集、管理类和拷贝组注册节点然后dsmc backup手工触发一次在q actlog里看到ANR0500I之类的完成记录说明整条带库链路已经打通。4. Oracle 与 DB2 的备份与异机恢复设备层通了之后剩下的是数据层。Oracle 和 DB2 都要通过 TSM 的 TDPData Protection客户端把数据流交给 TSM再由 TSM 写到带库。这里最容易混淆的是两套配置文件dsm.sys/dsm.opt负责和 TSM 服务端通信tdpo.opt/db2dsdriver.cfg负责告诉数据库插件去哪里找 API 库。4.1 Oracle 客户端的 NUB 与 TDPO 配置客户端机器上要装两样东西TSM Backup-Archive 客户端提供 API 和dsmc以及 Data Protection for Oracle。装完先配 TSM 连接。# 典型的两个包BA 客户端和 API 库 rpm -ivh TIVsm-BA.x86_64.rpm TIVsm-API64.x86_64.rpm# /opt/tivoli/tsm/client/ba/bin/dsm.sys SERVERNAME tsm63 COMMMETHOD TCPip TCPPORT 1500 TCPSERVERADDRESS 192.168.81.7 NODENAME ORACLE PASSWORDACCESS GENERATE配好之后用dsmc query session验证能连上服务端第一次会交互式输入密码并生成。接下来配tdpo.opt这个文件是 Oracle 插件专用的。# /opt/tivoli/tsm/client/oracle/bin64/tdpo.opt DSMI_ORACLE2 /opt/tivoli/tsm/client/oracle/bin64 DSMI_LOG /opt/tivoli/tsm/client/oracle/bin64 TDPO_NODE ORACLE TDPO_PSWDPATH /opt/tivoli/tsm/client/oracle/bin64DSMI_ORACLE2指向插件自己的库目录写错路径的典型症状是 RMAN 报ORA-19554: error allocating device或者sbt库加载失败。TDPO_NODE必须和dsm.sys里的NODENAME一致不一致时备份能跑但数据会挂到另一个节点名下到异机恢复时找不到属于典型的「当场没问题、事后要命」的配置。配完用插件自带的命令做一次连通性检查比直接跑 RMAN 更容易定位问题。# 查询密码与节点状态能正常返回说明插件和服务端握手成功 /opt/tivoli/tsm/client/oracle/bin64/tdpocmd query tsm4.2 RMAN 备份到带库RMAN 调用 TSM 的方式是通过sbt_tape通道把TDPO_OPTFILE作为环境变量传进去。建议用configure channel固化而不是每个脚本里都写一遍。rman target /-- 固化 sbt 通道避免每次备份都要拼一长串参数 CONFIGURE CHANNEL DEVICE TYPE SBT_TAPE PARMS ENV(TDPO_OPTFILE/opt/tivoli/tsm/client/oracle/bin64/tdpo.opt); CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO %F; CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; -- 全库加归档日志备份完删除已备份的归档 BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;CONTROLFILE AUTOBACKUP ON这一条在异机恢复里是救命设置没有它就得手工指定控制文件位置。FORMAT %F让控制文件自动备份使用 TSM 能识别的唯一名字恢复时可以直接restore controlfile from autobackup。备份发起后到 TSM 侧确认数据真的落到了带库而不是在磁盘上打转。-- 在 dsmadmc 里看会话和卷占用确认走的是 TAPEPOOL Q SESSION Q VOLUME USAGE SELECT * FROM SUMMARY WHERE ACTIVITYBACKUP AND START_TIMETODAY-1如果Q SESSION里看到客户端在跑但Q VOLUME里没有卷被占用说明数据写进了磁盘存储池检查策略域里的拷贝组目标是不是指向磁带池。4.3 Oracle 异机恢复的完整顺序异机恢复是这套文档里最有含金量的部分也是实操中最容易翻车的地方。顺序不能乱恢复参数文件、恢复控制文件、mount、恢复数据文件、recover、open resetlogs。# 目标机先建好必要的目录结构路径要和源库一致 mkdir -p /u01/app/oracle/oradata/orcl mkdir -p /u01/app/oracle/admin/orcl/adump-- 启动到 nomount从自动备份里恢复 spfile STARTUP NOMOUNT; SET DBID 1234567890; RESTORE SPFILE FROM AUTOBACKUP; -- 用恢复出来的 spfile 重启到 nomount SHUTDOWN ABORT; STARTUP NOMOUNT; -- 恢复控制文件 RESTORE CONTROLFILE FROM AUTOBACKUP; ALTER DATABASE MOUNT; -- 恢复并前滚数据文件 RESTORE DATABASE; RECOVER DATABASE; -- 打开库 ALTER DATABASE OPEN RESETLOGS;SET DBID这一步在异机恢复时不能省因为目标机上没有原来的控制文件RMAN 不知道去哪里找自动备份。DBID 可以从源库的SELECT DBID FROM V$DATABASE提前记下来。另外如果目标机用的是不同的 TSM 节点名会直接报找不到备份对象因为 TSM 的备份是按节点隔离的。处理办法有两种把目标机注册成和源库相同的节点名实验环境最省事或者在 TSM 服务端用GRANT AUTHORITY把源节点的备份访问权限授给目标节点。-- 服务端授权让 RESTORE 节点能读到 ORACLE 节点名下的备份 GRANT AUTHORITY ORACLE NODERESTORE4.4 DB2 的 TSM 备份与恢复DB2 走的是同样的思路只是插件配置文件和命令不一样。装好 TDP for DB2 后在实例用户下更新配置让 DB2 知道用 TSM 作为介质。# 以实例用户执行指向 TSM API 和配置文件 db2 update dbm cfg using VENDOROPT /opt/tivoli/tsm/client/api/bin64/tdpo.opt # 全库备份use tsm 表示走 TSM 介质 db2 backup db sample use tsm # 查看备份历史确认落在 TSM 上 db2 list history backup all for sample恢复时如果要做异机验证用redirect方式恢复到一个新库名避免覆盖原库。# 恢复到新库 SAMPLE2需要手工重定向表空间容器 db2 restore db sample from tsm taken at 20250418103500 \ into sample2 redirect without rolling forward # 查看需要重定向的容器 db2 restore db sample continue # 重定向完成后前滚并结束 db2 rollforward db sample2 to end of logs and completetaken at后面的时间戳必须和list history里的完全一致精确到秒。DB2 的恢复对日志链完整性要求很高如果中间缺一段归档日志rollforward会卡住不动这时候要看db2diag.log里具体缺哪个日志文件。5. 避坑这套组合最容易翻车的五处下面的五条都是在这套环境里真实会遇到的按现象、原因、解决三段写遇到问题时可以直接对号入座。5.1 服务起了但 lsscsi 里看不到带库现象service mhvtl start返回成功ps里能看到vtllibrary和vtltape进程但lsscsi -g里一台 mediumx 都没有。原因内核模块没加载。mhvtl-utils包只提供用户态程序mhvtl.ko需要单独make install而服务脚本并不会主动modprobe。解决先lsmod | grep mhvtl确认没有就手工modprobe mhvtl再重启服务。如果modprobe报invalid module format说明编译时用的内核头文件版本和当前运行内核不一致用uname -r和rpm -q kernel-devel对一下重装匹配版本后重新编译。这一条我在不同机器上遇到过三次全都是版本不匹配。5.2 iSCSI 重启后设备号全变TSM 报设备不可用现象机器重启后 TSM 启动正常但q drive显示所有驱动器OFFLINEq path里路径状态是OFFLINE手工vary on报找不到设备。原因两个问题叠加。一是 iSCSI 会话没有自动重建/dev/nstN根本不存在二是即使重建了SCSI 扫描顺序变化导致编号漂移原来写死的/dev/nst0现在对应的是别的驱动器。解决先把node.startup改成automatic并确认iscsid开机自启解决会话问题。设备号漂移用/dev/tape/by-id/的持久化路径或者 udev 规则固定名字然后把 TSM 里的define path全部改成稳定路径。改设备路径不需要删驱动器用UPDATE PATH直接改DEVICE参数即可。5.3 RMAN 报 ORA-19554 或 sbt 库加载失败现象allocate channel ... type sbt_tape直接失败报ORA-19554: error allocating device, device type: SBT_TAPE后面跟ORA-27211: Failed to load Media Management Library。原因Oracle 找不到libtsm.so。常见情况有三种——DSMI_ORACLE2路径写错、装的是 32 位插件而数据库是 64 位、tdpo.opt权限不对导致oracle用户读不到。解决先用ldd检查libobk.so的依赖是否齐全再确认$ORACLE_HOME/lib/libobk.so是否指向了 TSM 的库。权限上tdpo.opt一般要求属主是oracle:oinstall、权限 600 或 640。这一条排查顺序建议从路径开始因为路径错误占了大多数。5.4 异机恢复时 RMAN 找不到备份现象目标机上restore controlfile from autobackup报ORA-19870或者直接说没有可用的备份。原因TSM 的备份按节点名隔离源库备份挂在ORACLE节点名下目标机注册的是RESTORE节点自然看不到。另一个可能是控制文件自动备份的FORMAT没设成%F导致 RMAN 无法按 DBID 推算文件名。解决实验环境里最简单的做法是把目标机注册成同名节点用同一个NODENAME生产环境用GRANT AUTHORITY做跨节点授权。如果是FORMAT的问题只能回到源库重新配置并做一次新的自动备份历史备份改不了。5.5 备份任务一直排队存储池拿不到卷现象客户端dsmc backup或 RMAN 一直卡在waiting for mountq actlog里反复出现ANR8779E或等待介质的消息。原因存储池里没有可用的 scratch 卷。要么卷没检入要么检入时状态被设成了PRIVATE要么MAXSCRATCH设得太小已经用满。解决Q LIBVOLUME看卷清单和状态Q STGPOOL TAPEPOOL FD看 scratch 剩余。空带用CHECKIN ... STATUSSCRATCH重新检入已经写过数据的带如果确认可以覆盖先DELETE VOLUME再检入。MAXSCRATCH可以在线UPDATE STGPOOL调大不用重启服务。6. 验收清单怎么确认这套假带库是真在工作跑完一遍备份不代表链路可用我一般会做三个动作来验收。第一个是反向读从带库里restore一个文件到临时目录比对md5sum第二个是看 TSM 的卷占用Q VOLUME USAGE里必须能看到磁带被实际写入否则数据可能全在磁盘池里第三个是拔掉磁盘池的写入权限强制备份走磁带看任务是否仍然成功。这三个动作做完才敢说带库链路是通的。-- 验收三连卷占用、驱动器状态、近一天的成功备份 Q VOLUME USAGE Q DRIVE FD SELECT ACTIVITY, SUCCESSFUL, BYTES, START_TIME FROM SUMMARY \ WHERE START_TIME TODAY-1再补一个我常用的技巧在dsmadmc里给测试节点单独设一个小的管理类RETEXTRA1、VEREXISTS1让带上的数据很快过期这样反复测试不会把 43 个槽位很快占满。虚拟带库的槽位数是固定的跑十几轮全备之后就满了MAXSCRATCH再大也没用只能靠缩短保留期来回收。还有一点很关键恢复验证一定要用和生产不同的机器做异机恢复能成功才说明控制文件、spfile、归档日志三样东西都是完整的。同机恢复能过但异机恢复失败基本都是控制文件自动备份没开或者节点名不一致。从那以后我每次搭这套环境都会先做一次完全空库的异机恢复演练再开始跑正式备份省得数据堆了一堆才发现恢复不了。希望帮到你。本文还有配套的精品资源点击获取
