问题描述

现场环境：

Centos7.9+11.2.0.4.0+physical standby
ADG保护模式：MAXIMUM PERFORMANCE
重做日志传输模式：LGWR ASYNC AFFIRM
应用方法：redo apply

巡检时发现备库告警日志中显示如下报错：

ARCq: Archival started
ARCr: Archival started
ARCs: Archival started
ARCm: Becoming the 'no FAL' ARCH
ARCn: Becoming the heartbeat ARCH
ARCn: Becoming the active heartbeat ARCH
ARCt: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Wed Mar 05 09:03:49 2025
Standby crash recovery failed to bring standby database to a consistent
point because needed redo hasn't arrived yet.
MRP: Wait timeout: thread 1 sequence# 17
Standby Crash Recovery aborted due to error 16016.
Errors in file /u01/app/oracle/diag/rdbms/wafu/wafu/trace/wafu_ora_1512.trc:
ORA-16016: archived log for thread 1 sequence# 17 unavailable
Recovery interrupted!
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail
Completed Standby Crash Recovery.
Errors in file /u01/app/oracle/diag/rdbms/wafu/wafu/trace/wafu_ora_1512.trc:
ORA-10458: standby database requires recovery
ORA-01196: file 1 is inconsistent due to a failed media recovery session
ORA-01110: data file 1: '/oradata/wafu/system01.dbf'
ORA-10458 signalled during: ALTER DATABASE OPEN...
复制

分析过程

查看备库状态

SQL> select status from v$instance;

STATUS
------------
MOUNTED



Database altered.
复制

分别应用和取消实时应用日志

SQL> alter database recover managed standby database parallel 10 disconnect from session;

Database altered.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
复制

启库

备库启动后依然报错

SQL> alter  database open;
alter  database open
*
ERROR at line 1:
ORA-10458: standby database requires recovery
ORA-01196: file 1 is inconsistent due to a failed media recovery session
ORA-01110: data file 1: '/oradata/wafu/system01.dbf'
复制

查看官方文档

ORA-01196: file string is inconsistent due to a failed media recovery session

Cause: The file was being recovered but the recovery did not terminate normally. This left the file in an inconsistent state. No more recovery was successfully completed on this file.

Action: Either apply more logs until the file is consistent or restore the backup again and repeat recovery.

查看主备库监听

发现备库监听未启动

解决办法

备库监听启动后数据库open正常。

以下的法一和法二方法都不对，

启动备库监听

 lsnrctl start
复制

open备库

SQL> alter  database open;
Database altered
复制

开启实时应用日志

SQL> alter database recover managed standby database parallel 10 disconnect from session;

Database altered.
复制

查看告警日志

查看告警日志发现已恢复，同步已正常

Wed Mar 05 09:32:37 2025
db_recovery_file_dest_size of 4182 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Wed Mar 05 09:37:27 2025
Using STANDBY_ARCHIVE_DEST parameter default value as /oradata/archivelog
Wed Mar 05 09:37:27 2025
RFS[1]: Assigned to RFS process 3365
RFS[1]: Opened log for thread 1 sequence 18 dbid -2007640562 branch 1194792401
Wed Mar 05 09:37:27 2025
RFS[2]: Assigned to RFS process 3367
RFS[2]: Opened log for thread 1 sequence 19 dbid -2007640562 branch 1194792401
Wed Mar 05 09:37:27 2025
RFS[3]: Assigned to RFS process 3369
RFS[3]: Opened log for thread 1 sequence 20 dbid -2007640562 branch 1194792401
Archived Log entry 5 added for thread 1 sequence 18 rlc 1194792401 ID 0x88561d0e dest 2:
Archived Log entry 6 added for thread 1 sequence 19 rlc 1194792401 ID 0x88561d0e dest 2:
Archived Log entry 7 added for thread 1 sequence 20 rlc 1194792401 ID 0x88561d0e dest 2:
Wed Mar 05 09:37:27 2025
RFS[4]: Assigned to RFS process 3371
RFS[4]: Selected log 4 for thread 1 sequence 17 dbid -2007640562 branch 1194792401
Wed Mar 05 09:37:27 2025
Archived Log entry 8 added for thread 1 sequence 17 ID 0x88561d0e dest 1:
RFS[1]: Selected log 4 for thread 1 sequence 21 dbid -2007640562 branch 1194792401
Wed Mar 05 09:37:29 2025
Archived Log entry 9 added for thread 1 sequence 21 ID 0x88561d0e dest 1:
Wed Mar 05 09:37:29 2025
Primary database is in MAXIMUM PERFORMANCE mode
RFS[5]: Assigned to RFS process 3375
RFS[5]: Selected log 4 for thread 1 sequence 22 dbid -2007640562 branch 1194792401
Wed Mar 05 09:38:33 2025
alter  database open
Beginning Standby Crash Recovery.
Serial Media Recovery started
Managed Standby Recovery starting Real Time Apply
Media Recovery Log /oradata/archivelog1_16_1194792401.dbf
Media Recovery Log /oradata/archivelog1_17_1194792401.dbf
Incomplete Recovery applied until change 1027435 time 03/04/2025 17:31:30
Completed Standby Crash Recovery.
Wed Mar 05 09:38:33 2025
SMON: enabling cache recovery
Dictionary check beginning
Dictionary check complete
Database Characterset is AL32UTF8
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Physical standby database opened for read only access.
Completed: alter  database open
Wed Mar 05 09:43:02 2025
alter database recover managed standby database parallel 10 disconnect from session
Attempt to start background Managed Standby Recovery process (wafu)
Wed Mar 05 09:43:02 2025
MRP0 started with pid=56, OS id=3660
MRP0: Background Managed Standby Recovery process started (wafu)
 started logmerger process
Wed Mar 05 09:43:07 2025
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 10 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Log /oradata/archivelog1_17_1194792401.dbf
Media Recovery Log /oradata/archivelog1_18_1194792401.dbf
Media Recovery Log /oradata/archivelog1_19_1194792401.dbf
Media Recovery Log /oradata/archivelog1_20_1194792401.dbf
Completed: alter database recover managed standby database parallel 10 disconnect from session
Media Recovery Log /oradata/archivelog1_21_1194792401.dbf
Media Recovery Waiting for thread 1 sequence 22 (in transit)
复制