ORA-00313 ORA-00312 ORA-27037

Table of Contents

• 1. 简述
• 2. 错误信息
• 3. 问题分析
• 4. 解决问题

1. 简述

某客户现场，由于原有备库磁盘空间不足，要做备库切换。 实现此场景的方式，对应用影响较小的就是搭建一套新的备库。也就是实现一套主多个从库的结构。这样，应用程序只需要修改tns中的IP地址，重启应用程序即可。

但是在搭建新的备库时，出现如下问题。

2. 错误信息

ORA-00313: open failed for members of log group 9 of thread 1
ORA-00312: online log 9 thread 1: '/data/onlineredo/group_9.265.1176307293'
ORA-27037: unable to obtain file status
......

报错的，不只是这一个redo文件。有很多，只是截取这一个，用来体现日志中报错信息。 下面开始分析。

3. 问题分析

先来查看下redo 文件有没有生成。遇到此问题时，第一个想到的就是 redo文件是不是没有生成，确认一下:

#ls /data/onlineredo
group_14.1182.1176307327  group_15.1180.1176307327   group_16.1179.1176307331 group_17.1178.1176307333
group_18.1176.1176307337

很奇怪的事，为什么从14以后有，而14之前的没有呢。 查看下主库的配置:

SQL> select group#,thread# from v$standby_log;

    GROUP#    THREAD#
---------- ----------
         9          1
        10          1
        11          1
        12          1
        13          1
        14          2
        15          2
        16          2
        17          2
        18          2

10 rows selected.

从此发现，group 14及之后的standby redo logfiles 是属于thread 2 的。也就是说thread 1 的都没有生成。 这是很奇怪的事。因为thread 1 上也是有数据处理的，如此长时间的不提交standby redo log 一直没有想明白 。

对于redo 日志缺失这种问题，解决办法 ，就是使用clear 命令重建就可以了。

4. 解决问题

注意这里并不是从 group 9 开始的，而是从1开始的， 因为既然做么，就一次性全处理掉。免得以后想用online redo 时再处理一次。 但是单纯从这个问题的角度上来讲，group 1~8 是可以不用处理的。

alter database clear logfile group 1;
alter database clear logfile group 2;
alter database clear logfile group 3;
alter database clear logfile group 4;
alter database clear logfile group 5;
alter database clear logfile group 6;
alter database clear logfile group 7;
alter database clear logfile group 8;
alter database clear logfile group 9;
alter database clear logfile group 10;
alter database clear logfile group 11;
alter database clear logfile group 12;
alter database clear logfile group 13;

生成后，启用数据同步,并观察日志:

sqlplus / as sysdba <<EOF
alter database recover managed standby database disconnect from session;
EOF
cd $ORACLE_BASE/diag/rdbms/<db_uniq_name>/<db_name>/trace/
tail -50f alert_<ORACLE_SID>.log
2024-09-18T22:17:35.262484+08:00
PR00 (PID:37538): Managed Standby Recovery starting Real Time Apply
max_pdb is 5
2024-09-18T22:17:36.059886+08:00
Parallel Media Recovery started with 40 slaves
2024-09-18T22:17:36.119199+08:00
Stopping change tracking
2024-09-18T22:17:36.157449+08:00
TT02 (PID:37624): Waiting for all non-current ORLs to be archived
2024-09-18T22:17:36.157528+08:00
TT02 (PID:37624): All non-current ORLs have been archived
2024-09-18T22:17:36.229130+08:00

发现已经不再报错了。

但是归档缺失。无法进行数据同步，也是有点儿折磨老朽呀。

Validate