Friday, July 13, 2018

Issue in DR Stand-By Instance while start-up


After creating the Stand-by Instance using RMAN backup from Primary Instance, below issue occurs while trying to start the standby database.

dbmgrprd@db_dr:/oracle/RMAN#!sq
sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Wed Jul 11 17:51:18 2018

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area 1068937216 bytes
Fixed Size                  2228344 bytes
Variable Size             432017288 bytes
Database Buffers          620756992 bytes
Redo Buffers               13934592 bytes
Database mounted.
ORA-10458: standby database requires recovery
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '+DATA/vis/datafile/system01.dbf'


On investigating the alert log file, found the database is searching for the archive log sequence 970 to apply.

ALTER DATABASE OPEN
Beginning standby crash recovery.
Serial Media Recovery started
Managed Standby Recovery starting Real Time Apply
Media Recovery Waiting for thread 1 sequence 970
Fetching gap sequence in thread 1, gap sequence 970-970
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Wed Jul 11 17:51:34 2018
Using STANDBY_ARCHIVE_DEST parameter default value as +DATA/vis/datafile/archive
Creating archive destination file : +DATA/vis/datafile/archive/1_970_970193294.dbf (430376 blocks)
Wed Jul 11 17:51:54 2018
Creating archive destination file : +DATA/vis/datafile/archive/1_970_970193294.dbf (430376 blocks)
Wed Jul 11 17:52:15 2018
Creating archive destination file : +DATA/vis/datafile/archive/1_970_970193294.dbf (430376 blocks)
Wed Jul 11 17:52:35 2018
Standby crash recovery need archive log for thread 1 sequence 970 to continue.
Please verify that primary database is transporting redo logs to the standby database.
Wait timeout: thread 1 sequence 970
Standby crash recovery aborted due to error 16016.
Errors in file /oracle/VIS/db/11.2.0/admin/VIS_db_dr/diag/rdbms/vis/VIS/trace/VIS_ora_4718654.trc:
ORA-16016: archived log for thread 1 sequence# 970 unavailable
Recovery interrupted!
Completed standby crash recovery.
Errors in file /oracle/VIS/db/11.2.0/admin/VIS_db_dr/diag/rdbms/vis/VIS/trace/VIS_ora_4718654.trc:
ORA-10458: standby database requires recovery
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '+DATA/vis/datafile/system01.dbf'

Since all the parameters for connectivity are already established, wondering where the problem might be. After some thorough checking, found the directory "archive" is missed under the archive location specified in the pfile. This is the reason for the logs are not getting transferred from Primary to Stand-by Instance. After creating the required directory structure, manually copied the file(archive sequence #970) and followed the below steps.

On Primary:
scp <missing archive file> <user>@<stand-by server IP>:<stand-by archive file destination>

On Stand-by:
Assign the proper ownership and permission to the file
SQL> alter database register logfile '</path/filename>';
SQL>alter database recover managed standby database disconnect;


Alert log content:

Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 4 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Log +DATA/vis/datafile/archive/1_970_970193294.dbf
Completed: alter database recover managed standby database disconnect

Since the media recovery happened successfully, tried to open the stand-by database

SQL>alter database open;

Now the issue is solved and the database opens successfully.

Note: Repeat the above steps as per the missing log files according to your issue criteria.


****************************நன்றி****************************


No comments:

Post a Comment

IAS Cache initialization failed

 Today I faced an Issue in R12.2 instance. The solution I followed to overcome the issue is very simple, but they are more than one solution...