简介面向系统/备份运维工程师的原创技术资料围绕 TSM 6.3、Mhvtl 虚拟带库、Oracle 与 DB2 数据库在 Linux 平台上的备份恢复测试展开适合正在规划集中备份或灾备方案的团队参考。全文以四个章节组织先介绍 Mhvtl 虚拟带库在 CentOS 6.5 上的安装配置再讲解 TSM 主服务器安装、存储设备与卷配置、备份策略制定随后聚焦 Oracle 数据库的 TSM 客户端配置与手工备份最后补充异机恢复的完整流程。文档覆盖从底层虚拟带库到上层应用恢复的完整链路包含编译安装 MHVLT、测试带库可用性、基于 tgt 的 iSCSI 映射、NUB 客户端安装、RMAN 恢复数据库、异机恢复授权等关键操作并配有分区截图与命令示例可作为搭建虚拟带库备份环境或制定灾备演练方案的参考模板。压缩包内共有 1 个 docx 格式的完整技术文档约 1.83MB共 53 页目录层级清晰直接打开即可通读。目前已有 241 人学习下载适合需要评估 TSM 备份方案、或正在实施数据库备份恢复项目的工程师。1. 搭一套 TSMMhvtl 备份恢复测试环境你也会踩的版本坑在备份运维圈子里MhvtlLinux 虚拟带库加 TSM 6.3.5再配上 Oracle 和 DB2 客户端做备份恢复验证是搭测试环境最常见的组合之一。这套环境本身不难但版本链路很长Mhvtl 1.5-2 的编译要求 kernel-devel 与当前内核精确匹配TSM 6.3.5 的存储设备定义又依赖虚拟带库的设备路径一个环节写错后边的卷、策略、RMAN 备份全部连不上。我曾经在这上面折腾了两天最后发现只是 sg 设备号漂移。这份文档适合两类人一类是要在测试机里复现“TSM 备份 Oracle/DB2 到带库”全流程的运维另一类是准备做异机恢复演练但不想占用真实磁带库的团队。后面会按“装 Mhvtl → 映射 iSCSI → 配置 TSM → 发起备份 → 异机恢复”的顺序完整走一遍。2. Mhvtl 虚拟带库编译安装从依赖包到 tar 读写验证2.1 环境基线四个节点一台虚拟带库这套测试环境对应的是某评测中心的一个简化备份拓扑全部跑在虚拟化平台上。参与备份的节点一共四个角色划分非常清楚服务器角色主机名IP 地址操作系统应用备份主服务器tsm6192.168.81.7CentOS 6.6TSM 6.3.5虚拟带库mhvtl192.168.81.6CentOS 6.6Mhvtl 1.5-2 iSCSI备份客户端 1oracle192.168.81.11RHEL 5.7Oracle 11g备份客户端 2db2192.168.81.12RHEL 5.7DB2 9.7带库节点和 TSM 服务器都是 CentOS 6.6两个数据库客户端是老牌的 RHEL 5.7。这套组合有一个典型特征数据库版本和操作系统版本都偏旧但这恰恰是很多存量生产环境还在跑的真实形态。后面所有安装操作都以这张表为准主机名和 IP 别改配置里到处都要用。2.2 安装前准备依赖包和 vtl 用户Mhvtl 不是那种解压即用的软件它需要编译内核模块所以先把编译工具链和 SCSI 管理工具装齐。用 yum 一次装完yum install lsscsi mt-st mtx zlib-devel sg3_utils zlib kernel-devel kernel-headers gcclsscsi列出 SCSI 设备及其 sg 设备号后面验证带库设备全靠它mt-st和mtx前者是磁带机控制工具后者是机械手控制工具测试带库可用性时直接对应/dev/st*和/dev/sg*zlib-devel、zlib、kernel-devel、kernel-headers编译 Mhvtl 内核模块必需的开发包gcc编译器没它什么都编不了。依赖装完后创建专用用户和目录useradd vtl passwd vtl mkdir -p /opt/mhvtl mkdir -p /etc/mhvtl chown -Rf vtl:vtl /opt/mhvtl chown -Rf vtl:vtl /etc/mhvtl这里/opt/mhvtl是虚拟带库的存储路径所有“磁带”介质文件都落在这里/etc/mhvtl是配置文件路径。把属主改成 vtl 用户是因为 Mhvtl 服务默认以这个用户运行目录权限不对会导致写介质失败或者服务起不来。我在 2.1 环境表里特意把 mhvtl 节点单列出来也是因为它的目录规划直接影响后边 iSCSI 映射能不能透传设备。提示确认kernel-devel版本与uname -r完全一致不一致的话编译必报错具体现象放到第 5 章排查部分说。2.3 编译安装 MHVLT 1.5-2 与内核模块依赖和目录就绪后开始装软件包。Mhvtl 的安装分两部分rpm 包提供用户态工具zip 源码包提供内核模块。顺序不能反rpm -ivh mhvtl-utils-1.5-2.x86_64.rpm unzip mhvtl-1.5-2.zip cd markh794-mhvtl-d9f6115/kernel make make installmhvtl-utils-1.5-2.x86_64.rpm装的是 mtx 之外的 Mhvtl 管理工具和启动脚本解压后的目录名markh794-mhvtl-d9f6115是源码仓库的默认目录名进入kernel子目录才是内核模块源码make make install编译并安装内核模块这步必须有第 2.2 小节的 kernel-devel 支撑。编译安装完成后启动服务并设置开机自启service mhvtl start chkconfig mhvtl on首次启动时系统会看到类似Could not locate library config file: /etc/mhvtl/library_contents.10的提示然后自动生成默认的 library_contents 文件。这是正常现象不是报错说明服务已经在按默认配置创建两套带库。默认情况下 Mhvtl 会模拟两个带库一个对应/dev/sg10机械手一个对应/dev/sg11机械手。启动后改一下磁带容量配置默认 500MB 一盘带根本不够 TSM 写归档日志cat /etc/mhvtl/mhvtl.conf# Home directory for config file(s) MHVTL_CONFIG_PATH/etc/mhvtl # Default media capacity (500 M) CAPACITY2046 # Set default verbosity [0|1|2|3] VERBOSE1 # Set kernel module debuging [0|1] VTL_DEBUG0CAPACITY2046的含义是每盘磁带默认容量 2046MB约等于 2GB。这个值直接影响后面 TSM 定义卷时对带库容量的判断建议测试环境直接设成 2046不要用默认的 500。VERBOSE控制日志详细度排查问题时调到 2 或 3 能看到更多内核模块输出VTL_DEBUG平时保持 0 即可。注意修改CAPACITY后必须重启 mhvtl 服务而且该设置只对新生成的磁带介质生效槽位里已存在的卷标签介质容量不会变。2.4 设备验证lsscsi、mtx 与 tar 读写服务启动后第一件事是看设备是否被内核识别这一步能过滤掉大半配置问题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 [3:0:9:0] tape STK T10000B 0105 /dev/st4 /dev/sg6 [3:0:10:0] tape STK T10000B 0105 /dev/st5 /dev/sg7 [3:0:11:0] tape STK T10000B 0105 /dev/st6 /dev/sg8 [3:0:12:0] tape STK T10000B 0105 /dev/st7 /dev/sg9设备类型这一列要重点看mediumx是机械手SCSI Media Changertape是磁带机。/dev/sg10对应 STK L700 机械手/dev/sg11对应 STK L80 机械手这两个是 TSM 定义 library 时用的设备路径。/dev/st0到/dev/st7是八台磁带机但注意 st 设备不是按 sg 顺序排列的/dev/st0对应/dev/sg2/dev/st4对应/dev/sg6定义 path 时容易搞混我一般直接以lsscsi -g输出为准抄写。设备识别无误后用 mtx 验证机械手mtx -f /dev/sg10 statusStorage Changer /dev/sg10:4 Drives, 43 Slots ( 4 Import/Export ) Data Transfer Element 0:Empty Data Transfer Element 1:Empty ... Storage Element 1:Full :VolumeTagE01001L4 ... Storage Element 22:Full :VolumeTagCLN101L4 Storage Element 30:Full :VolumeTagF01030L5Storage Changer后面那行是带库概要4 个驱动器、43 个槽位。Data Transfer Element是驱动器元素号TSM 定义 drive 时用的 element 编号就对应这里的 0 到 3。Storage Element是槽位VolumeTag是介质卷标签这里是 E01001L4 这种命名L4 表示 LTO4 介质后半段的 F01030L5 是 LTO5 介质。还有CLN101L4这种是清洁带备份策略里要过滤掉不能当普通卷用。机械手验证通过后做一次真实的写读测试mtx -f /dev/sg10 load 1 0 tar -cvf /dev/st0 /boot mt -f /dev/st0 rewind tar -tvf /dev/st0load 1 0把 1 号槽位的磁带加载到 0 号驱动器相当于机械手抓带动作。tar -cvf /dev/st0 /boot把/boot目录写入磁带c创建归档v显示文件列表f指定输出设备为 st0。写完必须mt rewind倒带因为磁带写完后停在带尾直接读会什么都读不到。tar -tvf列出带内内容能看到文件就说明整条带库链路已经通了。3. iSCSI 带库映射与 TSM 服务器端配置让备份软件看到一个“真实”带库3.1 用 tgt 把带库映射给 iSCSIMhvtl 装好之后带库设备在 mhvtl 节点本地。要让 TSM 服务器能用上它通常做法是装一个基于 tgt 的 iSCSI target把带库的 sg 设备和 st 设备原样映射出去TSM 服务器通过 iSCSI 登录后就能看到完整的机械手和磁带机跟接了一台真实带库没有区别。先装 tgt 服务端并编辑 targets 配置yum install scsi-target-utils vim /etc/tgt/targets.confinclude /etc/tgt/tgt.local target iqn.2015-04.test.mhvtl:library backing-store /dev/sg10 backing-store /dev/sg11 backing-store /dev/st0 backing-store /dev/st1 backing-store /dev/st2 backing-store /dev/st3 backing-store /dev/st4 backing-store /dev/st5 backing-store /dev/st6 backing-store /dev/st7 /targettarget iqn...定义了一个 iSCSI target客户端登录时用这个 IQN 找到设备组每个backing-store把一个本地设备映射成一个 LUN。这里映射的全部是lsscsi -g输出里的 sg 字符设备不是块设备这是关键机械手sg10、sg11必须映射只映射磁带机不映射机械手的话TSM 定义 library 时找不到/dev/smc设备。配置完启动 tgt然后在 TSM 服务器侧发起 iSCSI 连接service tgtd start chkconfig tgtd on iscsiadm -m discovery -t sendtargets -p 192.168.81.6 iscsiadm -m node -T iqn.2015-04.test.mhvtl:library -p 192.168.81.6 --logindiscovery用来发现带库节点上有哪些 target--login是正式建立会话。登录成功后 TSM 服务器本地lsscsi -g会出现和 mhvtl 节点几乎一样的设备列表设备号可能从别的 scsi 总线号开始但类型和型号完全一致。提示target 名称里的日期段可以随意但整条 IQN 在客户端登录时必须原样使用少一个字母都登录不上。3.2 TSM 6.3.5 主服务器安装TSM 主服务器安装本身不复杂常见做法是解压安装介质后按组件顺序安装先装 GSKit 加密库再装服务器端主程序最后装服务端命令行工具。安装过程中需要指定实例名和数据库目录生产习惯是单独划一个分区给 TSM 的数据库和日志测试环境可以共用根分区但目录要分开规划。装完后 TSM 会创建一个实例默认的管理员账号是 admin初始密码在安装过程中设置。进入管理命令行是后面所有配置操作的前置条件/opt/tivoli/tsm/server/bin/dsmadmc -idadmin -passwordadmin进入后是tsm: SERVER1提示符所有定义带库、卷、策略的命令都在这下面执行。如果密码忘了可以用安装时的实例用户执行dsmadmc -idadmin -password重置这是 TSM 预留的本地认证通道生产环境建议安装后立刻改掉默认密码。3.3 定义带库设备机械手与驱动器TSM 把物理带库抽象成三层library 对应机械手drive 对应驱动器path 把服务器和这些设备关联起来。在 dsmadmc 里执行define library L700TO typescsi define path SERVER1 to L700TO srctypeserver desttypelibrary device/dev/sg10 define drive L700TO drive0 element0 define path SERVER1 L700TO drive0 srctypeserver desttypedrive libraryL700TO device/dev/st0define library ... typescsi声明一个 SCSI 带库TSM 会通过机械手设备发送 SMC 指令define path ... device/dev/sg10把 TSM 服务器和机械手设备路径绑定这里的设备路径必须是 TSM 服务器本地lsscsi -g看到的路径define drive ... element0element 号对应mtx status里 Data Transfer Element 的编号第一个驱动器是 0最后一条 path 把服务器和驱动器绑定libraryL700TO指定它归属于哪个带库device/dev/st0是磁带机设备路径。这里最容易踩的坑是 library 名和实际带库型号混用。Mhvtl 节点上两个机械手一个是 STK L700、一个是 STK L80TSM 里定义两个 library 时命名要能区分我习惯直接叫L700TO和L80TO避免后面定义卷时对着名字发呆。3.4 配置卷、备份策略与本地磁盘备份池带库设备定义完成后还要让 TSM 知道“磁带”的容量规格和卷标签。Mhvtl 模拟的是 LTO 驱动器所以设备类按 LTO 定义define devclass LTO5LG devtypeLTO libraryL700TO formatdrive define volume L700TO E01001L4 define volume L700TO F01030L5devtypeLTO告诉 TSM 这是 LTO 设备类后面建存储池时直接引用formatdrive表示容量格式由驱动器协商决定不做强制覆盖define volume定义带库里的卷卷标签必须和mtx status里已存在的 VolumeTag 一致填一个不存在的标签TSM 调用机械手抓带时会找不到介质。卷有了再建备份存储池和策略define stgpool BACKUPPOOL LTO5LG maxscratch30 update copygroup STANDARD STANDARD STANDARD destBACKUPPOOLBACKUPPOOL是备份数据最终落地的存储池maxscratch30表示允许 TSM 自动从带库抓取最多 30 盘空带作为临时卷。update copygroup把默认管理类的备份目标指向 BACKUPPOOL这样客户端备份的数据默认进带库池。TSM 还支持把备份池的数据再复制到磁盘池这个设计在文档里叫本地磁盘备份。做法是先定义一个磁盘存储池然后执行池间备份define stgpool DISKPOOL disk maxscratch30 backup stgpool BACKUPPOOL DISKPOOLbackup stgpool是 TSM 的存储池备份功能把 BACKUPPOOL 里的数据复制一份到 DISKPOOL这样同一份备份数据既有带库副本又有磁盘副本。测试环境的习惯做法是把 DISKPOOL 指向本机一块独立目录验证恢复时优先从磁盘池取数据速度比从虚拟带库读快很多也顺便验证了 TSM 的层级存储。4. 基于 TSM 的 Oracle 备份从客户端注册到手工发起4.1 客户端环境准备与 TDP for Oracle 安装Oracle 数据库备份不能靠 TSM 基础客户端直接完成需要安装 TDP for Oracle 模块这份测试文档里写作 NUB 客户端实际对应的就是 TSM 的 TDPO 模块。它负责在 RMAN 和 TSM 之间搭桥RMAN 的备份通道以sbt_tape类型调用 TSM API数据流从 Oracle 到 TSM 再到虚拟带库。安装顺序有讲究先装 TSM API 和 BA 客户端再装 TDPO两个包缺一个RMAN 分配 channel 时都会报找不到 TDPO 库文件。Oracle 客户端节点是 RHEL 5.7安装时要选兼容该系统的客户端版本装完确认 TDPO 的libobk.so存在于安装目录。4.2 dsm.opt / dsi.opt 配置与节点注册客户端要和 TSM 服务器通信核心是三个文件dsm.opt是 BA 客户端的连接配置dsi.opt是 TDPO 的选项文件密码文件由 TDPO 安装时生成。先写连接配置cat /usr/tivoli/tsm/client/oracle/bin/dsm.opt EOF NODE oracle TCPADDRESS 192.168.81.7 TCPPORT 1500 EOFcat /usr/tivoli/tsm/client/oracle/bin/dsi.opt EOF TDPO_NODE oracle TDPO_PSWDPATH /usr/tivoli/tsm/client/oracle/bin EOFNODE oracle客户端节点名必须和 TSM 服务器上注册的节点完全一致TCPADDRESS指向 TSM 主服务器的 IP也就是 192.168.81.7不是 mhvtl 带库节点TCPPORT 1500TSM 默认开放 1500 端口接收客户端连接改过端口的话这里要跟着改TDPO_PSWDPATH指向存放 TDPO 密码文件的目录RMAN 备份时 TSM 会从这里读节点密码。节点要在服务器端先注册才能在客户端发起备份。在 TSM 服务器上执行dsmc reg node oracle oracle123 dsmc query nodereg node注册一个名为 oracle 的客户端节点第二个参数是节点密码。query node验证注册结果能看到节点的平台、策略域、上次备份时间等信息。节点密码在客户端配置文件里不会明文出现TDPO 安装时会提示输入密码并写入加密的密码文件这一点和直接写死明文的普通 dsm.opt 不一样。4.3 服务器端策略确认与手工发起备份节点注册后要把它放进能用的策略域。默认 STANDARD 策略域可以直接用但要确认管理类里的 copygroup 指向了第 3.4 小节创建的 BACKUPPOOL。确认无误后在 Oracle 服务器上用 RMAN 发起一次手工备份rman target /run { allocate channel t1 type sbt_tape; send ENV(TDPO_OPTFILE/usr/tivoli/tsm/client/oracle/bin/dsi.opt); backup database plus archivelog; release channel t1; }allocate channel t1 type sbt_tape指定备份通道走 TSM 的 SBT 接口没有这一步数据只会落在本地磁盘send命令把 TDPO 的选项文件路径传给 TSM APIdsi.opt里已经写好了节点名backup database plus archivelog备份整个数据库并附带归档日志这是数据库在线备份的常规姿势跑完后 TSM 会把数据写成带库上的卷。备份发起后在 TSM 服务器端可以实时看到任务状态和最终落卷情况q process q content BACKUPPOOLq process显示正在执行的备份进程能看到读写字节数q content BACKUPPOOL列出存储池里已经写入的卷和数据对象看到备份产生的新卷说明整条链路已经打通。到这一步“客户端 → TSM 服务器 → 虚拟带库”的备份通路就算正式跑起来了。5. TSMMhvtl 环境排查避坑五个翻车现场这套环境搭建过程中有一半时间花在排错上而且很多错是重复出现的。以下五条按现象到解决的方式记录每条都是我实际遇到过的。5.1 kernel-devel 版本不匹配编译第一步就报错现象在make编译 Mhvtl 内核模块时报一堆找不到generated/autoconf.h或linux/version.h的错误无论怎么重装 kernel-devel 都一样。原因系统里有多个 kernel-devel 版本yum install kernel-devel默认装的是 yum 源里最新的版本而当前运行的内核是另一个版本源码编译时引用的/usr/src/kernels/$(uname -r)目录不存在。解决安装和当前内核精确匹配的开发包yum install kernel-devel-$(uname -r)。装完先确认/usr/src/kernels/$(uname -r)存在再重新make make install。从那以后我每台机器编译前都先执行uname -r看一眼。5.2 mhvtl 服务起来了但 lsscsi 看不到 mediumx 设备现象service mhvtl start提示进程已启动PID 也打印出来了但lsscsi -g里只有原来的磁盘和光驱看不到任何带库设备。原因八成是/opt/mhvtl或/etc/mhvtl的属主不是 vtl服务启动后没有权限创建介质描述文件另一种情况是内核模块没真正加载lsmod | grep mhvtl输出为空。解决先停服务重新执行chown -Rf vtl:vtl /opt/mhvtl /etc/mhvtl再启动服务。如果依然没有设备手动加载内核模块后重启 mhvtl然后重新执行lsscsi -g不用重启系统。设备出来后注意记下 sg 号重启后设备号可能漂移TSM 里定义 path 的路径要跟着更新。5.3 iSCSI 客户端看到的不是 mediumx 而是 disk现象TSM 服务器 iSCSI 登录成功后lsscsi -g里能看到设备但类型不是mediumx和tape而是disk设备型号也变成了 tgt 的默认仿真型号。原因/etc/tgt/targets.conf里backing-store指向了块设备路径或者指向了本地磁盘设备而不是 sg 字符设备。tgt 对 sg 设备透传时会把 SCSI INQUIRY 数据原样转发客户端看到的才是 STK 机械手和 LTO 驱动器指向块设备时tgt 只能按普通磁盘导出客户端的 SCSI 层就把它识别成 disk。解决回到带库节点确认lsscsi -g输出的设备路径把 targets.conf 里的backing-store全部改成/dev/sgX和/dev/stX格式重启 tgtd客户端重新iscsiadm --logout后再--login重新扫描后设备类型就正常了。排查时可以对比带库节点和 TSM 服务器两侧的lsscsi -g输出类型应该完全一致。5.4 磁带容量只有 500MB备份跑一会儿就写满现象RMAN 备份开始后没几分钟TSM 服务器端报卷满q content里看到一个卷被写了大量小对象但备份进程反复换带速度极慢最后归档日志备份失败。原因默认CAPACITY500一盘磁带 500MBOracle 的归档日志和数据文件很快就把带写满了。TSM 通过设备类容量感知到卷满后会不断抓新卷而虚拟带库换带本身有开销整个备份就被拖垮了。解决修改/etc/mhvtl/mhvtl.conf里的CAPACITY2046重启 mhvtl。注意只对新生成的介质生效槽位里已存在的旧卷标签容量不会自动扩大建议把模拟的槽位介质清掉重新生成或者直接换新的卷标签。改完在 TSM 里重新定义新的卷再跑一次备份验证。5.5 TSM 客户端报 TCP 连接失败先查 1500 端口再查节点名现象dsmc backup或 RMAN 分配 channel 时报连接失败错误信息里出现 TCP 相关字样客户端日志和服务器端日志各执一词。原因两个最常见的原因一是 TSM 服务器 1500 端口没有监听二是客户端dsm.opt里TCPADDRESS写错了地址或NODE名和服务器端注册的不一致。iSCSI 映射带库的拓扑里经常有人把TCPADDRESS写成带库节点的 IP这是把带库当成了备份服务器。解决先在 TSM 服务器上执行netstat -an | grep 1500确认端口监听再在客户端执行dsmc query session测试连通性。确认网络没问题后核对dsm.opt里的NODE和服务器端dsmc query node的输出是否完全一致节点名区分大小写。最后检查dsmerror.log错误码会直接告诉你认证失败还是网络不可达。6. 用 Oracle 异机恢复验收整套链路从 restore spfile 到 open database备份做完只算完成一半验证备份能不能恢复才算是闭环。我做这套测试的最后一个动作是拿一台空机器做 Oracle 异机恢复目标很直接把第 4 章备份的 11g 数据库通过 TSM 从虚拟带库拉回到一台没有原始数据的新主机上恢复完成并打开数据库。恢复前先做两个检查。第一目标机必须装好 TDP for Oracle 客户端dsi.opt和dsm.opt里的节点名写原生产库的节点 oracle密码要和服务器端注册的一致。第二在 TSM 服务器端确认备份数据还在dsmc query session q content BACKUPPOOLq content能看到当年备份产生的卷和对象确认 BACKUPPOOL 里的数据没被过期回收。接下来在目标机上创建恢复必要的目录结构Oracle 的 adump、闪回区、数据文件目录都要预先存在否则 restore 会因路径缺失直接失败mkdir -p /u01/app/oracle/admin/orcl/adump mkdir -p /u01/app/oracle/flash_recovery_area mkdir -p /u01/app/oracle/oradata/orcl然后通过 RMAN 走 TSM 通道恢复先恢复 spfile 和 controlfilestartup nomount; run { allocate channel t1 type sbt_tape; send ENV(TDPO_OPTFILE/usr/tivoli/tsm/client/oracle/bin/dsi.opt); restore spfile to pfile /tmp/initorcl.ora; restore controlfile to /u01/app/oracle/oradata/orcl/control01.ctl; release channel t1; }恢复完 spfile 和 controlfile 后用恢复出来的参数文件重新启动实例并挂载数据库startup force nomount; alter system set control_files/u01/app/oracle/oradata/orcl/control01.ctl scopespfile; alter database mount;mount成功后执行数据文件和归档日志的完整恢复run { allocate channel t1 type sbt_tape; send ENV(TDPO_OPTFILE/usr/tivoli/tsm/client/oracle/bin/dsi.opt); restore database; recover database; release channel t1; } alter database open resetlogs;restore database从虚拟带库拉回全部数据文件recover database应用归档日志把数据库推进到一致性状态open resetlogs是异机恢复的必选动作它会重置 redo 日志序列号。打开成功后执行一次select count(*) from v$tablespace能查到所有表空间就说明整条链路完全跑通。从那以后我每次搭完这类环境都不急着拆机器强制把异机恢复全流程再走一遍才收工——因为只有在空机器上成功 open 过一次你才知道备份是真能用而不是只在日志里“备份成功”。DB2 9.7 的恢复思路和 Oracle 类似同样是客户端走 TSM API 取数据核心验证动作换成本身的管理命令即可。希望帮到你。本文还有配套的精品资源点击获取