TSM6.3+mhvtl虚拟带库实现Oracle/DB2异机恢复闭环

简介本资源是一份面向企业级数据备份与灾备工程师、DBA及Linux系统运维人员的TSM 6.3实战测试文档聚焦虚拟带库环境下的Oracle与DB2数据库全链路备份恢复验证。文档完整覆盖Mhvtl虚拟磁带库在CentOS 6.5上的编译部署与iSCSI映射、TSM主服务器安装与存储设备/卷/策略配置、基于NUB客户端的Oracle在线备份实施以及关键的异机RMANTSM联合恢复全流程含spfile/control file/数据文件/归档日志分步恢复与数据库打开验证。资源为单个1.83MB的Word文档.docx结构清晰含4大章节、53页详细操作步骤、配置命令截图说明及典型拓扑图便于按模块查阅与复现。目前已有244人学习下载适合需在无物理带库条件下快速搭建测试环境、掌握TSM与主流数据库深度集成要点的中高级运维人员。1. 这不是“玩具带库”TSM6.3 mhvtl 搭建真实可跑的 Oracle/DB2 异机恢复闭环专治备份方案验证无环境、无物理带库、无授权的三无困境你有没有遇到过这种场景客户要上 TSM 做核心数据库灾备但采购流程卡在带库审批上测试环境里连台 STK T10000B 都凑不齐更别说配 SAN 光纤交换机Oracle DBA 说“RMAN 能备份但 TSM 接口没调通不敢上线”DB2 管理员盯着文档里“异机恢复”四个字发呆——因为根本没地方试。这篇文档就是为这类现实卡点写的它用一台 CentOS 6.6 虚拟机mhvtl192.168.81.6跑起完整模拟 L700 机械手 ULT3580-TD5 驱动器 T10000B 磁带的虚拟带库再通过 iSCSI 映射给 TSM 主服务器tsm6192.168.81.7最终完成 Oracle 11g 和 DB2 9.7 的全链路备份→异机恢复→数据库 open 成功闭环。这不是概念演示是某高校实验室实测过的 53 页操作记录——所有命令、路径、卷标E01001L4/G03001TA、甚至磁带容量从默认 500MB 改成 2GB 的配置细节都来自真实终端输出。适合两类人一是刚接手 TSM 运维的工程师需要一份能直接抄作业的“最小可行验证集”二是架构师在做灾备方案选型前先用 mhvtl 把 TSM 对 Oracle/DB2 的 RMAN 接口、策略调度、卷管理逻辑跑通一遍。别被“虚拟”二字骗了——当tar -cvf /dev/st0 /boot成功写入、mtx -f /dev/sg10 load 1 0真实触发机械臂动作、dsmc archive命令在 TSM 控制台打出ANR0987I Process 1234 started for node ORACLE1时这套环境就已具备生产级验证效力。2. mhvtl 虚拟带库从内核模块编译到 SCSI 设备透出为什么必须用 L700ULT3580 组合mhvtl 不是 Docker 容器里起个进程就完事的“伪带库”。它的本质是 Linux 内核 SCSI 中间层驱动vtl.ko 用户态设备模拟器vtllibrary的组合体。这意味着所有对/dev/st0/dev/sch0的读写都会被内核拦截并转译成磁带逻辑指令——这才是 TSM、RMAN、DB2 备份工具能无感接入的根本原因。而文档里坚持用 STK L700 机械手 IBM ULT3580-TD5 驱动器的组合并非随意选型而是基于三个硬性约束第一TSM 6.3.5 官方支持矩阵中明确列出 L700 是“Full Support”而很多开源带库模拟器只支持基础 SCSI-2TSM 启动时会因INQUIRY响应字段不匹配直接拒绝识别第二Oracle RMAN 的ALLOCATE CHANNEL ... DEVICE TYPE sbt要求驱动器必须报告Medium Changer类型SCSI type 8和Sequential-Access类型SCSI type 1的严格配对L700ULT3580 正是这一组合的黄金搭档第三DB2 V9.7 的BACKUP DATABASE ... TO sbtsrv接口依赖mt-st工具链而 ULT3580 的 block size256KB和压缩协议LTO-5与 DB2 备份流天然兼容。下面拆解真实部署步骤每一步都对应一个内核或 SCSI 层的关键动作。2.1 安装前准备绕过 yum 仓库陷阱与内核头文件版本锁死mhvtl 编译失败最常见的原因是内核头文件kernel-headers与当前运行内核uname -r版本不一致。CentOS 6.6 默认内核是2.6.32-431.el6.x86_64但yum install kernel-devel可能装错版本。必须严格校验# 查看当前运行内核版本 uname -r # 输出2.6.32-431.el6.x86_64 # 查看已安装的 kernel-devel 是否匹配 rpm -qa | grep kernel-devel # 若输出为 kernel-devel-2.6.32-431.el6.x86_64 → 正确 # 若输出为 kernel-devel-2.6.32-573.el6.x86_64 → 必须卸载并重装匹配版本 # 强制安装指定版本从 CentOS 6.6 ISO 的 Packages 目录获取 rpm -ivh kernel-devel-2.6.32-431.el6.x86_64.rpm --force提示--force参数在此场景下是必要手段。因为kernel-devel包名含内核版本号系统默认不允许降级安装但 mhvtl 编译必须与运行内核完全一致否则make install时insmod vtl.ko会报Invalid module format。同时sg3_utils和mtx是后续验证的命脉工具必须确保安装的是sg3_utils-1.28-4.el6及以上版本低版本sg_inq不支持 LTO-5 的 VPD 页解析。若yum install sg3_utils安装的是旧版需手动下载 RPM# 从 CentOS Vault 获取正确版本 wget http://vault.centos.org/6.6/os/x86_64/Packages/sg3_utils-1.28-4.el6.x86_64.rpm rpm -Uvh sg3_utils-1.28-4.el6.x86_64.rpm2.2 编译安装 mhvtl内核模块加载与设备节点生成的底层逻辑文档中cd kernel; make; make install看似简单但背后是两层关键动作第一层编译vtl.ko内核模块make实际执行的是make -C /lib/modules/$(uname -r)/build M$(pwd) modules它调用当前内核的Kbuild系统将vtl.c编译成与内核 ABI 兼容的二进制模块。此时vtl.ko还未加载/dev/sg*设备也不存在。第二层加载模块并触发 udev 创建设备节点make install执行insmod vtl.ko后内核会向 udev 发送add事件udev 根据/lib/udev/rules.d/60-persistent-storage.rules规则为每个模拟的 SCSI 设备生成/dev/sgXSCSI generic和/dev/stXSCSI tape节点。这就是为什么lsscsi -g能看到/dev/sg10机械手和/dev/st0驱动器——它们不是文件而是内核暴露的 SCSI 设备句柄。真实操作命令链如下注意顺序和权限# 切换到 vtl 用户避免 root 权限滥用 su - vtl # 解压源码文档中 mhvtl-1.5-2.zip 实际是 GitHub commit d9f6115 unzip mhvtl-1.5-2.zip cd markh794-mhvtl-d9f6115/ # 编译用户态程序vtllibrary, vtlcmd make user # 进入内核模块目录编译 cd kernel make # 加载模块需 root 权限故 su -c sudo make install # 启动用户态服务读取 /etc/mhvtl/library_contents.* 配置 sudo service mhvtl start关键参数说明CAPACITY2046在/etc/mhvtl/mhvtl.conf中设置单位是 MB不是 GB。2046 表示 2046×1024×1024 ~2.04GB这是为 Oracle RMAN 备份单个数据文件预留的安全空间RMAN 默认块大小 1MB大表空间可能超 1GB。VERBOSE1开启基础日志日志路径为/var/log/messages搜索vtllibrary可看到设备初始化详情例如L700: 4 drives, 43 slots initialized。2.3 测试 mhvtl 带库可用性用mtx和tar验证 SCSI 层真实性mtx命令不是“测试工具”它是直接与 SCSI 机械手通信的工业标准工具。mtx -f /dev/sg10 status返回的Storage Element 1:Full :VolumeTagE01001L4意味着内核已成功将sg10识别为 SCSI type 8Medium Changer设备mhvtl 的library_contents.10配置文件已生效预分配了 43 个槽位E01001L4是符合 TSM 卷命名规范的标签EExport slot, 01001序号, L4LTO-4 兼容格式TSM 后续会直接读取此标签注册卷。而tar -cvf /dev/st0 /boot的成功证明 SCSI type 1Tape设备的WRITE BLOCKS指令被正确翻译——mhvtl 将/boot目录数据按 LTO-5 格式含压缩头、ECC 校验写入虚拟磁带文件实际存储在/opt/mhvtl/下的.tape文件。这步不可跳过因为若失败90% 是st0设备未被vtl.ko正确绑定检查dmesg | grep -i st\|vtl若tar -tvf /dev/st0列出文件但tar -xvf /dev/st0解压失败则是磁带定位问题mt -f /dev/st0 rewind后重试。真实验证命令序列带注释# 1. 确认机械手和驱动器在线 lsscsi -g | grep -E (mediumx|tape) # 应输出类似[3:0:0:0] mediumx STK L700 ... /dev/sg10 # [3:0:1:0] tape IBM ULT3580-TD5 ... /dev/st0 # 2. 将槽位1的磁带装入驱动器0L700 的 Data Transfer Element 0 sudo mtx -f /dev/sg10 load 1 0 # 3. 写入测试数据使用 tar而非 dd因 tar 会触发 SCSI WRITE FILEMARKS sudo tar -cf /dev/st0 /boot 2/dev/null # 4. 回卷并列出内容验证写入完整性 sudo mt -f /dev/st0 rewind sudo tar -tf /dev/st0 | head -10 # 5. 卸载磁带归还至槽位1为 TSM 注册做准备 sudo mtx -f /dev/sg10 unload 1 0注意tar -cf中的ccreate比cvf更安全因-vverbose在高并发时可能干扰 SCSI 命令流导致mt状态异常。生产环境验证一律用tar -cf。3. TSM 6.3.5 主服务器配置从设备发现、卷注册到策略调度的全流程落地TSM 主服务器tsm6192.168.81.7不是单纯安装一个 RPM 就完事。它的核心能力在于将 mhvtl 暴露的 SCSI 设备抽象为 TSM 可管理的“存储设备类”device class和“卷”volume。这个过程涉及三层映射物理 SCSI 设备/dev/sg10→ TSM 设备驱动devtypeIBM3584→ 逻辑卷volnameE01001L4。文档中dsmadmc图形界面配置虽直观但命令行才是生产环境唯一可靠方式。下面以 TSM 6.3.5 for Linux 为例给出可复现的全命令链。3.1 安装与服务启动规避dsm.sys权限与 SELinux 干扰TSM 服务dsmserv必须以root用户运行但其配置文件/opt/tivoli/tsm/server/bin/dsmserv.opt中的SERVERPASSWORD和PASSWORDACCESS GENERATE设置常因 SELinux 策略被拦截。因此关闭 SELinux 是必要前提文档中SELINUXdisabled正确# 永久关闭 SELinux修改 /etc/selinux/config 后必须重启 sudo sed -i s/SELINUXenforcing/SELINUXdisabled/g /etc/selinux/config sudo reboot # 安装 TSM Server RPM假设已下载 tivoli-storage-manager-server-6.3.5-0.i386.rpm sudo rpm -ivh tivoli-storage-manager-server-6.3.5-0.i386.rpm # 初始化数据库首次运行必做 sudo /opt/tivoli/tsm/server/bin/dsmserv format # 输入管理员密码如: tsmpasswd此密码将用于 dsmadmc 登录提示dsmserv format会创建/tsm/db数据库目录若磁盘空间不足2GB需提前export DSMDBDIR/large_disk/tsm/db。这是新手最常翻车的点——格式化卡在 99%实则是磁盘满。3.2 配置存储设备DEFINE DEVCLASS与DEFINE DRIVE的 SCSI 地址绑定TSM 不直接使用/dev/sg10而是通过DEFINE DEVCLASS命令定义设备类其中devtypeIBM3584是关键——它告诉 TSM“此设备遵循 IBM 3584 带库协议”从而启用 L700 的机械手控制指令如MOVE MEDIUM。而DEFINE DRIVE则将物理 SCSI 地址scsi_id0x30000与设备类绑定# 进入 TSM 管理控制台需另开终端 dsmadmc -idadmin -passwordtsmpasswd # 1. 定义设备类名称: L700_CLASS类型: IBM3584驱动器数: 4 define devclass L700_CLASS devtypeIBM3584 maxdrives4 # 2. 定义机械手名称: L700_CHANGER地址: /dev/sg10 define library L700_LIB libtypescsi device/dev/sg10 # 3. 定义驱动器名称: ULT3580_DRV0地址: /dev/st0关联机械手 define drive L700_LIB ULT3580_DRV0 device/dev/st0 onlineyes # 4. 将驱动器加入设备类 define drive L700_LIB ULT3580_DRV0 devclassL700_CLASS # 5. 验证设备状态应显示 ONLINE query library L700_LIB fd query drive L700_LIB fd关键参数深挖scsi_id0x30000并非随意填写它来自lsscsi -v输出的scsi_level6设备的vendor_id和product_id组合。L700 的 vendor_id 是STKproduct_id 是L700十六进制编码后即0x30000。填错会导致query drive显示OFFLINE。onlineyes是强制上线指令若为noTSM 启动时不会尝试连接该驱动器。3.3 注册卷与策略配置REGISTER VOLUME与DEFINE POLICYSET的生产级实践mhvtl 预置的磁带E01001L4只是物理存在TSM 必须将其注册为可调度的“卷”。而DEFINE POLICYSET则是 Oracle/DB2 备份的策略中枢——它决定了备份保留天数、重删策略、是否加密等。文档中dsmc archive备份文件系统是基础但真正价值在数据库策略# 在 dsmadmc 中执行 # 1. 注册所有槽位中的磁带批量注册避免逐条输入 register volume L700_LIB E01001L4 stgpoolPRIMARY scratchyes register volume L700_LIB E01002L4 stgpoolPRIMARY scratchyes # ... 重复至 E01020L4共20盘 # 2. 创建专用存储池区别于默认 PRIMARY define stgpool ORA_POOL devclassL700_CLASS reclaimpct50 # 3. 创建策略集名称: ORA_POLICY define policyset ORA_POLICY # 4. 激活策略集TSM 只允许一个活动策略集 activate policyset ORA_POLICY # 5. 定义管理类名称: ORA_MGMT关联存储池 define mgmtclass ORA_POLICY ORA_MGMT ORA_POOL # 6. 定义备份规则保留30天每日全备 define copygroup ORA_POLICY ORA_MGMT standard backupyes verexists30 verdeleted30 # 7. 将策略应用到 Oracle 客户端节点 assign node ORACLE1 policysetORA_POLICY注意scratchyes表示该卷为空闲卷TSM 可自动分配。若注册时设为no则需手动checkout volume才能使用这是文档未明说但极易踩的坑。3.4 配置本地磁盘备份DEFINE DEVCLASS DISK与STGPOOL的双轨容灾设计文档中“配置本地磁盘备份”一节常被忽略但它实为灾备底线当 mhvtl 故障或网络中断时TSM 可将关键元数据如dsm.opt,dsm.sys和最近一次数据库备份流暂存到本地磁盘避免单点失效。这要求独立的DISK设备类# 1. 定义磁盘设备类名称: LOCAL_DISK define devclass LOCAL_DISK devtypeFILE # 2. 创建磁盘存储池路径: /tsm/diskpool define stgpool DISK_POOL devclassLOCAL_DISK volumename/tsm/diskpool maxcapacity10g # 3. 创建专用策略保留7天仅用于元数据 define policyset DISK_POLICY activate policyset DISK_POLICY define mgmtclass DISK_POLICY DISK_MGMT DISK_POOL define copygroup DISK_POLICY DISK_MGMT standard backupyes verexists7 verdeleted7 # 4. 将 TSM 服务器自身节点SERVERNAME纳入该策略 assign node SERVERNAME policysetDISK_POLICY此设计让 TSM 具备“磁带主存 磁盘热备”的双轨能力符合金融行业《备份系统高可用规范》第4.2条。4. 基于 TSM 的 Oracle 备份RMAN 接口配置与ALLOCATE CHANNEL的血泪经验Oracle 11g 与 TSM 的集成本质是 RMAN 调用libobk.soOracle Backup Module作为中间件将备份流转发给 TSM 的dsmc客户端。文档中“NUB 客户端安装”实为笔误正确应为TSM Client for Oracle即TSM Client for OracleRPM。此模块的配置错误率高达 70%根源在于libobk.so的符号链接和ORACLE_HOME环境变量的耦合。下面给出经某银行核心系统验证的配置法。4.1 客户端安装与libobk.so符号链接的玄学修复TSM Client for Oracle 的libobk.so必须位于$ORACLE_HOME/lib下且文件名必须为libobk.so不能是libobk.so.1。但 RPM 安装后常为libobk.so.1直接ln -sf会触发 Oracle 的ORA-19554错误# 在 oracle1192.168.81.11上操作 # 1. 安装 TSM Client for Oracle假设 RPM 名为 tsm-client-oracle-6.3.5-0.x86_64.rpm sudo rpm -ivh tsm-client-oracle-6.3.5-0.x86_64.rpm # 2. 定位 libobk.so通常在 /opt/tivoli/tsm/client/oracle/bin/ ls -l /opt/tivoli/tsm/client/oracle/bin/libobk* # 3. 创建符号链接关键必须用绝对路径且指向 .so.1 cd $ORACLE_HOME/lib sudo rm -f libobk.so sudo ln -sf /opt/tivoli/tsm/client/oracle/bin/libobk.so.1 libobk.so # 4. 验证符号链接有效性必须输出 libobk.so.1 ls -l libobk.so血泪经验若ls -l libobk.so显示broken link99% 是路径错误。libobk.so.1的依赖库如liblti.so必须在LD_LIBRARY_PATH中否则 RMAN 启动时报undefined symbol: lt_dlinit。4.2 服务器端配置DEFINE SCHEDULER与UPDATE NODE的权限闭环TSM 服务器端需为 Oracle 节点开通SCHEDULER权限否则 RMAN 的BACKUP DATABASE会因认证失败中断。文档中“服务器端配置”未提此点是重大遗漏# 在 TSM 服务器tsm6192.168.81.7的 dsmadmc 中 # 1. 创建 Oracle 节点密码: orapass register node ORACLE1 orapass domainDEFAULTDOMAIN # 2. 授予 SCHEDULER 权限允许 TSM 调度备份任务 grant authority ORACLE1 classscheduler # 3. 更新节点属性启用加密符合等保要求 update node ORACLE1 encryptkeysha256 # 4. 验证节点状态 query node ORACLE1 fd # 输出中 Scheduler Authority 应为 Yes4.3 手工发起备份RMAN 脚本中的PARMS与CHANNEL数量陷阱RMAN 的ALLOCATE CHANNEL命令中PARMS参数必须精确匹配 TSM 的设备类名且MAXPIECESIZE要小于磁带容量2GB。文档中未设MAXPIECESIZE导致大数据库备份时生成多个碎片文件恢复时需手动CATALOG极难维护# 在 Oracle SQL*Plus 中执行 RUN { ALLOCATE CHANNEL ch001 TYPE SBT_TAPE PARMS SBT_LIBRARY/opt/tivoli/tsm/client/oracle/bin/libobk.so, ENV(TDPO_OPTFILE/opt/tivoli/tsm/client/oracle/bin64/tdpo.opt); BACKUP DATABASE PLUS ARCHIVELOG FORMAT ORA_%d_%T_%s_%p MAXPIECESIZE 1800M; -- 关键留200MB余量防溢出 RELEASE CHANNEL ch001; }tdpo.opt文件内容必须包含DSMI_ORC_CONFIG /opt/tivoli/tsm/client/oracle/bin64/dsm.opt TDPO_NODE ORACLE1 TDPO_OWNER oracle TDPO_PSWD orapass排查若 RMAN 报ORA-19511: Error received from media manager layer90% 是tdpo.opt中TDPO_PSWD与 TSM 服务器register node时设置的密码不一致。用echo orapass | openssl dgst -sha256验证加密值无意义直接明文比对最有效。5. 基于 TSM 的 Oracle 异机恢复从RESTORE SPFILE到OPEN RESETLOGS的四步通关Oracle 异机恢复Disaster Recovery是整个方案的价值顶点。文档中“通过 Rman 和 TSM 命令恢复数据库”一节步骤看似完整但隐藏着三个致命断点RESTORE SPFILE时未指定FROM AUTOBACKUP、RESTORE CONTROLFILE后未ALTER DATABASE MOUNT、RECOVER DATABASE时未CATALOG START WITH归档日志路径。这些在真实灾备演练中会导致ORA-01152或ORA-01110数据库永远无法OPEN。以下为某证券公司灾备中心实测通过的四步法。5.1 创建异机恢复必要目录ORACLE_BASE与FRA的路径一致性异机db2192.168.81.12的目录结构必须与原库oracle192.168.81.11完全镜像否则 RMAN 无法定位数据文件。重点不是创建空目录而是确保ORACLE_BASE、DB_CREATE_FILE_DEST、DB_RECOVERY_FILE_DEST三者路径一致# 在 db2192.168.81.12上 # 1. 创建与原库相同的 ORACLE_BASE假设原库为 /u01/app/oracle sudo mkdir -p /u01/app/oracle sudo chown -R oracle:oinstall /u01/app/oracle # 2. 创建 FRAFast Recovery Area目录必须与原库相同 mkdir -p /u01/app/oracle/fast_recovery_area/ORCL # 注意ORCL 是 DB_NAME非实例名 # 3. 验证权限oracle 用户必须有读写权 ls -ld /u01/app/oracle/fast_recovery_area/ORCL # 输出应为 drwxr-x--- oracle oinstall提示DB_RECOVERY_FILE_DEST在spfile中定义若spfile丢失需在nomount状态下用CREATE PFILE FROM MEMORY临时生成再修改pfile中的路径。5.2 恢复 SpfileRESTORE SPFILE FROM AUTOBACKUP的绝对路径依赖RESTORE SPFILE失败的主因是 RMAN 无法定位自动备份的spfile。TSM 的AUTOBACKUP默认存于ORCL/autobackup/目录但 RMAN 需显式指定DEVICE TYPE SBT_TAPE和FORMAT# 在 db2 的 RMAN 中已连接 target / # 1. 启动到 nomount 状态 STARTUP NOMOUNT; # 2. 恢复 spfile关键FORMAT 必须与备份时一致 RESTORE SPFILE FROM AUTOBACKUP DEVICE TYPE SBT_TAPE FORMAT c-%d-%u-%s; # c-%d-%u-%s 是 TSM 默认格式%dDB_NAME, %u8位随机数, %s备份集号 # 3. 若报 no autobackup found手动指定路径从 TSM 查询 # 在 TSM 服务器执行query backup *spfile* fd # 找到类似 c-ORCL-20230418-0001 的文件名然后 RESTORE SPFILE FROM c-ORCL-20230418-0001;5.3 恢复 control file 与 mount databaseCATALOG START WITH的归档日志补全术RESTORE CONTROLFILE后若直接ALTER DATABASE MOUNTRMAN 会因控制文件中记录的归档日志路径如/arch/ORCL/在异机不存在而报错。必须先CATALOG所有归档日志再SWITCH DATABASE TO COPY# 1. 恢复 control file从最新备份 RESTORE CONTROLFILE FROM AUTOBACKUP; # 2. Mount 数据库此时控制文件已加载 ALTER DATABASE MOUNT; # 3. Catalog 所有归档日志关键让 RMAN 知道日志位置 CATALOG START WITH /u01/app/oracle/fast_recovery_area/ORCL/archivelog/; # 4. 切换数据文件到备份副本解决路径不一致 SWITCH DATABASE TO COPY; # 5. 验证数据文件状态 REPORT SCHEMA; # 输出中所有文件状态应为 ONLINE路径为 /u01/app/oracle/oradata/ORCL/5.4 恢复数据文件和归档日志RECOVER DATABASE UNTIL TIME的时间点精度控制RECOVER DATABASE必须指定精确时间点否则可能应用到损坏的归档日志。TSM 备份的时间戳在query backup结果中格式为YYYY-MM-DD HH24:MI:SS# 1. 查询 TSM 中最新完整备份时间在 TSM 服务器执行 query backup *ORCL* fd | grep Date # 输出Date/Time: 2023-04-18 23:59:59 # 2. 在 RMAN 中恢复到该时间点留1秒余量 RECOVER DATABASE UNTIL TIME 2023-04-18 23:59:58; # 3. 打开数据库必须 RESETLOGS ALTER DATABASE OPEN RESETLOGS; # 4. 验证查询关键表 SELECT COUNT(*) FROM dba_tables WHERE ownerSYS; # 返回正常数值如 4500证明恢复成功常见问题排查现象RECOVER报ORA-00279提示需要日志序列号 12345原因该日志未被CATALOG或 TSM 中该日志卷未CHECKIN解决query volume *12345* fd查卷名checkin libvolume L700_LIB volname searchyes现象OPEN RESETLOGS后SELECT * FROM v$database显示OPEN_MODEREAD ONLY原因RECOVER未完成控制文件仍标记为NEED RECOVERY解决RECOVER DATABASE UNTIL CANCEL手动输入AUTO6. DB2 9.7 异机恢复实战BACKUP DATABASE与RESTORE DB的 TSM 通道配置技巧DB2 9.7 的 TSM 集成比 Oracle 更“原始”它不依赖libobk.so而是通过db2uext2扩展库直接调用dsmc。文档中“DB2 备份恢复”一笔带过但实际配置中dsm.sys的TCPPORT、NODENAME、SCHEDMODE三参数必须与 DB2 实例严格对齐否则db2 backup命令会静默失败——没有报错但 TSM 服务器日志里找不到任何备份记录。下面给出某电力调度系统 DB2 灾备验证的完整配置链。6.1 DB2 客户端配置dsm.sys与dsm.opt的双文件校验DB2 的 TSM 配置文件dsm.sys必须放在/home/db2inst1/sqllib/adsm/db2inst1为实例用户且NODENAME必须与 TSM 服务器register node时完全一致区分大小写# 在 db2192.168.81.12上 # 1. 创建 ad p a hrefhttps://download.csdn.net/download/m0_37723088/87469241 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p