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.
Log transfer gets terminated from primary even if archives are present.
Applicable Error Code
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
Please check if log file for sequence 69497 is available on dbvlab01.
DescriptionA Network issue has occurred between primary and standby for an extended period of time. After this issue was resolved, the archivelogs in the primary had been backed up and deleted so were needing to be restored in order to be sent to the Standby. However, when trying to send the archivelogs using the -R option from primary get the below error.
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.
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.
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.
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.