前言

客户11204单机到单机的linux active dataguard环境，之前adg同步都正常，反应从昨晚开始备库突然没有实时同步。备库MRP进程一直处于等待归档日志，而非在线日志。在主库手动切换归档，备库MRP进程才会应用新生成归档日志。

一、现状检查

从主库侧看下当前的ADG状态，V$ARCHIVE_DEST_STATUS.RECOVERY_MODE显示是MANAGED REAL TIME APPLY ，直观理解是备库实时应用中，但gap_status='LOG SWITCH GAP‘，明显有问题。

在主库检查可以看到主备延迟挺大的，正常应该少于60s。

 THREAD# DEST_ID DEST_NAME TARGET DATABASE_MODE STATUS ERROR RECOVERY_MODE DB_UNIQUE_NAME DESTINATION GAP_STATUS CURRENT_SEQ# LAST_ARCHIVED APPLIED_SEQ# APPLIED_SCN -------- -------- -------------------- -------------------- -------------------- ---------- ---------- -------------------- --------------- --------------- ---------- ---------------- ---------------- ---------------- ---------------- 1 1 LOG_ARCHIVE_DEST_1 LOCAL PRIMARY OPEN VALID IDLE NONE /u03/arch 4317 4316 0 1 2 LOG_ARCHIVE_DEST_2 PHYSICAL STANDBY OPEN_READ-ONLY VALID MANAGED REAL TIME AP ora9 ora9 LOG SWITCH 4317 4316 4316 612 PLY GAP $ ora dglag status: VALID DG Lag: 6859s

查看备库的alert日志：

讯享网Thu Oct 22 11:07:18 2020 Managed Standby Recovery starting Real Time Apply Parallel Media Recovery started with 4 slaves Waiting for all non-current ORLs to be archived... All non-current ORLs have been archived. Media Recovery Waiting for thread 1 sequence 4328 Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION Thu Oct 22 11:07:47 2020 RFS[2]: Selected log 7 for thread 1 sequence 4328 dbid  branch  Thu Oct 22 11:07:47 2020 Archived Log entry 3731 added for thread 1 sequence 4328 ID 0x2afda2d8 dest 1: Thu Oct 22 11:07:48 2020 Media Recovery Log /u01/arch/1_4328_.dbf Media Recovery Waiting for thread 1 sequence 4329

备库MRP进程进程等待归档4329。这里明显有问题，如果实时同步的话，日志应该是类似：

Media Recovery Waiting for thread 1 sequence 4329 (in transit) 

二.ADG同步原理

以是一个ADG主备库的实时同步示意图：

讯享网

■ 传输流程：

   - 主库的LGWR进程写自己的在线重做日志(ORL)
   - 主库的DataGuard进程LNS(LogWriter Network Process)从SGA的redo buffer里读redo信息然后通过网络服务传输给备用数据库。
   - 由LNS传输的redo记录由备用数据库的另外一个DataGuard进程RFS(Remote File Server)接收。
   - RFS接收redo记录之后将其写入备用重做日志(SRL)。

■ ARCH or LNS

在备库故障或网络中断期间，DataGuard在主库上使用ARCH进程连续ping备库来确定其状态。当与备库的通信还原后，ARCH ping进程会查询备库控制文件来确定备用数据库最后一个接收到的完整日志文件，以此确定需要从主库传输哪些日志文件来重新同步备库，然后开始使用ARCH进程传输相应文件。

Oracle10g开始默认归档进程数为2，从而在自动处理日志文件间隔时，不影响主数据库的归档操作。

在接下来执行日志切换时，LNS会试图连接备用数据库，成功后也会开始传输当前重做数据，同一时间ARCH进程在后台处理日志文件间隔。

当应用进程(MRP)赶上进度之后，不再读取归档日志文件，转而读取SRL文件。

■ 应用服务（MRP）

MRP进程在库自动应用redo记录来维护与主库的同步，允许对数据的事务性一致访问。默认应用服务需要等待SRL归档之后才应用redo，当然也可以启动实时应用，允许应用服务应用当前SRL的redo记录。

三、问题分析

1、当前进程情况

主库的进程如下，没有发现负责传输的LNS进程

讯享网13:23:12 sys@ORA9 > SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS ,CLIENT_PID, pid FROM gV$MANAGED_STANDBY WHERE THREAD#!=0 ORDER BY THREAD#, SEQUENCE#; PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS CLIENT_PID PID --------- ---------- -------------------- ----------- -------------------- -------------------- ---------------------------------------- -------------------- LGWR CLOSING 1 4183  16 2663 2663 ARCH CLOSING 1 4320 8192 263 2685 2685 ARCH CLOSING 1 4328 6144 1484 2715 2715 ARCH CLOSING 1 4328 1 7627 2711 2711

后台也没有发现LNS进程

$ ps -ef|grep -v grep|grep -E "ora_lns|ora_nsa|ora_nss" $ 

备库进程如下，有MRP进程（wait for log），没有发现RFS进程工作，也可以理解为当前没有数据传输 ing 。

讯享网 INST_ID PROCESS PID CLIENT_PROCESS CLIENT_PID STATUS THREAD# SEQUENCE# BLOCK#