重庆思庄Oracle、KingBase、PostgreSQL、Redhat认证学习论坛

标题: 使用 RECOVERY_PARALLELISM和ApplyParallel提高ADG 日志应用效率 [打印本页]

作者: mahan 时间: 2026-1-4 20:07
标题: 使用 RECOVERY_PARALLELISM和ApplyParallel提高ADG 日志应用效率
1.ORA-16766: Redo Apply is stopped
DGMGRL> show configuration

Configuration - ycjj2dg

  Protection Mode: MaxPerformance
  Databases:
ycjj - Primary database
ycjj2dg - Physical standby database
   Error: ORA-16766: Redo Apply is stopped

Fast-Start Failover: DISABLED

Configuration Status:
ERROR

DGMGRL> show database verbose ycjj2dg

Database - ycjj2dg

  Role:          PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag: (unknown)
  Apply Lag:    (unknown)
  Apply Rate:    (unknown)
  Real Time Query: OFF
  Instance(s):
ycjj

  Database Error(s):
ORA-16766: Redo Apply is stopped

  Properties:
DGConnectIdentifier          = 'ycjj2dg'
ObserverConnectIdentifier    = ''
LogXptMode                   = 'ASYNC'
DelayMins                      = '0'
Binding                      = 'optional'
MaxFailure                   = '0'
MaxConnections                = '1'
ReopenSecs                   = '300'
NetTimeout                   = '30'
RedoCompression                = 'DISABLE'
LogShipping                   = 'ON'
PreferredApplyInstance       = ''
ApplyInstanceTimeout          = '0'
ApplyParallel                = 'AUTO'
StandbyFileManagement          = 'AUTO'
ArchiveLagTarget             = '0'
LogArchiveMaxProcesses       = '4'
LogArchiveMinSucceedDest       = '1'
DbFileNameConvert             = ''
LogFileNameConvert             = ''
FastStartFailoverTarget       = ''
InconsistentProperties       = '(monitor)'
InconsistentLogXptProps       = '(monitor)'
SendQEntries                   = '(monitor)'
LogXptStatus                   = '(monitor)'
RecvQEntries                   = '(monitor)'
ApplyLagThreshold             = '0'
TransportLagThreshold          = '0'
TransportDisconnectedThreshold  = '30'
SidName                      = 'ycjj'
StaticConnectIdentifier       = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=ycjj-jcpt-backup)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=ycjj2dg_DGMGRL)(INSTANCE_NAME=ycjj)(SERVER=DEDICATED)))'
StandbyArchiveLocation       = '/u01/app/oracle/oradata/archivelog'
AlternateLocation             = ''
LogArchiveTrace                = '0'
LogArchiveFormat             = '%t_%s_%r.dbf'
TopWaitEvents                = '(monitor)'

Database Status:
ERROR

DGMGRL>

从你提供的 Data Guard 配置信息来看，核心问题是物理备库 ycjj2dg 的重做应用（Redo Apply）被停止，报出ORA-16766: Redo Apply is stopped错误，同时传输延迟、应用延迟等指标均为(unknown)，配置状态和数据库状态均为 ERROR。以下是逐步排查和解决的方案：

错误分析
该错误表示备库的介质恢复（Redo Apply）进程未运行，可能的原因包括：

备库的恢复进程（MRP）被手动停止；
备库无法读取归档日志 / 重做日志（文件缺失、权限不足、路径错误）；
主备库之间的重做传输中断，备库无新日志可应用；
备库处于只读打开状态但未启动实时应用，或恢复进程异常终止；
主备库的数据文件不一致（如备库数据文件损坏、主库执行了备库未同步的操作如NOLOGGING）。
解决问题
步骤 1：检查备库的归档日志和重做传输状态
1. 登录备库的 SQL*Plus（以 sysdba 身份）
sqlplus / as sysdba
2. 检查主备库的重做传输状态（备库执行）
-- 查看归档日志的接收情况
SELECT SEQUENCE#, APPLIED, STATUS FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

-- 查看重做传输的状态（主库执行更准确，备库可看V$LOGSTDBY_PROCESS）
-- 备库查看是否有MRP进程
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS
FROM V$MANAGED_STANDBY;
如果V$MANAGED_STANDBY中没有MRP0或MRP进程，说明恢复进程未启动；
如果有MRP0进程但状态为ERROR，说明恢复过程中出现异常。
3. 检查主库的重做日志发送状态（主库执行）
-- 查看日志传输状态
SELECT DESTINATION, STATUS, ARCHIVED_THREAD#, ARCHIVED_SEQ#
FROM V$ARCHIVE_DEST_STATUS WHERE STATUS != 'INACTIVE';

-- 检查是否有传输错误
SELECT MESSAGE FROM V$ARCHIVE_DEST_STATUS WHERE ERROR != '';
步骤 2：重启备库的 Redo Apply（核心解决步骤）
如果恢复进程未启动，手动启动 Redo Apply（备库执行），分两种场景：

场景 1：非实时应用（传统归档应用）
-- 启动介质恢复（基于归档日志）
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
场景 2：实时应用（Active Data Guard，备库只读打开时）
-- 先确保备库处于只读模式（如果之前是关闭的，先启动到mount再打开只读）
ALTER DATABASE MOUNT;
ALTER DATABASE OPEN READ ONLY;

-- 启动实时应用（实时应用主库的在线重做日志）
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
若启动时出现错误（如日志缺失）
检查缺失的日志序列：
-- 备库查看缺失的日志序列
SELECT SEQUENCE#, STATUS FROM V$ARCHIVED_LOG WHERE STATUS = 'DELETED' OR APPLIED = 'NO';
从主库手动传输缺失的归档日志到备库，并注册：
-- 备库注册手动传输的归档日志
ALTER DATABASE REGISTER PHYSICAL LOGFILE '/u01/app/oracle/oradata/archivelog/xxx.dbf';
重新执行恢复命令。
步骤 3：排查深层问题（若重启后仍报错）
如果启动 Redo Apply 后仍然报ORA-16766，需排查以下问题：

1. 检查备库的数据文件一致性
主库执行NOLOGGING操作（如直接路径加载数据、创建索引）会导致主备库数据文件不一致，备库无法应用日志。

主库检查 NOLOGGING 操作：

SELECT TABLE_NAME, LOGGING FROM DBA_TABLES WHERE LOGGING = 'NO';
SELECT INDEX_NAME, LOGGING FROM DBA_INDEXES WHERE LOGGING = 'NO';
解决：需要重新同步备库（如使用 RMAN 增量备份恢复、重建备库）。

2. 检查文件权限和路径
备库的归档日志目录（StandbyArchiveLocation = '/u01/app/oracle/oradata/archivelog'）的权限是否为oracle:oinstall；
检查DbFileNameConvert和LogFileNameConvert配置是否正确（如果主备库的文件路径不同，需配置该参数映射，否则备库会找不到数据文件 / 日志文件）。
3. 检查备库的参数配置
-- 备库检查关键参数
SHOW PARAMETER STANDBY_FILE_MANAGEMENT; -- 应为AUTO
SHOW PARAMETER LOG_ARCHIVE_DEST_2; -- 主库检查备库的归档目标配置
SHOW PARAMETER DB_UNIQUE_NAME; -- 主备库的DB_UNIQUE_NAME需不同（主库ycjj，备库ycjj2dg，已配置正确）
4. 检查网络连接和 TNS 配置
主备库之间的 TNS 连接是否正常（tnsping ycjj2dg、tnsping ycjj）；
Data Guard 的静态监听配置是否正确（备库的StaticConnectIdentifier已配置，需确保监听正常）。
步骤 4：验证恢复结果
备库执行以下命令，确认 MRP 进程启动：
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE 'MRP%';
若状态为APPLYING_LOG，说明恢复正常。

回到 DGMGRL 工具，检查配置状态：
dgmgrl /
DGMGRL> show configuration;
DGMGRL> show database ycjj2dg;
此时应无ORA-16766错误，配置状态变为SUCCESS。

总结
当前问题的核心是备库的 Redo Apply 未运行，优先通过手动启动备库的介质恢复进程解决；若启动失败，再依次排查日志缺失、数据文件一致性、权限 / 路径、网络配置等问题。如果是生产环境，建议开启实时应用（USING CURRENT LOGFILE）和 Fast-Start Failover 以提升可用性。

2. ORA-16826
DGMGRL> show configuration

Configuration - ycjj2dg

  Protection Mode: MaxPerformance
  Databases:
ycjj - Primary database
ycjj2dg - Physical standby database
   Warning: ORA-16826: apply service state is inconsistent with the DelayMins property

Fast-Start Failover: DISABLED

Configuration Status:
WARNING

DGMGRL>

DGMGRL> show database ycjj2dg;

Database - ycjj2dg

  Role:          PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag: 1 minute 33 seconds (computed 12 seconds ago)
  Apply Lag:    1 day(s) 20 hours 20 minutes 7 seconds (computed 9 seconds ago)
  Apply Rate:    9.49 MByte/s
  Real Time Query: OFF
  Instance(s):
ycjj

  Database Warning(s):
ORA-16826: apply service state is inconsistent with the DelayMins property

Database Status:
WARNING

DGMGRL>

现在的问题从之前的ORA-16766（Redo Apply 停止）变为了ORA-16826: apply service state is inconsistent with the DelayMins property（应用服务状态与DelayMins属性不一致），同时备库出现 ** 传输延迟较小（1 分 33 秒）但应用延迟极大（1 天 20 小时）** 的情况。以下是问题分析和解决步骤：

错误分析
该错误表示：

Data Guard 配置中DelayMins（日志应用延迟分钟数）设置为0（即无延迟应用），但备库的 Redo Apply 实际运行状态却带有延迟配置，或备库的应用进程未按照DelayMins的配置执行；
也可能是备库启动 Redo Apply 时指定了延迟应用（如DELAY参数），但 Data Guard 的DelayMins属性为 0，导致配置与实际运行状态冲突；
此外，** 应用延迟极大（1 天 20 小时）** 说明备库虽然在接收日志（传输延迟小），但日志应用被延迟或阻塞，这是引发该警告的关键原因。
因dg 备份还原主库到备库后，存在日志延迟应用导致了该问题，可以修改DelayMins降低延迟时间，消除警告。

解决问题
步骤 1：明确DelayMins配置和当前 Redo Apply 的运行模式
1. 查看 Data Guard 的DelayMins属性（DGMGRL 执行）
DGMGRL> show database ycjj2dg DelayMins;
从之前的输出可知DelayMins = '0'（无延迟），这是默认的正常配置。

2. 检查备库当前 Redo Apply 的运行状态（备库 SQL*Plus 执行，sysdba 身份）
-- 查看备库的恢复进程状态（关键看是否有DELAY配置）
SELECT PROCESS, STATUS, CLIENT_PROCESS, COMMAND
FROM V$MANAGED_STANDBY
WHERE PROCESS IN ('MRP0', 'MRP');

-- 查看备库的恢复配置（是否启用延迟应用）
SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME LIKE '%delay%';

-- 查看归档日志的应用情况（重点看最新序列的APPLIED状态）
SELECT SEQUENCE#, APPLIED, FIRST_TIME, NEXT_TIME
FROM V$ARCHIVED_LOG
ORDER BY SEQUENCE# DESC FETCH FIRST 20 ROWS ONLY;
如果V$MANAGED_STANDBY中MRP0进程的COMMAND列显示RECOVER但带有DELAY，说明实际运行了延迟应用；
如果归档日志的最新序列APPLIED为NO，且序列号远小于已接收的序列，说明应用被阻塞或延迟。
步骤 2：解决配置冲突并重启无延迟的 Redo Apply（核心步骤）
1. 先停止当前的 Redo Apply 进程（备库执行）
-- 停止所有正在运行的介质恢复进程
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
2. 启动无延迟的 Redo Apply（匹配DelayMins=0的配置）
根据备库的运行模式选择对应命令：

场景 1：备库处于 MOUNT 状态（非 Active Data Guard
-- 启动无延迟的介质恢复，直接应用已接收的归档日志（无延迟）
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
  DISCONNECT FROM SESSION; -- 无DELAY参数，对应DelayMins=0
场景 2：备库处于 READ ONLY 状态（Active Data Guard，实时应用）
-- 启动实时应用（使用主库当前的在线日志，无延迟）
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
  USING CURRENT LOGFILE
  DISCONNECT FROM SESSION; -- 实时应用，彻底消除延迟
关键说明：
上述命令未指定DELAY参数，与 Data Guard 的DelayMins=0属性完全一致，会直接消除ORA-16826警告；
如果之前启动 Redo Apply 时误加了DELAY [n] MINUTES参数（如ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DELAY 60 DISCONNECT;），会导致实际运行状态与DelayMins=0冲突，这是引发ORA-16826的最常见原因。
步骤 3：解决应用延迟极大的问题（传输正常但应用慢）
如果重启 Redo Apply 后，应用延迟仍很大（如 1 天 20 小时），需排查以下原因：

1. 检查备库的 Redo Apply 并行度（提升应用速度）
-- 查看当前并行度配置
SHOW PARAMETER APPLY_PARALLEL; -- Data Guard属性：ApplyParallel = 'AUTO'
SHOW PARAMETER RECOVERY_PARALLELISM;

-- 手动提升并行度（备库执行，停止恢复后设置）
ALTER SYSTEM SET RECOVERY_PARALLELISM = 4 SCOPE=BOTH; -- 根据CPU核心数调整，如4/8/16

-- 重启Redo Apply时指定并行度（可选）
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
  PARALLEL 4
  DISCONNECT FROM SESSION;
2. 检查备库是否存在日志应用阻塞
-- 查看备库的等待事件（是否有IO/锁阻塞）
SELECT EVENT, COUNT(*) FROM V$SESSION
WHERE STATUS = 'WAITING' AND PROGRAM LIKE '%ora_mrp%'
GROUP BY EVENT;

-- 检查是否有未应用的日志被锁定或损坏
SELECT SEQUENCE#, STATUS, ERROR FROM V$ARCHIVED_LOG WHERE APPLIED = 'NO';
如果存在IO wait（如磁盘 IO 瓶颈），需检查备库的存储性能（归档目录所在磁盘的 IO 使用率）；
如果日志状态为ERROR，需重新注册或从主库拷贝缺失的日志。
3. 检查主库的NOLOGGING操作（导致备库日志应用中断）
主库的NOLOGGING操作（如直接路径加载数据、创建索引）会导致备库数据文件不一致，从而阻塞日志应用：

-- 主库执行：检查是否有NOLOGGING操作
SELECT TABLE_NAME, LOGGING FROM DBA_TABLES WHERE LOGGING = 'NO';
SELECT INDEX_NAME, LOGGING FROM DBA_INDEXES WHERE LOGGING = 'NO';

-- 查看主库的日志历史中是否有NOLOGGING记录
SELECT TIMESTAMP, OPERATION, LOGGING FROM V$NOLOGGING_OPERATION;
如果存在NOLOGGING操作，需通过RMAN 增量备份同步备库数据文件，再重启 Redo Apply。
步骤 4：验证问题是否解决
1. 回到 DGMGRL 检查配置状态
DGMGRL> show configuration;
DGMGRL> show database ycjj2dg;
正常情况下，ORA-16826警告会消失，配置状态变为SUCCESS；
传输延迟和应用延迟会逐渐缩小（实时应用时应用延迟接近 0）。
2. 备库 SQL*Plus 验证应用状态
-- 查看MRP进程状态（应为APPLYING_LOG）
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE 'MRP%';

-- 查看最新日志的应用情况
SELECT SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE# DESC FETCH FIRST 1 ROW ONLY;
总结
当前ORA-16826的本质是Redo Apply 的实际运行状态（可能带延迟）与 Data Guard 的DelayMins=0配置冲突，同时备库应用延迟极大是因为日志应用未以无延迟 / 实时模式运行。解决步骤的核心是：停止现有恢复进程，启动无延迟的 Redo Apply（或实时应用），并根据情况提升并行度、排查阻塞因素。如果是生产环境，建议启用 Active Data Guard 的实时应用（USING CURRENT LOGFILE），彻底避免延迟问题。

3. 问题总结：
从你的输出可以看到问题经历了Redo Apply 停止（ORA-16766）→ 启动后出现配置不一致警告（ORA-16826）+ 应用延迟极大的过程，这说明核心矛盾是：Redo Apply 的实际运行状态与 Data Guard 配置不匹配，且日志应用存在阻塞 / 延迟。以下是针对性的完整解决流程，涵盖问题根因和落地步骤：

两个核心问题的关联

ORA-16766：Redo Apply 进程未运行，是初始状态，手动启动后该错误消失；
ORA-16826 + 应用延迟极大：启动 Redo Apply 时，实际运行模式带有延迟（或被阻塞），与DelayMins=0（无延迟）的配置冲突，且备库接收日志正常但应用速度极慢。
处理问题总结
步骤 1：彻底停止备库的 Redo Apply（清除旧的运行状态）
登录备库的SQL*Plus（sysdba 身份），执行以下命令停止所有恢复进程，避免残留状态干扰：

-- 停止介质恢复进程（无论当前是何种模式）
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

-- 确认进程已停止（查询无MRP0/MRP进程）
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE 'MRP%';
如果上述命令提示 “无恢复进程运行”，可忽略，继续下一步。

步骤 2：修复配置冲突，启动无延迟 + 高并行的 Redo Apply
1. （可选）优化备库应用并行度（解决应用速度慢的问题）
备库执行以下命令提升日志应用的并行度（根据 CPU 核心数调整，如 4/8/16）：

-- 设置恢复并行度（临时+永久）
ALTER SYSTEM SET RECOVERY_PARALLELISM = 8 SCOPE=sfpile;

-- 同时设置Data Guard的ApplyParallel属性（DGMGRL执行，可选）
DGMGRL> EDIT DATABASE 'ycjj2dg' SET PROPERTY ApplyParallel = '8';
修改Data Guard的ApplyParallel属性，Oracle先取消了日志应用，然后使用该修改的参数启动日志应用。

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
Sun Dec 21 22:32:14 2025
MRP0: Background Media Recovery cancelled with status 16037
Errors in file /u01/app/oracle/diag/rdbms/ycjj2dg/ycjj/trace/ycjj_pr00_100415.trc:
ORA-16037: user requested cancel of managed recovery operation
Recovery interrupted!
Recovered data files to a consistent state at change 11191119625
Sun Dec 21 22:32:17 2025
MRP0: Background Media Recovery process shutdown (ycjj)
Sun Dec 21 22:32:17 2025
Managed Standby Recovery Canceled (ycjj)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  THROUGH ALL SWITCHOVER DISCONNECT PARALLEL 8 USING CURRENT LOGFILE
Attempt to start background Managed Standby Recovery process (ycjj)
Sun Dec 21 22:32:17 2025
MRP0 started with pid=30, OS id=101257
MRP0: Background Managed Standby Recovery process started (ycjj)
started logmerger process
Sun Dec 21 22:32:22 2025
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 8 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Log /u01/app/oracle/oradata/archivelog1_43228_1196150430.dbf
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  THROUGH ALL SWITCHOVER DISCONNECT PARALLEL 8 USING CURRENT LOGFILE
Sun Dec 21 22:32:27 2025
RFS[4]: Selected log 5 for thread 1 sequence 43958 dbid 523858460 branch 1196150430
Media Recovery Log /u01/app/oracle/oradata/archivelog1_43229_1196150430.dbf
Sun Dec 21 22:32:37 2025
Archived Log entry 778 added for thread 1 sequence 43958 ID 0x2095edec dest 1:
Sun Dec 21 22:33:01 2025
RFS[3]: Selected log 5 for thread 1 sequence 43959 dbid 523858460 branch 1196150430
Sun Dec 21 22:33:01 2025
Archived Log entry 779 added for thread 1 sequence 43957 ID 0x2095edec dest 1:
Sun Dec 21 22:33:17 2025
Media Recovery Log /u01/app/oracle/oradata/archivelog1_43230_1196150430.dbf
Sun Dec 21 22:33:28 2025
Media Recovery Log /u01/app/oracle/oradata/archivelog1_43231_1196150430.dbf

2. 启动无延迟的实时应用（匹配 DelayMins=0，消除 ORA-16826）
根据备库的运行模式选择命令，推荐使用 Active Data Guard 的实时应用模式（备库只读打开，直接应用主库在线日志）：

场景 1：备库当前处于 MOUNT 状态
-- 先打开备库为只读模式（Active Data Guard）
ALTER DATABASE OPEN READ ONLY;

DGMGRL> show database ycjj2dg

Database - ycjj2dg

  Role:          PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag: 4 minutes 15 seconds (computed 0 seconds ago)
  Apply Lag:    1 day(s) 14 hours 33 minutes 53 seconds (computed 0 seconds ago)
  Apply Rate:    3.53 MByte/s
  Real Time Query: OFF
  Instance(s):
ycjj

  Database Warning(s):
ORA-16770: Redo Apply not started since physical standby database is opening

Database Status:
WARNING

DGMGRL>

# 当前ORA-16770错误的本质是备库刚完成 OPEN READ ONLY，但未启动 Redo Apply，解决步骤的核心是：在备库只读打开后，立即启动高并行的实时 Redo Apply。启动后，MRP 进程会开始应用堆积的归档日志和主库的实时日志，应用延迟会逐渐缩小，最终Apply Lag会接近 0（实时应用状态）。如果应用速度过慢，需检查并行度和 IO 性能，确保无日志间隙阻塞。

-- 启动实时应用（无延迟，直接应用主库当前在线日志）
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
  USING CURRENT LOGFILE  -- 实时应用主库在线日志，消除延迟
  PARALLEL 8          -- 高并行加速应用
  DISCONNECT FROM SESSION; -- 后台运行，不占用当前会话
场景 2：备库已处于 READ ONLY 状态
直接执行上述RECOVER MANAGED STANDBY DATABASE命令即可。

场景 3：无法开启 Active Data Guard（仅 MOUNT 模式）
-- 启动无延迟的归档日志应用（高并行）
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
  PARALLEL 8
  DISCONNECT FROM SESSION;
步骤 3：排查应用延迟极大的根因（若重启后仍有大延迟）
如果启动后应用延迟仍高达 1 天 20 小时，说明日志应用被阻塞，需排查以下关键点：

1. 检查备库是否缺失归档日志（最常见原因）
-- 备库查询未应用的日志，重点看是否有GAP（日志序列不连续）
SELECT * FROM V$ARCHIVE_GAP;

-- 查看所有归档日志的接收和应用状态
SELECT SEQUENCE#, APPLIED, STATUS, FIRST_TIME
FROM V$ARCHIVED_LOG
ORDER BY SEQUENCE# DESC FETCH FIRST 50 ROWS ONLY;
如果V$ARCHIVE_GAP有记录，说明存在日志间隙，需从主库拷贝缺失的日志到备库并注册：

-- 主库查找缺失的日志文件（假设GAP的序列是100-105）
SELECT NAME FROM V$ARCHIVED_LOG WHERE SEQUENCE# BETWEEN 100 AND 105;

-- 将这些日志文件拷贝到备库的归档目录后，备库执行注册
ALTER DATABASE REGISTER PHYSICAL LOGFILE '/u01/app/oracle/oradata/archivelog/1_100_123456.dbf';
2. 检查主库的 NOLOGGING 操作（导致备库数据不一致）
主库的NOLOGGING操作（如直接路径加载数据、创建索引）会让备库无法通过日志同步，从而阻塞应用：

-- 主库执行：查询是否有NOLOGGING操作
SELECT TIMESTAMP, OPERATION, TABLE_NAME FROM V$NOLOGGING_OPERATION;

-- 主库执行：检查对象的LOGGING属性
SELECT TABLE_NAME, LOGGING FROM DBA_TABLES WHERE LOGGING = 'NO';
若存在此类操作，需通过RMAN 增量备份同步备库：
主库执行 RMAN 增量备份（从备库最后同步的 SCN 开始）；
将备份集拷贝到备库；
备库恢复增量备份，然后重启 Redo Apply。
3. 检查备库的 IO 性能（磁盘瓶颈导致应用慢）
-- 备库查询MRP进程的等待事件（是否有IO阻塞）
SELECT EVENT, COUNT(*) FROM V$SESSION
WHERE STATUS = 'WAITING' AND PROGRAM LIKE '%ora_mrp%'
GROUP BY EVENT;
如果等待事件是db file sequential read/db file scattered read（IO 等待），需检查备库归档目录 / 数据文件所在磁盘的 IO 使用率（使用iostat/top命令），必要时迁移文件到高性能存储。
步骤 4：验证问题解决结果
1. 备库 SQL*Plus 验证进程状态
-- 查看MRP进程是否处于APPLYING_LOG状态
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#
FROM V$MANAGED_STANDBY
WHERE PROCESS LIKE 'MRP%';
正常状态应为：MRP0 / APPLYING_LOG（实时应用）或RECOVERING（归档应用）。

2. DGMGRL 验证配置状态
DGMGRL> show configuration;
DGMGRL> show database ycjj2dg;
正常情况下，ORA-16766和ORA-16826错误 / 警告消失，配置状态变为SUCCESS；
传输延迟和应用延迟会逐渐缩小（实时应用时应用延迟接近 0）。
总结
当前问题的解决核心是：

清除旧的 Redo Apply 状态，避免残留的延迟配置与DelayMins=0冲突；
启动无延迟 + 高并行的实时应用，匹配 Data Guard 的配置，消除ORA-16826；
排查日志间隙 / NOLOGGING 操作 / IO 瓶颈，解决应用延迟极大的问题。
如果是生产环境，建议长期启用Active Data Guard 的实时应用和Fast-Start Failover，提升 Data Guard 的可用性和性能。

RECOVERY_PARALLELISM（数据库参数）和ApplyParallel（Data Guard 配置属性）
在 Oracle Data Guard 和介质恢复中，RECOVERY_PARALLELISM（数据库参数）和ApplyParallel（Data Guard 配置属性）是控制 Redo Apply 并行度的两个核心参数，二者功能关联但作用层级、适用场景不同。以下是详细的区别、配置方法和最佳实践，结合你当前的备库应用延迟问题给出针对性建议。

核心概念与区别
特性 RECOVERY_PARALLELISM（数据库初始化参数） ApplyParallel（Data Guard 配置属性）
作用层级数据库实例级（Oracle 内核的介质恢复层） Data Guard 配置级（DG Broker 管理的应用层）
控制对象备库的 ** 介质恢复进程（MRP）** 的并行度，适用于所有介质恢复操作（包括手动RECOVER、备库 Redo Apply） DG Broker 管理的备库 Redo Apply 并行度，本质是对RECOVERY_PARALLELISM的封装和统一管理
适用场景所有 Oracle 版本（包括无 DG Broker 的备库） Oracle 11g+，且使用 DG Broker（dgmgrl）管理 Data Guard 时
默认值 0（由 Oracle 自动决定，通常为 CPU 核心数的 1/2） AUTO（等同于RECOVERY_PARALLELISM=0，由 Oracle 自动调整）
修改方式 SQL*Plus 中修改（静态 / 动态参数） DGMGRL 工具中修改（DG Broker 属性）
二、RECOVERY_PARALLELISM（数据库参数）详解
RECOVERY_PARALLELISM 控制备库介质恢复的并行进程数，即同时有多少个进程来应用重做日志（归档日志 / 在线日志）。值越大，并行度越高，日志应用速度越快（受 CPU、IO 资源限制）。

查看当前值
-- 备库SQL*Plus执行（sysdba身份）
SHOW PARAMETER RECOVERY_PARALLELISM;

-- 或查询数据字典
SELECT NAME, VALUE, DESCRIPTION FROM V$PARAMETER WHERE NAME = 'recovery_parallelism';
默认值为0：Oracle 会根据系统 CPU 核心数自动分配并行度（如 4 核 CPU 分配 2 个并行进程）。
修改方式
（1）动态修改（即时生效，重启后失效）
-- 临时设置并行度为8（根据CPU核心数调整，如4/8/16）
ALTER SYSTEM SET RECOVERY_PARALLELISM = 8 SCOPE=MEMORY;
（2）永久修改（重启后生效，需修改 spfile）
-- 永久设置并行度为8
ALTER SYSTEM SET RECOVERY_PARALLELISM = 8 SCOPE=SPFILE;

-- 重启备库实例使参数生效（需先停止Redo Apply）
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE OPEN READ ONLY;
三、ApplyParallel（DG Broker 属性）详解
ApplyParallel 是 DG Broker 通过该属性统一管理备库的 Redo Apply 并行度，其值会映射到底层的RECOVERY_PARALLELISM参数。当设置ApplyParallel=8时，DG Broker 会自动将备库的RECOVERY_PARALLELISM设为 8。

查看当前值
# DGMGRL工具执行
dgmgrl /
DGMGRL> show database ycjj2dg ApplyParallel;
默认值为AUTO：表示由 Oracle 自动调整并行度。
修改方式
（1）设置为具体数值（如 8）
# DGMGRL执行
DGMGRL> EDIT DATABASE 'ycjj2dg' SET PROPERTY ApplyParallel = '8';
（2）恢复为自动调整
DGMGRL> EDIT DATABASE 'ycjj2dg' SET PROPERTY ApplyParallel = 'AUTO';
生效条件
修改ApplyParallel后，需要重启备库的 Redo Apply（DG Broker 会自动重新应用参数）：

DGMGRL> EDIT DATABASE 'ycjj2dg' SET STATE = 'APPLY-OFF';
DGMGRL> EDIT DATABASE 'ycjj2dg' SET STATE = 'APPLY-ON';
四、针对当前备库问题的配置建议（解决应用延迟）
结合你当前备库**应用延迟极大（1 天 14 小时）*的问题，建议采用*高并行度配置，步骤如下：

步骤 1：优先通过RECOVERY_PARALLELISM设置高并行度（即时生效）
-- 备库SQL*Plus执行
-- 1. 停止当前的Redo Apply
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

-- 2. 设置并行度为8（根据CPU核心数调整，如16核CPU可设为16）
ALTER SYSTEM SET RECOVERY_PARALLELISM = 8 SCOPE=MEMORY;

-- 3. 启动高并行的实时Redo Apply
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
  USING CURRENT LOGFILE
  PARALLEL 8  -- 此处的PARALLEL参数会覆盖RECOVERY_PARALLELISM的临时值，双重保障
  DISCONNECT FROM SESSION;
步骤 2：（可选）通过 DG Broker 同步ApplyParallel属性
# DGMGRL执行，使DG Broker配置与数据库参数一致
DGMGRL> EDIT DATABASE 'ycjj2dg' SET PROPERTY ApplyParallel = '8';

# 验证配置
DGMGRL> show database ycjj2dg ApplyParallel;
DGMGRL> show database ycjj2dg;
步骤 3：监控并行度效果
-- 备库查看实际的恢复进程数（确认并行度是否生效）
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#
FROM V$MANAGED_STANDBY
WHERE PROCESS IN ('MRP0', 'PR00', 'PR01', 'PR02'); -- PR00-PR0n是并行恢复进程
如果看到多个PR00、PR01等进程，说明并行度已生效，日志应用速度会显著提升。
五、最佳实践
并行度取值建议：

通常设置为CPU 核心数的 1/2 到全部（如 8 核 CPU 设为 4 或 8）；
若备库存在 IO 瓶颈（iostat显示 % util 接近 100%），不建议设置过高并行度（会加剧 IO 竞争），需先优化存储性能。
生产环境配置：

无 DG Broker 的备库：直接设置RECOVERY_PARALLELISM为固定值（如 8）；
有 DG Broker 的备库：通过ApplyParallel属性统一管理，保持与RECOVERY_PARALLELISM一致。
避免过度并行：

并行度过高会导致 CPU、内存资源耗尽，反而降低应用速度。建议先从 4 开始测试，逐步提升至 8/16，观察应用速度和系统资源使用率。

总结
RECOVERY_PARALLELISM是底层的数据库参数，直接控制恢复并行度；ApplyParallel是 DG Broker 的上层属性，封装了前者的功能。针对你当前的备库应用延迟问题，核心是将并行度设置为合理的数值（如 8），并启动高并行的实时 Redo Apply，这样能显著加快堆积日志的应用速度，缩小应用延迟。

欢迎光临重庆思庄Oracle、KingBase、PostgreSQL、Redhat认证学习论坛 (http://bbs.cqsztech.com/)