ORA-06054探究

本文讨论了Oracle数据库在异机恢复过程中遇到的ORA-06054错误,详细介绍了错误产生的原因,提供了从源机器复制redo日志文件至目标机器并进行恢复的步骤,最终通过resetlogs命令成功打开数据库的方法。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

ORA-06054异机恢复经典的错误,06054找的是current redo也就是备份完成那一时刻的current 状态的在线日志,

RMAN是不备份online redo log的,所以恢复也不恢复redo

[oracle@guo PROD2]$ ll

total 1762996

-rw-r----- 1 oracle oinstall 9748480 Jun 9 14:52 control01.ctl

-rw-r----- 1 oracle oinstall 362422272 Jun 9 14:45 example01.dbf

-rw-r----- 1 oracle oinstall 576724992 Jun 9 14:45 sysaux01.dbf

-rw-r----- 1 oracle oinstall 754982912 Jun 9 14:45 system01.dbf

-rw-r----- 1 oracle oinstall 94380032 Jun 9 14:45 undotbs01.dbf

-rw-r----- 1 oracle oinstall 5251072 Jun 9 14:45 users01.dbf

恢复错误信息


RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of recover command at 06/09/2015 14:46:00

RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 25 and starting SCN of 991157


查看源机器当前scn
SYS@PROD2 > select * from v$log;

    GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME

---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ ---------

         1 1 25 52428800 512 1 NO CURRENT 991157 09-JUN-15 2.8147E+14      就是06054要找的那个

         2 1 23 52428800 512 1 YES INACTIVE 991092 09-JUN-15 991143 09-JUN-15

         3 1 24 52428800 512 1 YES INACTIVE 991143 09-JUN-15 991157 09-JUN-15


从源机上把redo拷贝过去(需要停机,慎用)

[oracle@guo1 PROD2]$ scp redo0* guo:/u01/app/oracle/oradata/PROD2/

oracle@guo's password:

redo01.log 100% 50MB 16.7MB/s 00:03

redo02.log 100% 50MB 16.7MB/s 00:03

redo03.log 100% 50MB 25.0MB/s 00:02

[oracle@guo1 PROD2]$ 

异机上

[oracle@guo PROD2]$ ll

total 1882944

-rw-r----- 1 oracle oinstall 9748480 Jun 9 14:52 control01.ctl

-rw-r----- 1 oracle oinstall 362422272 Jun 9 14:45 example01.dbf

-rw-r----- 1 oracle oinstall 52429312 Jun 9 14:52 redo01.log

-rw-r----- 1 oracle oinstall 52429312 Jun 9 14:52 redo02.log

-rw-r----- 1 oracle oinstall 17821696 Jun 9 14:52 redo03.log

-rw-r----- 1 oracle oinstall 576724992 Jun 9 14:45 sysaux01.dbf

-rw-r----- 1 oracle oinstall 754982912 Jun 9 14:45 system01.dbf

-rw-r----- 1 oracle oinstall 94380032 Jun 9 14:45 undotbs01.dbf

-rw-r----- 1 oracle oinstall 5251072 Jun 9 14:45 users01.dbf

[oracle@guo PROD2]$

再次恢复,正常

RMAN> recover database;

Starting recover at 09-JUN-15

using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 25 is already on disk as file /u01/app/oracle/oradata/PROD2/redo01.log

archived log file name=/u01/app/oracle/oradata/PROD2/redo01.log thread=1 sequence=25

media recovery complete, elapsed time: 00:00:01

Finished recover at 09-JUN-15

不过还是需要resetlogs打开

RMAN> alter database open;

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of alter db command at 06/09/2015 14:52:55

ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

在报06054的时候直接resetlogs打开的时候oracle会自动重建redo

如何解决呢?方法只有一个,将那个时间的日志拷贝过来,进行恢复就可以了。如何拷贝呢?关闭源库后才能拷贝,这个。。。

 一般情况下恢复到指定SCN就可以避免这个错误。

 确定scn是不是最后的scn,确定了之后直接resetlogs打开。

另外还可以使用RMAN duplicat功能恢复可以不用resetlogs打开


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/24742969/viewspace-1693114/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/24742969/viewspace-1693114/

### ADG 初始化完成后出现 ORA-01110 错误的原因分析 ORA-01110 是 Oracle 数据库常见的错误之一,通常表明某个数据文件无法被正常访问或定位。具体到 ADG(Active Data Guard)环境中,该错误可能由多种因素引起,例如物理路径不一致、数据文件损坏或者日志应用过程中发生异常。 #### 可能原因 1. **数据文件路径配置错误** 在主备切换或恢复操作期间,如果备用数据库的数据文件路径与实际存储位置不符,则可能导致此错误[^1]。 2. **数据文件丢失或不可用** 如果目标数据文件因磁盘故障或其他硬件问题而缺失或变得不可用,也会触发 ORA-01110 错误[^4]。 3. **Redo 日志同步失败** 当 Redo 应用程序尝试更新某些数据块时发现对应的数据文件不存在或状态异常,也可能引发此类错误[^2]。 --- ### 解决方案 针对上述潜在成因,以下是具体的排查和修复措施: #### 方法一:验证并修正数据文件路径 检查 `v$datafile` 和操作系统上的真实文件名是否匹配。如果不一致,可以重新指定正确的路径: ```sql ALTER DATABASE RENAME FILE '旧路径/文件名' TO '新路径/文件名'; ``` #### 方法二:离线处理受损数据文件 对于已确认存在问题的具体数据文件,可将其置为 OFFLINE 状态后再进行后续维护工作。例如: ```sql ALTER DATABASE DATAFILE '<datafile_id>' OFFLINE DROP; ``` 这里 `<datafile_id>` 需替换为目标对象的实际编号。 #### 方法三:重建受影响表空间 当简单调整不足以解决问题时,考虑删除再导入整个关联的表空间作为替代策略。注意备份现有结构以防万一: ```sql CREATE TABLESPACE 新名称 DATAFILE '完整路径\filename.dbf' SIZE 初始大小 AUTOEXTEND ON NEXT 自动扩展量 MAXSIZE 最大容量; @expdp schemas=模式名 directory=目录 location=dump_file.dmp logfile=log_exp.log @impdp schemas=模式名 directory=目录 dumpfile=dump_file.dmp logfile=log_imp.log ``` #### 方法四:联系官方支持团队获取进一步指导 假如经过本地努力仍未能彻底消除故障现象,则建议收集完整的告警日志提交给 Oracle 官方技术支持部门寻求帮助。 --- ### 总结 综上所述,在面对 ADG 启动阶段遭遇 ORA-01110 的状况下,应优先从基础层面入手——即核实各组件间映射关系准确性;其次才是深入探究更深层次的技术细节直至最终妥善处置完毕为止。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值