Oracle 12c RAC环境下RMAN恢复共享数据文件
在RAC环境下使用RMAN恢复共享数据文件,很多DBA第一次遇到时都会感到棘手:备份文件明明完整,执行RESTORE DATABASE却报ORA-01102或ORA-01507。别紧张,这并非命令错误,而是RAC的共享存储与多实例并发机制与RMAN恢复流程存在根本性的不兼容。

RMAN在RAC下无法直接restore/recover共享数据文件——必须走异机单实例恢复路径
RAC的OCR、ASM以及集群心跳机制,与RMAN独占挂载的要求之间存在直接冲突。RMAN恢复过程默认要求数据库处于NOMOUNT或MOUNT独占状态,而RAC实例之间无法协调这种独占操作。因此,不要幻想在原集群上随便停一个实例、再启动另一个就能完成恢复——即便只保留一个实例、其他全停,ASM磁盘组未卸载、voting disk锁争用,同样会导致恢复卡死。
真正可行的起点是:完全脱离RAC环境,在一台干净的Linux主机上安装同版本Oracle(例如12.1.0.2),不配置集群软件,不启动CRS。这一步很多人嫌麻烦,但缺少它,后面全是坑。
RMAN restore database在RAC中报ORA-01102或ORA-01507怎么办
这是最典型的误操作信号:在RAC节点上执行RESTORE DATABASE或RECOVER DATABASE,结果数据库无法启动,提示“cannot mount database in EXCLUSIVE mode”(ORA-01102)或“database not mounted”(ORA-01507)。
- 不要在原有RAC集群的任何节点上尝试
STARTUP MOUNT后恢复;那样只会卡死或触发OCR报错 - 即便只启动一个实例、其他实例全部停止,仍可能因ASM diskgroup未dismount或voting disk锁争用而失败
- 真实可行的起点是:完全脱离RAC环境,在一台干净的Linux主机上安装同版本Oracle(如12.1.0.2),不配集群软件,不启CRS
为什么不能用RMAN recover table恢复RAC中误删的表
RECOVER TABLE命令在RAC下直接失效,这不是配置问题,而是架构级的不可兼容。它底层依赖自动创建的辅助实例(auxiliary instance),而该实例必须是单机、非ASM、本地文件系统加独立监听的常规数据库。RAC的OCR注册、ASM磁盘组挂载、集群心跳机制会直接阻止该辅助实例正常启动。
- 执行时大概率报
ORA-19566: exceeded limit of 0 corrupt blocks for file或静默失败 - 即使手动指定
AUXILIARY DESTINATION,RMAN仍会试图在当前节点本地启动库,而非真正隔离环境 - 对PDB内的表同样无效——必须连
CDB$ROOT才能调用该命令,但RAC的CDB启动模式本身就不满足辅助实例的要求
异地恢复时controlfile和DBID不匹配导致restore失败
异机恢复第一步就卡在RESTORE CONTROLFILE?十有八九是SET DBID没设,或设错了。RAC的v$database.dbid是全局唯一值,但不同RAC实例查出来的DBID完全一致——你必须从任意一个在线节点查询,例如:
SQL> SELECT dbid FROM v$database;
然后在RMAN连接后第一句就必须执行:
RMAN> SET DBID 1234567890;
- 漏掉这句,
RESTORE CONTROLFILE FROM 'xxx'会报RMAN-06023: no backup or copy of control file found,即使备份文件物理存在 - 控制文件必须从RMAN备份中还原,不能使用
BACKUP CONTROLFILE TO TRACE生成的SQL脚本——trace文件不含归档日志序列链,后续RECOVER DATABASE必然会中断 - 确认备份片中确实有控制文件:使用
LIST BACKUP OF CONTROLFILE检查,并确保该备份是在表空间删除之前创建的
recover database until time卡住,提示archived log not found
这几乎必然是归档日志没有拷贝完整。RAC每个实例(thread)都独立生成归档,例如两节点RAC就有thread 1和thread 2两套归档序列。你只拷贝了node1的归档(/arch1/),却没有拷贝node2的(/arch2/),RECOVER DATABASE UNTIL TIME就会在读到thread 2的第一个缺失归档时挂住,报类似:
archived log for thread 2 with sequence 45678 not found
- 必须将所有实例的归档日志(包括thread 1/2/…)全部拷贝到目标机同一目录下,例如
/backup/arch/ - 在RMAN中注册:
CATALOG START WITH '/backup/arch/'; - 检查是否识别完整:
LIST ARCHIVELOG ALL;应该看到所有thread的连续序列 - 如果某thread的归档确实缺失,只能退回到该thread最后一个可用归档的时间点做不完全恢复,数据会存在少量丢失
关键点常被忽略:RAC异地恢复不是“把备份拷过去run一下”,而是重建一套时间点一致的只读副本;所有路径映射、DBID、归档完整性、参数文件中db_file_name_convert的ASM到本地路径转换,缺一不可。任何一步跳过验证,都会在recover阶段爆发问题。
游乐网为非赢利性网站,所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系youleyoucom@outlook.com。
同类文章
如何配置Oracle可恢复空间分配以防止任务中断
启用可恢复空间分配需将RESUMABLE_TIMEOUT设为非零值(如3600秒),RAC环境需逐节点单独设置。该机制仅对ORA-01536等空间类错误生效,挂起期间事务锁定状态不变,超时自动中止。会话级启用需显式指定timeout和name,否则可能无效。
Redis集群升级配置文件不兼容 对照新旧参数手册转换
升级至Redis7 0配置不兼容须知:主从复制命令由slaveof改为replicaof否则报错;集群全量覆盖参数默认开启需改为关闭;TCP连接积压参数需与系统内核一致;访问控制列表默认用户无管理权限需授权;节点配置文件禁止手动编辑,应通过命令管理。
Oracle 19c补丁冲突问题修复方法详细步骤使用opatch apply命令
Oracle19c补丁冲突因新旧补丁修复重叠或文件冲突所致。需先确认OPatch版本、inventory一致性及执行用户正确性,再通过opatchprereq定位具体冲突。真实冲突可回退旧补丁或改用完整RU流程,RAC环境需逐节点检查inventory。
MySQL修改权限后为何必须执行FLUSH PRIVILEGES?
MySQL修改权限后是否执行FLUSHPRIVILEGES取决于修改方式。通过GRANT或ALTERUSER标准命令自动同步,无需手动刷新;直接UPDATEmysql user表则必须执行以刷新内存缓存。已存在连接不重载,需注意host匹配、认证插件兼容性及RELOAD权限。
SQL嵌套查询在电商订单报表中的应用实践
SQL嵌套查询在电商订单报表中适用于条件筛选,如快速圈定用户范围,但不适合替代关联分析。使用时需注意子查询空值导致IN失效、必须返回单列、MySQL5 7不支持LATERAL及CTE。聚合分析应依赖聚合加过滤,深层嵌套可用派生表或CTE分步处理。
- 日榜
- 周榜
- 月榜
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10
相关攻略
2026-07-09 07:09
2026-07-09 07:09
2026-07-09 07:08
2026-07-09 07:08
2026-07-09 07:08
2026-07-09 07:08
2026-07-09 07:08
2026-07-09 07:07
热门教程
- 游戏攻略
- 安卓教程
- 苹果教程
- 电脑教程
热门话题

