企业官网建设流程全解析

简介：面向系统/备份运维工程师的原创技术资料，围绕 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. 搭一套 TSM+Mhvtl 备份恢复测试环境：你也会踩的版本坑

在备份运维圈子里，Mhvtl（Linux 虚拟带库）加 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 环境基线：四个节点一台虚拟带库

这套测试环境对应的是某评测中心的一个简化备份拓扑，全部跑在虚拟化平台上。参与备份的节点一共四个，角色划分非常清楚：

带库节点和 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 gcc

• lsscsi：列出 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 install

• mhvtl-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) CAPACITY=2046 # Set default verbosity [0|1|2|3] VERBOSE=1 # Set kernel module debuging [0|1] VTL_DEBUG=0

CAPACITY=2046的含义是每盘磁带默认容量 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 Changer），tape是磁带机。/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 status

Storage Changer /dev/sg10:4 Drives, 43 Slots ( 4 Import/Export ) Data Transfer Element 0:Empty Data Transfer Element 1:Empty ... Storage Element 1:Full :VolumeTag=E01001L4 ... Storage Element 22:Full :VolumeTag=CLN101L4 Storage Element 30:Full :VolumeTag=F01030L5

Storage 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/st0

load 1 0把 1 号槽位的磁带加载到 0 号驱动器，相当于机械手抓带动作。tar -cvf /dev/st0 /boot把/boot目录写入磁带，c创建归档，v显示文件列表，f指定输出设备为 st0。写完必须mt rewind倒带，因为磁带写完后停在带尾，直接读会什么都读不到。tar -tvf列出带内内容，能看到文件就说明整条带库链路已经通了。

3. iSCSI 带库映射与 TSM 服务器端配置：让备份软件看到一个“真实”带库

3.1 用 tgt 把带库映射给 iSCSI

Mhvtl 装好之后，带库设备在 mhvtl 节点本地。要让 TSM 服务器能用上它，通常做法是装一个基于 tgt 的 iSCSI target，把带库的 sg 设备和 st 设备原样映射出去，TSM 服务器通过 iSCSI 登录后就能看到完整的机械手和磁带机，跟接了一台真实带库没有区别。

先装 tgt 服务端并编辑 targets 配置：

yum install scsi-target-utils vim /etc/tgt/targets.conf

include /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 </target>

• <target 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 --login

discovery用来发现带库节点上有哪些 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 -id=admin -password=admin

进入后是tsm: SERVER1>提示符，所有定义带库、卷、策略的命令都在这下面执行。如果密码忘了，可以用安装时的实例用户执行dsmadmc -id=admin -password=重置，这是 TSM 预留的本地认证通道，生产环境建议安装后立刻改掉默认密码。

3.3 定义带库设备：机械手与驱动器

TSM 把物理带库抽象成三层：library 对应机械手，drive 对应驱动器，path 把服务器和这些设备关联起来。在 dsmadmc 里执行：

define library L700TO type=scsi define path SERVER1 to L700TO srctype=server desttype=library device=/dev/sg10 define drive L700TO drive0 element=0 define path SERVER1 L700TO drive0 srctype=server desttype=drive library=L700TO device=/dev/st0

• define library ... type=scsi：声明一个 SCSI 带库，TSM 会通过机械手设备发送 SMC 指令；
• define path ... device=/dev/sg10：把 TSM 服务器和机械手设备路径绑定，这里的设备路径必须是 TSM 服务器本地lsscsi -g看到的路径；
• define drive ... element=0：element 号对应mtx status里 Data Transfer Element 的编号，第一个驱动器是 0；
• 最后一条 path 把服务器和驱动器绑定，library=L700TO指定它归属于哪个带库，device=/dev/st0是磁带机设备路径。

这里最容易踩的坑是 library 名和实际带库型号混用。Mhvtl 节点上两个机械手一个是 STK L700、一个是 STK L80，TSM 里定义两个 library 时命名要能区分，我习惯直接叫L700TO和L80TO，避免后面定义卷时对着名字发呆。

3.4 配置卷、备份策略与本地磁盘备份池

带库设备定义完成后，还要让 TSM 知道“磁带”的容量规格和卷标签。Mhvtl 模拟的是 LTO 驱动器，所以设备类按 LTO 定义：

define devclass LTO5LG devtype=LTO library=L700TO format=drive define volume L700TO E01001L4 define volume L700TO F01030L5

• devtype=LTO告诉 TSM 这是 LTO 设备类，后面建存储池时直接引用；
• format=drive表示容量格式由驱动器协商决定，不做强制覆盖；
• define volume定义带库里的卷，卷标签必须和mtx status里已存在的 VolumeTag 一致，填一个不存在的标签，TSM 调用机械手抓带时会找不到介质。

卷有了，再建备份存储池和策略：

define stgpool BACKUPPOOL LTO5LG maxscratch=30 update copygroup STANDARD STANDARD STANDARD dest=BACKUPPOOL

BACKUPPOOL是备份数据最终落地的存储池，maxscratch=30表示允许 TSM 自动从带库抓取最多 30 盘空带作为临时卷。update copygroup把默认管理类的备份目标指向 BACKUPPOOL，这样客户端备份的数据默认进带库池。

TSM 还支持把备份池的数据再复制到磁盘池，这个设计在文档里叫本地磁盘备份。做法是先定义一个磁盘存储池，然后执行池间备份：

define stgpool DISKPOOL disk maxscratch=30 backup stgpool BACKUPPOOL DISKPOOL

backup 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 EOF

cat > /usr/tivoli/tsm/client/oracle/bin/dsi.opt <<EOF TDPO_NODE oracle TDPO_PSWDPATH /usr/tivoli/tsm/client/oracle/bin EOF

• NODE oracle：客户端节点名，必须和 TSM 服务器上注册的节点完全一致；
• TCPADDRESS指向 TSM 主服务器的 IP，也就是 192.168.81.7，不是 mhvtl 带库节点；
• TCPPORT 1500：TSM 默认开放 1500 端口接收客户端连接，改过端口的话这里要跟着改；
• TDPO_PSWDPATH指向存放 TDPO 密码文件的目录，RMAN 备份时 TSM 会从这里读节点密码。

节点要在服务器端先注册，才能在客户端发起备份。在 TSM 服务器上执行：

dsmc reg node oracle oracle123 dsmc query node

reg 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 API，dsi.opt里已经写好了节点名；
• backup database plus archivelog：备份整个数据库并附带归档日志，这是数据库在线备份的常规姿势，跑完后 TSM 会把数据写成带库上的卷。

备份发起后，在 TSM 服务器端可以实时看到任务状态和最终落卷情况：

q process q content BACKUPPOOL

q process显示正在执行的备份进程，能看到读写字节数；q content BACKUPPOOL列出存储池里已经写入的卷和数据对象，看到备份产生的新卷说明整条链路已经打通。到这一步，“客户端 → TSM 服务器 → 虚拟带库”的备份通路就算正式跑起来了。

5. TSM+Mhvtl 环境排查避坑：五个翻车现场

这套环境搭建过程中有一半时间花在排错上，而且很多错是重复出现的。以下五条按现象到解决的方式记录，每条都是我实际遇到过的。

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里看到一个卷被写了大量小对象，但备份进程反复换带，速度极慢，最后归档日志备份失败。

原因：默认CAPACITY=500，一盘磁带 500MB，Oracle 的归档日志和数据文件很快就把带写满了。TSM 通过设备类容量感知到卷满后会不断抓新卷，而虚拟带库换带本身有开销，整个备份就被拖垮了。

解决：修改/etc/mhvtl/mhvtl.conf里的CAPACITY=2046，重启 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 BACKUPPOOL

q 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 和 controlfile：

startup 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' scope=spfile; 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 取数据，核心验证动作换成本身的管理命令即可。希望帮到你。

本文还有配套的精品资源，点击获取