log_archive_dest_1 USE_DB_RECOVERY_FILE_DEST VALID_FOR

SYMPTOMS

NOTE: In the images and/or the document content below, the user information and environment data used represents fictitious data from the Oracle sample schema(s), Public Documentation delivered with an Oracle database product or other training material. Any similarity to actual environments, actual persons, living or dead, is purely coincidental and not intended in any manner.

For the purposes of this document, the following fictitious environment is used as an example to describe the procedure:

Database Name: ORCL
Disk Group:  +FRA

******************

Duplicate copy of Foreign Archive Logs were getting created in Logical Standby archive log destination.

When Foreign Archive Logs are deleted manually using RMAN, only the first copy gets deleted thereby maintaining the second copy indefinitely.

Only work around was to delete them manually from ASMCMD prompt.

As seen from RMAN and ASMCMD below, 2 copies of foreign archive logs were listed, but only 1 record found in the control file for each sequence.

So the auto cleanup would leave the second copy in ASM forever.

When Foreign Archive Logs are deleted manually using RMAN, only the first copy would get deleted, thereby maintaining the second copy in the ASM Disk Group indefinitely.

Only work around was to delete them manually from ASMCMD prompt.

--From RMAN

RMAN> list archivelog all completed after 'sysdate-1/360' ;

using target database control file instead of recovery catalog
List of Archived Log Copies for database with db_unique_name ORCL
=====================================================================

Key Thrd Seq S Low Time
------- ---- ------- - ---------
13880 2 1768 A 13-FEB-17
Name: +FRA/ORCL/ARCHIVELOG/2017_02_13/thread_2_seq_1768.3821.935831741

13881 2 1768 A 13-FEB-17
Name: +FRA/ORCL/ARCHIVELOG/2017_02_13/thread_2_seq_1768.1863.935831741

13882 3 1129 A 13-FEB-17
Name: +FRA/ORCL/ARCHIVELOG/2017_02_13/thread_3_seq_1129.3716.935831743

13883 3 1129 A 13-FEB-17
Name: +FRA/ORCL/ARCHIVELOG/2017_02_13/thread_3_seq_1129.1000.935831743

--From ASMCMD

ASMCMD> ls -lt

ARCHIVELOG UNPROT COARSE FEB 13 09:00:00 Y thread_3_seq_1128.2038.935831267
ARCHIVELOG UNPROT COARSE FEB 13 09:00:00 Y thread_3_seq_1128.3273.935831267
ARCHIVELOG UNPROT COARSE FEB 13 09:00:00 Y thread_3_seq_1129.1000.935831743
ARCHIVELOG UNPROT COARSE FEB 13 09:00:00 Y thread_3_seq_1129.3716.935831743

ASMCMD> pwd
+FRA/ORCL/ARCHIVELOG/2017_02_13
 

CHANGES

None.

Issue with log_archive_dest configuration.

CAUSE

Incorrect configuration for log_archive_dest at Logical Standby was found, causing duplicate/redundant copies of archive logs at the same destination.

With the current configuration, Primary had been transferring foreign archive logs to two remote locations at Logical Standby.
In given logical standby there were two location specified to create archivelogs as below, but both were for ALL_ROLES and ALL_LOGFILES

----------------------------------------------------------------------------------------------------------------------------------------------------------------

From the Standby parameters, log_archive_dest had been configured twice to the Fast Recovery Area.

log_archive_dest_1 string location=USE_DB_RECOVERY_FILE_DEST
log_archive_dest_3 string LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES)

SOLUTION

Suggested Configuration in Logical Standby:

alter system set log_archive_dest_1=location=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ONLINE_LOGFILE,ALL_ROLES) scope=both;
alter system set log_archive_dest_3=location=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(STANDBY_LOGFILE,STANDBY_ROLE) scope=both;

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Customer Implemented below to have just one Archive log dest in logical standby.

alter system set log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST' ;
alter system set log_archive_dest_3='' ;

Customer confirmed that issue resolved after implementing the above changes.