Oracle 数据保护模式（Data Guard）下的重做传输与应用服务-优快云博客

在这里插入图片描述
我将为您深入解析Oracle Data Guard的核心引擎：重做传输（Redo Transport） 与 日志应用（Redo Apply / SQL Apply）。理解这些内部原理是构建和管理高可用性、高可靠性数据库架构的基石。

第一部分：官方定义与核心作用

一、官方定义 (Official Definition)

Oracle Data Guard通过在不同站点的数据库之间传输重做数据并应用这些数据，来创建和维护一个或多个备用数据库（Standby Database）。备用数据库是主数据库（Primary Database）的事务一致性副本。

重做传输服务 (Redo Transport Services)：负责将主数据库产生的重做数据（Redo Data）安全、可靠地传输到一个或多个备用站点。
日志应用服务 (Log Apply Services)：负责在备用数据库上重演（Replay）接收到的重做数据，以使其与主数据库保持同步。

二、核心作用 (Purpose)

数据保护（Data Protection）：提供极低恢复点目标（RPO），甚至可实现零数据丢失（Zero Data Loss）。
高可用性（High Availability）：在主数据库发生计划内或计划外中断时，可快速将备用数据库切换（Switchover/Failover）为主数据库，极大缩短停机时间（RTO）。
负载分担（Offload Processing）：物理备用数据库可在只读模式下打开，用于分担报表查询、备份等只读工作负载。

通俗比喻：
将主数据库比作一家银行的中央总部，全天候处理交易。

重做传输：就像总部将每一笔交易的流水记录（重做日志） 通过安全的专线（网络）实时传真给一个或多个备用金库（备用数据库）。
日志应用：就像备用金库的工作人员，按照收到的交易流水记录，一丝不苟地同步更新自己金库的账本（数据文件）。
最终效果：一旦总部因故无法运营（灾难），任何一个备用金库都可以立即开门营业，担当起总部的职责，因为它的账本和总部的最后一笔记录都完全一致。

第二部分：深入底层原理与管理机制

一、重做传输服务 (Redo Transport Services)

1. 传输进程架构：

在主库上 (Primary Database)：
- LNSn (LogWriter Network Server process) 或 ARCH (Archiver process)：这是传输的发送方。使用哪种进程取决于配置的保护模式（后文详解）。
在备库上 (Standby Database)：
- RFS (Remote File Server process)：这是传输的接收方。它接收从主库发送来的重做数据，并将其写入备库的备用重做日志（Standby Redo Log, SRL） 文件中。

2. 关键组件：备用重做日志 (SRL)

作用：SRL是备库上的一个关键组件，其结构与在线重做日志（Online Redo Log, ORL）完全一致。它专门用于接收从主库传输过来的重做数据。
必要性：要启用实时应用（Real-Time Apply） 和同步传输（SYNC），必须配置SRL。SRL充当了重做数据在备库的“缓冲区”，确保即使应用进程暂时跟不上，数据也不会丢失。

3. 保护模式与传输模式：
保护模式决定了重做传输的机制和数据保护级别。

保护模式	传输机制 (如何发送)	确认机制 (何时算成功)	数据保护级别	性能影响
最大可用性 (MAXAVAILABILITY)	SYNC (同步)	LNSn进程直接发送给备库RFS进程，并等待其写入SRL并确认后，主库事务才提交。	零数据丢失（前提是备库无故障）。如果备库故障，主库自动降级为最大性能模式运行。	较高（受网络往返延迟影响）
最大性能 (MAXPERFORMANCE)	ASYNC (异步)	LNSn或ARCH进程发送重做数据。主库事务提交无需等待备库确认。	有数据丢失风险（丢失量通常为网络缓冲区中未传输的数据）。	极低（对主库性能影响最小）
最大保护 (MAXPROTECTION)	SYNC (同步)	同“最大可用性”，但如果备库无确认（如网络中断），主库将会关闭（Shutdown Abort），而不是继续运行。	绝对零数据丢失。	最高（必须保证网络极高可用性）

4. 传输过程详解（以SYNC模式为例）：

用户在主库提交事务（COMMIT）。
主库的LGWR进程将重做记录写入本地ORL。
同时，LGWR通知LNSn进程。
LNSn进程立即将重做数据通过网络发送给备库的RFS进程。
RFS进程将接收到的重做数据写入备库的SRL。
写入SRL成功后，RFS向主库的LNSn发送“确认收到”消息。
LNSn通知LGWR，LGWR才向用户返回“提交成功”。
整个过程，用户需要等待网络往返和备库写磁盘的延迟。

二、日志应用服务 (Log Apply Services)

1. 应用类型：

重做应用 (Redo Apply)：用于物理备用数据库（Physical Standby）。
- 原理：直接使用Oracle的介质恢复（Media Recovery）技术，将SRL或归档日志中的重做数据在数据块级别应用到备库。这相当于在备库上重复主库的所有物理更改，因此备库是主库的块对块完全副本。
- 进程：MRP (Managed Recovery Process) 或 MRP0（在Active Data Guard中为PR00）。
SQL应用 (SQL Apply)：用于逻辑备用数据库（Logical Standby）。
- 原理：从重做数据中挖掘出原始的SQL语句（如INSERT, UPDATE, DELETE），然后在备库上重新执行这些SQL语句。
- 进程：LSP (Logical Standby Process)。
- 特点：备库可以保持打开状态并提供读写服务（表在应用期间处于维护状态），但数据结构可以与主库不同（例如，可以额外创建索引）。

2. 应用模式：

实时应用 (Real-Time Apply)：MRP进程可以直接应用刚刚被RFS写入SRL的重做数据，而无需等待SRL文件被归档。这极大地减少了备库的延迟（Lag）。
归档应用：MRP进程只应用已归档的日志文件。这会引入延迟（至少是一个SRL文件写满并归档的时间）。

第四部分：争用、等待事件与排查解决

Data Guard的瓶颈通常出现在网络、I/O和应用速度三个层面。

1. 网络延迟与吞吐量问题

场景：在SYNC模式下，主库性能完全受限于到备库的网络延迟（Round-Trip Time）和带宽。
等待事件：
- 主库：LGWR-LNET wait on channel attach, LNS wait on SENDREQ, log file sync（因为提交在等待网络确认）。
- 备库：SQL*Net message from client（RFS进程等待主库发送数据）。

排查SQL：

-- 在主库查看LNS进程状态和是否发生等待
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS
FROM V$MANAGED_STANDBY
WHERE PROCESS = 'LNS';

-- 查看备库的RFS进程接收日志的统计信息
SELECT PROCESS, CLIENT_PID, STATUS, THREAD#, SEQUENCE#, BLOCK#
FROM V$MANAGED_STANDBY
WHERE PROCESS = 'RFS';

解决方案：
- 使用低延迟、高带宽的专用网络（如万兆/InfiniBand）。
- 对于ASYNC模式，可以调整NET_TIMEOUT和ASYNC Blocksize来优化吞吐量。
- 如果网络是绝对瓶颈，考虑改用ASYNC模式。

2. 备库I/O或CPU性能瓶颈（应用延迟）

场景：主库生成重做日志的速度超过了备库应用重做日志的速度。导致数据延迟（Lag）持续增长。
等待事件：在备库上，MRP进程会出现常见的I/O等待事件，如 db file sequential read, db file scattered read, log file sync（应用重做时也会产生重做日志）。

排查SQL：

-- 查看备库的延迟情况（这是最重要的视图）
SELECT * FROM V$DATAGUARD_STATS;

-- 查看当前MRP进程的应用进度
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS
FROM V$MANAGED_STANDBY
WHERE PROCESS = 'MRP0';

-- 查看备库的I/O和CPU负载（需要在OS层面或使用AWR报告）

解决方案：
- 优化备库硬件：确保备库的I/O子系统（特别是SRL和数据文件所在磁盘）性能与主库匹配甚至更强。
- 启用并行应用（仅限逻辑备库或12c+的物理备库）：ALTER DATABASE START LOGICAL STANDBY APPLY PARALLEL; 或为物理备库设置PARALLEL参数。
- 调整恢复进程优先级（在OS层面）。

3. 归档速度慢

场景：如果未使用实时应用，备库必须等待SRL文件写满并被归档后，MRP才能开始应用。
等待事件：ARCH wait on NET IO（如果归档来自网络），ARCH wait on SENDREQ，或本地归档的I/O事件。
解决方案：
- 启用实时应用（Real-Time Apply）：这是最根本的解决方案。ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
- 优化备库的归档目标磁盘I/O性能。

第五部分：常用监控SQL

综合监控备库状态与延迟：

-- 查看备库的整体状态、数据库角色、保护模式等
SELECT DATABASE_ROLE, DB_UNIQUE_NAME, OPEN_MODE, PROTECTION_MODE, PROTECTION_LEVEL,
       SWITCHOVER_STATUS, DATAGUARD_BROKER, GUARD_STATUS
FROM V$DATABASE;

-- 查看所有Data Guard相关进程的状态（在主库或备库执行都非常有用）
SELECT PROCESS, PID, STATUS, CLIENT_PROCESS, CLIENT_PID, THREAD#, SEQUENCE#, BLOCK#, BLOCKS
FROM V$MANAGED_STANDBY;

查看日志传输的GAP（间隙）：

-- 在备库上执行，查看当前缺少哪些归档日志
SELECT * FROM V$ARCHIVE_GAP;

-- 在主库上查询备库所需的最大日志序列号
SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED = 'YES' AND DEST_ID = 2;
-- 与主库当前日志序列号对比
SELECT MAX(SEQUENCE#) FROM V$LOG;

监控应用进度：

-- 在备库执行，查看已接收和已应用的日志序列号
SELECT AL.THREAD#, AL.MAX_SEQUENCE# "Last Seq Received", LH.MAX_SEQUENCE# "Last Seq Applied"
FROM (SELECT THREAD#, MAX(SEQUENCE#) MAX_SEQUENCE# FROM V$ARCHIVED_LOG GROUP BY THREAD#) AL,
     (SELECT THREAD#, MAX(SEQUENCE#) MAX_SEQUENCE# FROM V$LOG_HISTORY GROUP BY THREAD#) LH
WHERE AL.THREAD# = LH.THREAD#;

总结

官方总结：Data Guard的重做传输与应用服务是一个复杂而精密的体系。重做传输通过LNS/RFS进程和SRL文件，以同步或异步模式确保重做数据可靠地到达备库。日志应用服务则通过MRP（物理）或LSP（逻辑）进程，以实时或归档模式将重做数据重演到备库，实现数据的同步。其性能与可靠性取决于网络、主备库I/O以及配置模式的平衡。

通俗总结：Data Guard是一个超高效率的“跨国抄书”团队。

重做传输：好比主库的通讯员（LNS） 骑着摩托车（网络），将主库账本（重做日志）的每一页新内容（重做记录） 飞速送往备库。同步模式下，他必须等备库的收发员（RFS） 签收并放入专用信箱（SRL）后，才能回去报信（确认），主库才能进行下一页。异步模式下，他放下页就走，不管签收。
日志应用：好比备库的誊写员（MRP），从专用信箱（SRL）里取出新页，一丝不苟地抄到自己的账本上（应用）。实时应用下，他守在信箱旁，来一页抄一页。归档应用下，他等信箱攒满一摞（SRL归档）后才一次性取走抄写。

DBA的职责是担任这个团队的总指挥：