DataGuard环境中主库RMAN删除归档时报ORA-08137

1.问题描述

客户环境：2节点rac，Centos6.5，配置了一个单实例physical standby，数据库数据量200g左右，日归档量10g

问题现象：2019年11月20日，源端备份软件每天全备数据库，RMAN删除三天前归档，但是监控系统报空间不足，经过检查，归档依然保留了2019年11月12日的到2019年11月20日的归档，并没有删除三天前的归档，经过检查备份软件生成备份日志，发现日志中报错如下：

RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
archived log file name=+FRADG/honor/archivelog/2019_11_22/thread_1_seq_365.534.1024999167 thread=1 sequence=365

2.问题原因

（1）分析原因

通过报错描述，初步判断为两方面原因：

a.有进程打开持有归档

b.归档日志并未传输应用到physical standby端，由于配置了physical standby，默认如果归档日志未在备库应用，源库不允许使用RMAN删除归档，防止发生gap。

（2）排查

a.排查是否有进程持有打开未删除归档

11g版本中asmcmd控制台中可以使用lsof命令查看asm磁盘中文件打开情况：

[root@db-oracle-node1 ~]# su - grid
Last login: Thu Nov 21 20:08:26 CST 2019
[grid@db-oracle-node1 ~]$ asmcmd
ASMCMD> lsof -G FRADG

通过检查，发现有进程打开了2019年11月13日归档，通过了解，此库并未配置OGG、SharePlex等复制软件，仅有DataGuard，且DG备库在合肥，网络丢包较为严重，此时判断打开的13日归档为DG传输进程，我们去数据库中通过如下查询语句印证了该判断。

select process,pid,status,thread#,sequence# from v$managed_standby;

但是同时，通过执行如下命令发现，隔段时间可以删除一部分归档，但是报错的归档序号并没有进程打开使用，所以排除有进程持有打开导致ORA-08137可能性。

RMAN> delete archivelog until time 'sysdate-3';
或
RMAN> delete archivelog all completed before 'sysdate-3';

b.排查是否由于归档未被DataGuard应用导致无法删除

通过如下命令检查physical standby端进程状态：

select process,pid,status,thread#,sequence# from v$managed_standby;

发现RFS接收进程正在接受的归档确实为11月13日无法删除的归档sequence#。

通过如下命令检查primary端归档应用情况：

select thread#,name,max(sequence#),applied from v$archived_log where applied='YES' group by thread#,name, applied;

发现physical standby端仅仅应用到了11月13日的日志，比当前足足落后了7天，所以基本判断网络丢包严重导致发送接收缓慢，导致无法归档无法及时被physical端接收应用导致无法删除。

3.问题解决

通过与客户了解，客户基本放弃了使用该physical standby，所以我们可以使用如下几种解决办法：

（1）选择合适时机，清除DG环境

a.将primary置为最大性能模式

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

b.重置Data Guard初始化参数

LOG_ARCHIVE_CONFIG
DB_FILE_NAME_CONVERT
LOG_FILE_NAME_CONVERT
LOG_ARCHIVE_DEST_n指向Standby Database以及对STANDBY_LOGFILES有效的该参数
LOG_ARCHIVE_DEST_STATE_n
STANDBY_ARCHIVE_DEST
STANDBY_FILE_MANAGEMENT
FAL_SERVER
FAL_CLIENT

c.删除Standby Redologs

SQL> SELECT GROUP# FROM V$STANDBY_LOG;
SQL> ALTER DATABASE DROP STANDBY LOGFILE GROUP ;

d.如果需要，可以将physical standby转换为独立的数据库使用

$ sqlplus / as sysdba
SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;

（2）临时解决该问题，可以通过设置参数log_archive_dest_state_2为defer以及隐含参数_deferred_log_dest_is_valid为false来消除删除报ORA-08137问题

_deferred_log_dest_is_valid参数默认为TRUE，控制log_archive_dest_state_n参数设置为defer时，是否允许primary归档在未被physical standby应用时删除，防止再次将log_archive_dest_state_n设置为enable时，gap发生，导致physical standby不可用，该参数在11.2.0.4版本中为可动态调整参数，可以在线修改。

SQL> alter system set log_archive_dest_state_2=defer scope=both;
SQL> alter system set "_deferred_log_dest_is_valid"='FALSE' scope=both;

（3）删除归档使用force选项

RMAN > delete force archivelog until time 'sysdate-3' ;

4.参考文档

How To Remove Standby Database And Convert It to Standalone Database (Doc ID 2074686.1)

How to remove a Data Guard Configuration from Primary Database (Doc ID 733794.1)

RMAN-08137 on Primary Database although Archive Destination to Standby is deferred (Doc ID 1380368.1)