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.

相关推荐
不想被吃掉氩1 小时前
MySQL的事务特性和高可用架构
数据库·oracle
FL16238631292 小时前
C#winform流程图工具箱源码支持画矩形箭头圆形菱形保存为图片
数据库·oracle
正在走向自律3 小时前
Java连接电科金仓数据库(KingbaseES)实战指南
java·数据库·oracle·国产数据库·kingbase
Xxtaoaooo9 小时前
OpenTenBase分布式HTAP实战:从Oracle迁移到云原生数据库的完整指南
云原生·oracle·tdsql·opentenbase·腾讯云数据库
西贝爱学习1 天前
数据库系统概论的第六版与第五版的区别
数据库·oracle
我是zxb1 天前
EasyExcel:快速读写Excel的工具类
数据库·oracle·excel
_苏沐1 天前
cte功能oracle与pg执行模式对比
数据库·oracle
Blossom.1182 天前
从“能写”到“能干活”:大模型工具调用(Function-Calling)的工程化落地指南
数据库·人工智能·python·深度学习·机器学习·计算机视觉·oracle
不秃的开发媛2 天前
Java连接池详解:从Oracle到TiDB的随缘之旅
java·oracle·tidb
嘻嘻哈哈曹先生2 天前
Oracle数据库
数据库·oracle