Oracle Active Data Guard（ADG）的同步机制是其实现高可用性、灾难恢复和实时数据访问的核心。它基于物理备库（Physical Standby Database）技术，通过重做数据（Redo Data）的传输和应用来实现主库与备库的同步。以下是其核心原理的详细解析：
一、核心概念：重做数据(Redo Data)
当用户在主库上提交事务时，Oracle会生成重做记录（Redo Records）。这些记录包含了对数据库数据块进行修改所需的所有信息，用于保证数据的持久性和恢复能力。
ADG的本质就是将这些重做记录实时或近乎实时地从主库传输到备库，并在备库上重新应用（Replay）这些修改。
二、同步流程：
ADG的同步是一个持续不断的流水线作业，主要包含两个关键服务，一个是重做传输服务(Redo Transport Services)，一个是重做应用服务(Redo Apply Services)。
第一个关键服务: 重做传输服务(Redo Transport Services)
源：主数据库（Primary Database）。目标：备数据库（Standby Database）。
传输服务的几个关键进程：
1)LGWR (Log Writer)：主库的核心进程，负责将重做记录写入本地在线重做日志文件（Online Redo Log Files）。
2)LNSn (Log Writer Network Server Process - 可选但推荐)：当使用LGWR进程进行传输时（推荐模式），主库会启动一个或多个LNSn进程。LGWR将重做记录同时写入本地在线重做日志和LNSn进程的缓冲区。
3)ARCH (Archiver Process - 可选模式)：在较旧或特定配置下，ARCH进程负责在本地在线重做日志切换（Log Switch）后，将归档日志文件（Archived Redo Log Files）传输到备库。这种方式延迟较大，不是ADG推荐的实时同步模式。
传输模式(Protection Modes)：决定了重做数据如何传输以及数据保护级别。
1)`ASYNC` (最大性能模式 - 默认)：LGWR进程将重做数据写入本地在线重做日志后，异步地通过LNSn进程将数据发送到备库。主库事务提交不需要等待备库确认收到。延迟最小，对主库性能影响最小，但存在极小数据丢失风险（主库故障时未传输的重做记录）。
2)`SYNC` (最大可用性/保护模式)：LGWR进程同步地将重做数据同时写入本地在线重做日志和通过网络发送到至少一个备库。主库上的事务提交必须等待备库确认已收到并写入备库的Standby Redo Logs (SRLs)后，才能完成提交。这确保了零数据丢失（Zero Data Loss），但增加了主库事务的响应时间，对网络稳定性和备库性能要求更高。
网络传输：LNSn进程（或ARCH进程）使用Oracle Net Services协议将重做数据块通过网络发送到备库。
目标端接收（一个进程、一个日志）：
1)RFS (Remote File Server Process)：运行在备库上的进程，负责接收从主库发送过来的重做数据。
2)Standby Redo Logs (SRLs)：RFS进程将接收到的重做数据直接写入备用重做日志文件。SRL在物理结构和功能上与主库的在线重做日志文件完全相同，是备库接收重做数据的临时缓冲区。SRL的存在是ADG实现实时同步的关键基础之一。
第二个关键服务: 重做应用服务(Redo Apply Services)
源：备库上的Standby Redo Logs (SRLs) 或 归档日志（如果使用ARCH模式传输）。
目标：备库的数据文件（Data Files）。
重做应用服务的几个关键进程：
1)MRP (Managed Recovery Process) / Redo Apply：这是备库上的核心进程。它持续不断地从Standby Redo Logs (SRLs)中读取重做记录（如果启用了实时应用），或者从归档日志中读取重做记录。
应用重做日志的过程：
1)MRP进程物理地将SRL或归档日志中的重做记录应用到备库的数据文件上。
2)这个过程与主库上SMON/DBWR进程应用重做记录修改数据块的方式完全一致。
3)因为应用的是物理的块级更改，所以备库是主库在块级别上的精确副本（Block-for-Block Copy）。这保证了数据的物理一致性。
实时应用(Real-Time Apply - RTA)：ADG的核心优势所在。
1)备库配置了SRLs。
2)当主库工作在`SYNC`或`ASYNC`模式且使用LGWR进程传输时，备库的MRP进程可以直接从正在被RFS进程写入的SRL中读取和应用重做记录，而不需要等待SRL文件切换或归档。
3)这使得备库的数据几乎与主库保持实时同步（延迟通常在秒级，主要取决于网络传输时间和应用速度），显著缩小
了RPO (Recovery Point Objective)。
三、ADG 的独特之处：备库可以读了（打开只读访问），支持住备库的读写分离
传统的物理备库在应用重做时，数据库必须处于`MOUNT`状态，不可访问。ADG 的关键突破：它允许备库在应用重做数据的同时，以只读（READ ONLY）模式打开数据库。实现原理如下：
1)快照技术(Snapshot Technology)：ADG在后台巧妙地利用了一种类似快照的技术。
2)分离视图：当用户发起一个只读查询时：
3)查询看到的是在查询开始那一刻已经应用了所有重做记录的数据库状态（一致性快照）。
4)与此同时，MRP进程在后台继续应用新的重做记录，修改底层的数据块。
5)重做记录缓存：在查询执行期间，后台应用的重做记录会被缓存起来，不会影响当前查询看到的静态一致性视图。
6)无缝切换：一旦查询完成，缓存的修改会很快合并到用户下次查询可能看到的视图中。这个切换对用户是透明的。
带来的好处是：支持了主备库的读写分离，用户可以在备库上进行报表、查询、数据抽取等只读操作，获得近乎实时的数据视图，同时数据库恢复（应用重做）在后台持续进行，互不干扰。
四、再次回顾几个关键进程
1)LGWR/LNSn:主库发送重做的核心。
2)RFS:备库接收重做的核心。
3)Standby Redo Logs (SRLs):备库接收重做的缓冲区，实现实时传输和实时应用的基础。
4)MRP (Redo Apply):备库应用重做、保持同步的核心。
5)快照技术：实现只读打开与重做应用并行的魔法。
ADG的优势：
1. 高可用与灾难恢复 (HA/DR):提供快速故障切换能力（Fast-Start Failover），极小RPO（`SYNC`模式为零），可控RTO。
2. 实时数据访问：备库可读，提供近乎实时的业务报告、查询分流，减轻主库负载。
3. 数据保护：主库物理损坏（如块损坏）不会传播到备库（因为传输和应用的是逻辑重做记录）。
4. 高效同步：物理块级应用非常高效。
5. 简化管理：主备库结构相同，管理相对简单（通常通过Data Guard Broker）。
6. 数据恢复：结合备库的日志延迟应用，可实现主库在数据异常被改动情况下，通过控制备库的重做日志延迟应用之故障点前，可作为一种数据恢复的快速手段，切不影响主备同步架构。具体可见之前写的如下文章。
ADG实操：如何吃下这颗“后悔药” 点击链接
文章至此。