当前位置: 首页 > Oracle, oracle 11g > 正文

ORA-00314和ORA-00312错误解决方法

之前BI的一个数据库磁盘故障,修复后由于没有足够空间的服务器和存储,使用了一台I/O很慢的存储临时搭建了DG,昨天新采购的服务器到货,要把备库迁移到新的服务器上。

备库迁移有很多种方案可以选择,我选择了一种比较方便比较简单的方案,直接拷贝备库,因为这个备库只起到一个容灾的作用,并没有承载任何的业务。

我的操作步骤是,停止备库的MRP进程(或者将数据库启动到MOUNT状态,不要启动MRP进程),这样数据文件就会静止,不会发生变化,并且备库还可以继续结束主库的日志,一旦下班之前完不成,还可以启动原备库的MRP进程,继续同步,因为原备库的磁盘I/O很慢,并不确定下班之前是否能传输完毕,而且这个活并不着急。

然后把备库的数据文件、控制文件、参数文件、密码文件、日志文件(redo log、standby redo log)传输到新的服务器。

传输完成后,关闭原备库,这样主库的日志就不会再发送到原备库,将缺少的归档日志从原备库传输到新服务器。因为数据文件传输的时候,原备库一直在接受主库的日志,原备库的控制文件一直在变化,所以原备库关闭后,还需要再把原备库的控制文件传输到新服务器。

因为原备库和新服务器的路径信息都一致,并不需要调整,修改主库和新服务器的tnsnames.ora文件里相应的IP地址信息,启动新服务器上的数据库。

在MOUNT的时候,告警日志报出ORA-00314错误,但是数据库mount成功。

alter database mount
ARCH: STARTING ARCH PROCESSES
Thu Mar 22 17:41:38 2018
ARC0 started with pid=29, OS id=140161
ARC0: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Thu Mar 22 17:41:39 2018
Successful mount of redo thread 1, with mount id 735403022
Physical Standby Database mounted.
Lost write protection disabled
Thu Mar 22 17:41:40 2018
ARC1 started with pid=30, OS id=140163
Thu Mar 22 17:41:40 2018
ARC2 started with pid=31, OS id=140165
Thu Mar 22 17:41:40 2018
ARC3 started with pid=32, OS id=140167
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC2: Becoming the heartbeat ARCH
ARC2: Becoming the active heartbeat ARCH
Errors in file /u01/app/oracle/diag/rdbms/huimaibi/huimaibi/trace/huimaibi_arc2_140165.trc:
ORA-00314: log 10 of thread 1, expected sequence# 68673 doesn't match 68625
ORA-00312: online log 10 thread 1: '/u01/app/oracle/oradata/huimaibi/redo_std01.log'
Create Relation IPS_PACKAGE_UNPACK_HISTORY
Completed: alter database mount

错误提示第10组redo文件损坏,这个数据库的第10组redo是第一个standby redo文件,在新服务上的备库启动到mount状态后,就可以接收主库的日志了,这时候又一次报出这个错误。

ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Thu Mar 22 17:52:19 2018
Using STANDBY_ARCHIVE_DEST parameter default value as /u01/app/oracle/archivelog
Thu Mar 22 17:52:19 2018
Errors in file /u01/app/oracle/diag/rdbms/huimaibi/huimaibi/trace/huimaibi_rfs_140379.trc:
ORA-00314: log 10 of thread 1, expected sequence# 68673 doesn't match 68625
ORA-00312: online log 10 thread 1: '/u01/app/oracle/oradata/huimaibi/redo_std01.log'
Errors in file /u01/app/oracle/diag/rdbms/huimaibi/huimaibi/trace/huimaibi_rfs_140379.trc:
ORA-00314: log 10 of thread 1, expected sequence# 68673 doesn't match 68625
ORA-00312: online log 10 thread 1: '/u01/app/oracle/oradata/huimaibi/redo_std01.log'

看到这个错误,我就知道是什么原因了,因为原备库在传输数据文件的时候,原备库一直在接受主库的日志,会使用到standby redo文件,不止控制文件会被更新,standby redo也会被更新,而之前我只考虑到控制文件被更新,重新传了一次控制文件,却忽略了standby redo也发生变化的问题。

这时,查询V$STANDBY_LOG视图已经查询不了,也报这个错误。

SQL> SELECT GROUP#,SEQUENCE#,ARCHIVED,STATUS FROM v$standby_log;

ORA-00314: log 10 of thread 1, expected sequence# 68673 doesn't match 68625
ORA-00312: online log 10 thread 1: '/u01/app/oracle/oradata/huimaibi/redo_std01.log'

在启动MRP进程,应用日志的时候,也遇到了这个错误。

Thu Mar 22 17:56:37 2018
Media Recovery Log /u01/app/oracle/archivelog/1_68656_966557443.dbf
Thu Mar 22 17:56:40 2018
Errors in file /u01/app/oracle/diag/rdbms/huimaibi/huimaibi/trace/huimaibi_arc2_140165.trc:
ORA-00314: log 10 of thread 1, expected sequence# 68673 doesn't match 68625
ORA-00312: online log 10 thread 1: '/u01/app/oracle/oradata/huimaibi/redo_std01.log'

但是并不影响备库接收主库的日志,从下面的日志可以看到,这里使用了redo_std02.log这个standby redo来时时接受主库的日志了。

Thu Mar 22 17:57:23 2018
Media Recovery Log /u01/app/oracle/archivelog/1_68675_966557443.dbf
Media Recovery Log /u01/app/oracle/archivelog/1_68676_966557443.dbf
Media Recovery Log /u01/app/oracle/archivelog/1_68677_966557443.dbf
Media Recovery Waiting for thread 1 sequence 68678 (in transit)
Recovery of Online Redo Log: Thread 1 Group 11 Seq 68678 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/huimaibi/redo_std02.log

这个问题解决起来也非常的简单,因为原先的备库已经停掉了,直接把这个文件拷过来就行了。

把报错的standby redo拷过来之后,在告警日志就可以看到,这个standby redo文件已经可以正常接收主库的日志了。

Thu Mar 22 17:58:06 2018
RFS[6]: Selected log 10 for thread 1 sequence 68679 dbid 730497987 branch 966557443
Thu Mar 22 17:58:06 2018
Media Recovery Waiting for thread 1 sequence 68679 (in transit)
Recovery of Online Redo Log: Thread 1 Group 10 Seq 68679 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/huimaibi/redo_std01.log

在查看V$STANDBY_LOG视图,可以查看到,redo_std01.log和redo_std02.log都在接受主库的日志信息,平时只能看到一组standby redo在工作,基本看不到两组standby redo工作的情况,这是一种例外。

SQL> SELECT GROUP#,SEQUENCE#,ARCHIVED,STATUS FROM v$standby_log;

    GROUP#  SEQUENCE# ARC STATUS
---------- ---------- --- ----------
        10      68679 YES ACTIVE
        11      68678 YES ACTIVE
        12          0 NO  UNASSIGNED
        13          0 NO  UNASSIGNED

既然是例外情况,就不会长久,在过一段时间,日志切换几次后,状态就会变成正常情况了。

SQL> SELECT GROUP#,SEQUENCE#,ARCHIVED,STATUS FROM v$standby_log;

    GROUP#  SEQUENCE# ARC STATUS
---------- ---------- --- ----------
        10      69076 YES ACTIVE
        11          0 NO  UNASSIGNED
        12          0 NO  UNASSIGNED
        13          0 NO  UNASSIGNED

我这个故障出现在standby redo log上,所以恢复起来比较简单,如果故障发生在online redo log上面,就要看online redo log是什么状态了。

如果损坏的是INACTIVE状态或者UNUSED状态,说明这个online redo log已经是检查点之前的了或者还没被使用到,恢复不会用到,可以直接使用alter database clear logfile group number命令重建;

如果是ACTIVE状态,说明这个online redo log还没归档完成,检查点可能还没有完成,恢复可能还会使用到,直接clear是不允许的,可以使用alter database clear unarchived logfile group number命令重建;

如果损坏的是CURRENT状态的日志,就比较麻烦了,可能会需要使用recover database until cancel做不完全恢复,还要设置隐含参数_allow_resetlogs_corruption=TRUE,最后还得是resetlogs的方式打开数据库,这就意味着,可能会丢失数据了,而且数据库还是不一致打开的,可能还会遇到ORA-00600错误,这样做之后最好是逻辑迁移一下数据,以免遇到其他问题。

本文固定链接: http://www.dbdream.com.cn/2018/03/26/ora-00314%e5%92%8cora-00312%e9%94%99%e8%af%af%e8%a7%a3%e5%86%b3%e6%96%b9%e6%b3%95/ | 信春哥,系统稳,闭眼上线不回滚!

该日志由 dbdream 于2018年03月26日发表在 Oracle, oracle 11g 分类下, 你可以发表评论,并在保留原文地址及作者的情况下引用到你的网站或博客。
原创文章转载请注明: ORA-00314和ORA-00312错误解决方法 | 信春哥,系统稳,闭眼上线不回滚!
关键字: , , , ,

ORA-00314和ORA-00312错误解决方法:等您坐沙发呢!

发表评论

您必须 [ 登录 ] 才能发表留言!

13511039874
dbdream