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

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

Mar262018
作者：dbdream   发布：2018-03-26 11:32   分类：Oracle, oracle 11g     抢沙发  

之前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错误，这样做之后最好是逻辑迁移一下数据，以免遇到其他问题。

本文固定链接: https://www.dbdream.com.cn/2018/03/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错误解决方法：等您坐沙发呢！

发表评论

快捷键：Ctrl+Enter