Oracle 19c RMAN恢复目录结构不一致解决方法
RMAN恢复中路径映射需注意:SETNEWNAME必须在RESTORE前显式指定并配合SWITCH;归档日志路径需提前建好或软链接;控制文件恢复后需CATALOGSTARTWITH重新扫描备份集;OMF启用时需停用或显式映射,注意优先级。这些环节贯穿恢复全流程,否则易报错。
restore时仍可能卡在ORA-01157或RMAN-06023错误上,错误提示往往不直接指出根本原因。下面几个关键点,是实战中必须盯紧的,每一条都直接关系到恢复能否顺利跑通。
SET NEWNAME 必须在 RESTORE DATABASE 前显式指定
RMAN不会自动识别路径变化,它默认沿用备份时记录的绝对路径(例如 +data/orcl/datafile/system.256.987654321),而目标机很可能未挂载ASM磁盘组,或对应目录根本不存在。如果遗漏set newname,就会卡在ora-01157或rman-06023上。

操作时需要注意:
- 先在源库查询真实路径:
SELECT FILE#, NAME FROM V$DATAFILE; - 在目标机提前创建统一根目录,例如
/u01/oradata/NEWDB/。 - RMAN中必须使用
RUN块逐个设置,不能只写一条:SET NEWNAME FOR DATAFILE 1 TO '/u01/oradata/NEWDB/system01.dbf';SET NEWNAME FOR DATAFILE 2 TO '/u01/oradata/NEWDB/sysaux01.dbf'; - 必须执行
SWITCH DATAFILE ALL;——这步才能真正将控制文件里记录的路径更新为新路径。 - 数据文件数量过多时,可用查询生成脚本:
SELECT 'SET NEWNAME FOR DATAFILE ' || FILE# || ' TO ''' || '/u01/oradata/NEWDB/' || SUBSTR(NAME, INSTR(NAME, '/', -1) + 1) || ''';' FROM V$DATAFILE;
归档日志路径不匹配会导致 RECOVER 失败
RECOVER DATABASE不会读取你修改过的LOG_ARCHIVE_DEST_1参数,它默认前往备份时归档日志存放的原始路径(比如/u01/app/oracle/archivelog)。如果目标机上该路径不存在或为空,就会报ORA-00308找不到归档。
实战中要注意:
- RMAN中没有
SET ARCHIVELOG DEST命令——直接执行会报错RMAN-00571。 - 修改参数必须进入SQL:数据库
MOUNT状态下运行ALTER SYSTEM SET log_archive_dest_1='LOCATION=/u01/app/oracle/archivelog' SCOPE=SPFILE;。 - 更稳妥的做法是:提前在目标机按照源库归档路径创建目录,哪怕只是软链接:
mkdir -p /u01/app/oracle/archivelog。 - 已存在的旧归档不会自动迁移,需手动复制过去;否则
RECOVER阶段会因缺少日志而中断。
控制文件重建或恢复后必须重扫描备份集
如果使用了RESTORE CONTROLFILE或CREATE CONTROLFILE,新控制文件中没有源库后续的备份记录,LIST BACKUP会返回空,RESTORE DATABASE找不到备份片,报RMAN-06023。
具体操作要点:
- 确认
DBID正确:SELECT DBID FROM V$DATABASE;,该值必须与RMAN中SET DBID设置的值一致。 - 强制RMAN重新加载磁盘上的备份信息:
CATALOG START WITH '/u01/backup/';(注意末尾斜杠)。 - 如果备份片存放在ASM,而目标机未挂载对应磁盘组,
CATALOG也会失败——需先挂载或改用文件系统路径存放备份。 CONFIGURE CONTROLFILE AUTOBACKUP ON默认开启,但自动备份可能落在$ORACLE_BASE/fast_recovery_area,升级后该目录常为空或权限不足,需通过V$RECOVERY_FILE_DEST确认。
OMF 启用时路径映射容易被忽略
源库启用了db_create_file_dest='+RECO',目标库却配成/u01/app/oracle/oradata/PROD,RMAN还原时仍会尝试写入ASM伪路径,报ORA-19573或ORA-19870。
操作上要留意:
- 优先停用OMF:
ALTER SYSTEM RESET db_create_file_dest SCOPE=SPFILE;,然后重启。 - 或者显式使用
db_file_name_convert映射路径:db_file_name_convert='/u01/old/db/','/u01/new/db/'。 - 注意优先级:
db_create_file_dest>db_file_name_convert,两者都设置时前者生效。 - 如果redo日志路径也不同,还需配置
log_file_name_convert,否则ALTER DATABASE OPEN RESETLOGS可能失败。
路径映射不是一次性配置,而是贯穿restore、recover、open全流程的连环动作。最容易被跳过的是归档路径准备和CATALOG START WITH,这两处一旦遗漏,整个恢复就会卡在“找不到东西”上,错误提示却不直接说清原因。
游乐网为非赢利性网站,所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系youleyoucom@outlook.com。
同类文章
SQL数据库视图简化开发人员编码的实用方法
视图适合封装固定逻辑(如固定时间窗口、静态状态过滤)和固定JOIN关系,不宜用于需动态传入参数(如用户ID、日期范围)的查询。视图性能取决于底层索引,而非视图本身。ALTERVIEW仅更新元数据,会短暂阻塞新查询启动,应避开高峰期操作。
MySQL decimal使用常见问题及解决方法
MySQL中的DECIMAL类型用于精确数值计算,通过DECIMAL(M,D)定义精度与标度。常见问题包括精度设置不当导致溢出、计算时精度溢出、插入格式错误等。优化建议:合理设置M和D,可用BIGINT存储分单位,关键列建索引,保持版本更新。
MySQL大字段TEXT建立索引导致的性能下降解决方案
TEXT字段无法直接建立常规B+树索引,前缀索引不支持左模糊查询,全文索引受词长、中文分词和更新延迟限制。高效替代方案是使用MD5摘要索引和垂直拆分,将TEXT字段分离到独立表,主表采用DYNAMIC行格式,避免溢出页IO问题。
金仓数据库迁移避坑指南:从未被质疑的左连接隐患
迁移至金仓KES时,LEFTJOIN若在WHERE中过滤右表非空列,将会触发外连接消除,导致数据结果减少。正确做法是将过滤条件置于ON子句中。金仓KES与主流数据库行为一致,务必通过EXPLAIN仔细检查执行计划,以确保连接语义正确。
PostgreSQL与MySQL数据库日志机制深度对比
PostgreSQL仅使用一套WAL日志,就同时实现了MySQL的redo、binlog和undo的全部功能,而MySQL因插件式架构需要三套日志并依赖两阶段提交保证一致性。其多版本并发控制通过追加写实现,无需单独的undo日志,但需要定期执行VACUUM操作清理死元组,防止表膨胀。
- 热门数据榜
相关攻略
2026-07-18 22:24
2026-07-18 22:22
2026-07-18 22:22
2026-07-18 22:22
2026-07-18 22:22
2026-07-18 22:05
2026-07-18 22:05
2026-07-18 22:05
热门教程
- 游戏攻略
- 安卓教程
- 苹果教程
- 电脑教程

