We're here to help!

 This article explains how to resolve issue when archivelogs from primary are not being transferred to standby after an outage because the archivelogs were restored using OS backup and not using RMAN.

Problem Details

Dbvisit Standby terminated... 
Error Code: 404 
Log transfer for ORCL thread 1 terminated: 
  Dbvisit Standby searched for log files, but could not find log file to transfer for 
sequence 69497. 
Please check if log file for sequence 69497 is available on dbvlab01.

Dbvisit Standby terminated... 
Error Code: 404 
Log transfer for TEXP thread 1 terminated: 
	 Dbvisit Standby searched for log files, but could not find log file to transfer for 
sequence 69497. 
Please check if log file for sequence 69497 is available on leodbprod. 
If using setting ARCHLOG_PREFIX, then please check if this is specified correctly 
You can run dbvctl with -R option to resynch archive logs with standby database, but 
if you are missing archive log files that have not been transferred to the standby, 
then you 
can make use of the Synchronize Standby Database feature, using dbvctl --sync to 
attempt re-syncing the 
standby database using incremental backups. 

The issue here is the archivelogs are backed by RMAN and deleted from the source and it was restored using OS backup, so there is no entry of these archivelogs in the current control file of the database , this results in the above error. 

By running the below SQL we can see that the archivelogs were deleted from control file. The Name Column is empty.

select name, thread#, SEQUENCE#,ARCHIVED,APPLIED,DELETED,STATUS from v$archived_log where SEQUENCE# between 69495 and 69510;

 NAME             THREAD#  SEQUENCE# ARCHIVED APPLIED   DELETED STATUS
----------------- ------- ---------- -------- --------- ------- ------
                        1      69495 YES      NO        YES     D
                        1      69496 YES      NO        YES     D
                        1      69497 YES      NO        YES     D
                        1      69498 YES      NO        YES     D
                        1      69499 YES      NO        YES     D
                        1      69500 YES      NO        YES     D
                        1      69501 YES      NO        YES     D
                        1      69502 YES      NO        YES     D
                        1      69503 YES      NO        YES     D
                        1      69504 YES      NO        YES     D
                        1      69505 YES      NO        YES     D
                        1      69506 YES      NO        YES     D
                        1      69507 YES      NO        YES     D
                        1      69508 YES      NO        YES     D
                        1      69509 YES      NO        YES     D
                        1      69510 YES      NO        YES     D

There are two ways to resolve this issue.

Option 1
1. Run the below query in the primary.

select thread#, sequence#, name from v$archived_log where sequence# > 69497 and name is not null order by sequence# ;

The above query will list the archivelogs needed to be copied to the standby. For example if sequence 69600 appears on the top, you have to copy till sequence 69599.

2. The above archive logs must be copied to ARCHDEST location (check the DDC file dbv_ORCL.env) in standby and then run ./dbvctl -d ORCL.
3. Once it applies all the archives run the ./dbvctl -d ORCL -R from primary.
Option 2

You can re-register the archivelogs again using the below command from primary. The location specified below is the Archivelog location in the primary, where the archives were restored. 

rman target=/ 
catalog start with '/u01/app/oracle/archive/ORCL';

This will re-register the archivelogs and then then you can run 
./dbvctl -d ORCL -R from primary which should copy all the archivelogs to standby and apply them.