处理RMAN-08120报错，记录相关进程 RFS，LNSn，MRP，LSP

问题描述

曾经主库为2节点RAC，备库为3节点RAC，在经过一次switchover之后（主库为3节点RAC，备库为2节点RAC）。一切运行正常。

在新主库端清理arch时，报错 RMAN-08120: WARING: archived log not deleted, not yet applied by standby 报错。

可是明明备库端同步的很好呢。

• 为了避免空间被arch占满，必须解决这个问题，清理归档方法：
  方法1：清理arch的语句加入force参数
  方法2：找原因。为什么会报错RMAN-08120呢？

目前方法1用不了，因为清理arch的操作是NBU端配置的，但是NBU中不能加入force参数。------ emmm…尴尬

问题分析

1. 思考为什么会报RMAN-08120错

Oracle 的archive log会不断生产，一般DBA会设置定期清理archivelog。如果数据库配置了DG备库的话，DG是通过传输日志条目、归档日志达到数据的同步的。

但DG环境中因为某些原因导致主库事务没有即使传到standby，而这时如果主库的archivelog也被清理掉了，好了DG数据重建吧。 ------ 哭

所以，如何能够确保standby日志接收到了，主库的archivelog才会被删除呢？

11G 后提供了RMAN的archivelog删除策略的配置参数:

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

那么其实现在我们遇到的报错其实是在保护DG数据的同步。

2. 思考 DG备库正常同步，为什么还报错？

既然报错的信息是在保护DG的同步，通过查看主库与备库的告警日志发现，备库一丝不苟的实时在接收 + 应用 主库传来的arch。

• 分别检查主备库的告警日志

突然的小发现

在检查主备库告警日志的时候发现主库中以下信息：

Tue May 26 15:20:59 2020
Archived Log entry 2207452 added for thread 2 sequence 308627 rlc 912200419 ID 0xc277ac1e dest 2:
Tue May 26 15:20:59 2020
Archived Log entry 2207454 added for thread 1 sequence 347385 ID 0xffffffffc277ac1e dest 1:
Tue May 26 15:20:59 2020
Archived Log entry 2207455 added for thread 1 sequence 347385 rlc 912200419 ID 0xc277ac1e dest 2:
Tue May 26 15:20:59 2020
LNS: Standby redo logfile selected for thread 1 sequence 347386 for destination LOG_ARCHIVE_DEST_3
RFS[246]: Opened log for thread 2 sequence 308628 dbid -1206570467 branch 912200419
RFS[198]: Opened log for thread 1 sequence 347386 dbid -1206570467 branch 912200419

Q1. 发现还有个LOG_ARCHIVE_DEST_3 ？

Q2. RFS进程怎么会出现在这里？

Q1. 发现还有个LOG_ARCHIVE_DEST_3 ？

熟悉搭建DG，一主一备的环境一般配置LOG_ARCHIVE_DEST_1 和 2 即可，这里怎么还多出来个3 ？ 根据我所了解到的本套系统的结构的确是“一主一备”（我们在问题描述部分也有体现）。

那么，检查主库参数

show parameter LOG_ARCHIVE_DEST_

log_archive_dest_1                   string      location=+ARCH

log_archive_dest_2                   string      service=orcl_new valid_for=(online_logfiles,primary_role) db_unique_name=orcl_new

log_archive_dest_3                   string      service=orcl valid_for=(online_logfiles,primary_role) db_unique_name=orcl

的确是有三个.
log_archive_dest_1 是本地归档存放位置
log_archive_dest_2、3 分别指向了两个service，难道有两个备库？

接下来确认orcl_new 和 orcl 分别指向了那个IP的数据库

[oracle@dbm ~]$ more $ORACLE_HOME/network/admin/tnsnames.ora

ORCL =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.5)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.6)(PORT = 1521))
    (LOAD_BALANCE = yes)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl)
      (UR=A)
    )
  )

ORCL_NEW =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.64)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.65)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.66)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME =orcl_new)
      (UR=A)
    )
  )

至此有点眉目了。根据IP地址我们发现ORCL_NEW是本机三节点RAC的VIP，ORCL是我们已知备库的2个VIP。

通过配置的参数，主库不仅把arch传给了正确的备库，同时还传给了自己!!

Q2. RFS进程怎么会出现在这里？

======= 先说下DG中的几个重要的进程吧 ==========

• RFS：remote file server。该进程是standby库接受来自primary库lgwr进程触发的redo信息并且写入到standby redo log中。RFS进程无疑是要和其他进程配合的，也就是传输的进程。那这里就需要上篇的知识了，我们知道触发同步可能由ARCH或者是LGWR进程触发的，两者是不同的。如果是LGWR进程触发，那10g前的话也是由LGWR进程负责传输redo信息，RFS进程负责接收redo信息写入standby redo log中，10g之后则由LNSn进程完成；如果是ARCH进程触发，也就是归档日志传输的话，那就是由ARCH进程负责传输，RFS进程负责接收，然后写入指定的归档位置，然后再应用的。那这里不同的设置也决定了参数LOG_ARCHIVE_DEST_n的不同设置。详细见下。

• LNSn：LGWR触发以后真正负责传输的进程，包括初始化网络I/O等一些列功能。

• MRP：managed recovery process，简单来说就是物理standby是通过这个进程来实现数据的同步的，直接通过standby redo log或者是归档日志（取决于模式不同）来进行的一个数据恢复。

• LSP:logical standby process：逻辑standby的方式，和上面的一样，只不过当中多了一步将redo信息转换成sql语句再恢复。也可以从这里看出逻辑standby和物理standby的不同。

那插播完了进程介绍，继续LOG_ARCHIVE_DEST_n，这个参数格式如下：

必须指定location/service：location代表的是本地的路径，在之后直接加入路径名例如LOG_ARCHIVE_DEST_1=‘LOCATION=/arch1/chicago/’

service代表的是net service name，通常就是standby数据库的net_service_name，可以在tnsnames.ora,定义NET SERVICE NAME.那根据前面所说的不同方式service的制定要复杂的多：LOG_ARCHIVE_DEST_2=‘SERVICE=net_service_name LGWR ASYNC’，那这里也可以是LGWR SYNC NET_TIMEOUT=××来设置同步并且指定超时时间。如果是应用归档的方式，那就直接LOG_ARCHIVE_DEST_2='SERVICE=net_service_name。

valid_for:这个参数的作用是指定该LOG_ARCHIVE_DEST_n的路径的redo log的type 和redo log的“身份”的，方便在转换的时候使用。VALID_FOR=(redo_log_type,database_role)type有下面这些： ONLINE_LOGFILE, STANDBY_LOGFILE, ALL_LOGFILES. “身份”是这些: PRIMARY_ROLE, STANDBY_ROLE, ALL_ROLES

===================================================================

巴拉巴拉补充了那么多，话说回来。

在主库端看到了RFS进程有问题的呢，但是结合Q1中的发现，主库自己给自己传arch，自己接收到了，那么出现了RFS进程，也是正常的呢。

不过问题又来了。那么这样现在的主库会认为自己有两套DG备库呢吧。然鹅！！ 传给自己的arch怎么可能会被apply呢，岂不是乱套了。

那么，主库认为arch传给了备库（们），但是的确是有个“备库”并没有apply，那么主库在清理arch的时候报错也就 没毛病了。

问题解决

把指向自己的LOG_ARCHIVE_DEST_n 的参数值清掉：

alter system set log_archive_dest_2='';

验证：尝试正常删除n天前的arch，看是否还有报错

rman target /
delete  archivelog all completed before 'sysdate-2';

OK。成功删除。。

后记

一定一定要按照官方文档的配置来哦。

Oracle大部分报错，分析到最后，导致问题的原因都忍不住 捶胸顿足一番。把自己折腾的半死。