1 引言

在数字化转型持续深化的今天，数据库作为信息系统的核心基础设施，其高可用性与容灾能力直接关系到企业业务的连续性和数据安全。无论是金融交易、政务系统还是智能制造，一旦数据库服务中断，轻则造成业务停摆、经济损失，重则影响社会稳定与公共安全。如何在硬件故障、自然灾害、网络中断等极端场景下保障数据不丢失、服务不中断，已成为每一家企业IT架构建设中的核心命题。

针对这一需求，主备集群架构因其成熟可靠、成本可控而成为业界主流的高可用与灾备方案。其基本思想是：部署一主一备或多备数据库节点，通过日志同步机制将主库的数据变更实时复制到备库，当主库发生故障时，备库迅速接管服务，从而实现高可用。围绕这一架构，国内外数据库厂商均推出了各自的主备集群产品，其中最具代表性的当属达梦数据库的DM数据守护（Data Watch） 与Oracle数据库的Data Guard。

本文将从架构设计、数据同步机制、备库模式与保护模式等维度，对DM数据守护与Oracle Data Guard进行全方位对比

2 产品概述

2.1 DM DataWatch概述

DM数据守护（Data Watch）是达梦数据库提供的一种集成化的高可用、高性能数据库解决方案，被定位为数据库异地容灾的首选方案。通过部署DM数据守护，可以在硬件故障（如磁盘损坏）、自然灾害（地震、火灾）等极端情况下避免数据损坏与丢失，保障数据安全，并能实现数据库服务的快速恢复。

与传统数据库备份还原技术相比，DM数据守护具有显著效率优势。传统备份还原随着数据规模增长，恢复往往需要数小时甚至更久，而数据守护基本不受数据规模影响，只需数秒即可完成备库到主库的切换，对外恢复数据库服务。

在实现原理上，DM 数据守护（DM Data Watch）的实现原理非常简单：将主库（生产库）产生的 Redo 日志传输到备库，备库接收并重新应用 Redo 日志，从而实现备库与主库的数据同步。DM 数据守护的核心思想是监控数据库状态，获取主、备库数据同步情况，为 Redo 日志传输与重演过程中出现的各种异常情况提供一系列的解决方案。

在集群形态上，DM数据守护支持多种部署方式，以适应不同场景的需求：

实时主备：由一个主库和一个或多个配置了实时归档的备库组成，保障数据库可用性与数据安全性。

MPP主备：为MPP大规模并行处理集群的每个节点配置实时主备系统，组间独立运行，保障MPP集群整体可用性。

DMDSC主备：支持DMDSC共享存储集群与单节点互为主备，实现共享存储集群的容灾。

读写分离集群：由一个主库和一个或多个即时/实时归档备库组成，在保障可用性基础上实现读写分离，通过JDBC、DPI等接口自动将只读操作分流至备库，降低主库负载。

2.2 Oracle DataGuard概述

Oracle Data Guard是Oracle数据库提供的一套全面的高可用性、数据保护与灾难恢复解决方案。它提供了一套综合性的服务，用于创建、维护、管理和监控一个或多个备用数据库，使生产Oracle数据库能够经受住灾难和数据损坏的考验。

在一个Data Guard配置中，包含一个生产数据库（主库）和最多九个备用数据库。主数据库与备用数据库通过Oracle Net连接，可以在地理上分散部署——例如，可以将一个备用数据库部署在与生产数据库相同的站点，同时将另外两个备用数据库部署在远程站点。Data Guard将备用数据库维护为与主数据库在事务上一致的副本，当生产数据库因计划内或计划外停机而不可用时，Data Guard可以将任意一个备用数据库切换为主数据库角色，从而最大限度地减少停机时间。

根据应用方式的不同，备用数据库可分为两类：

物理备库（Physical Standby） ：通过Redo Apply方式，在物理层面与主库保持完全一致，主要用于灾难恢复和备份操作。

逻辑备库（Logical Standby） ：通过SQL Apply方式，将主库的变更转换为SQL语句在备库执行，除灾难恢复外还可用于报表查询等只读业务。

3 架构对比

3.1 DM数据守护架构

DM数据守护系统主要由以下核心组件构成：

（1）主库（Primary）与备库（Standby）

主库是提供完整数据库服务的生产节点，处理所有读写请求。备库以只读模式运行，接收主库的Redo日志并重演以保持数据同步。备库支持联机备份、查询等只读操作。DM数据守护最多支持一主八备。

数据库在Data Watch体系中有三种运行模式：

Normal模式：提供无限制的正常数据库服务。

Primary模式：提供正常服务，仅极少数操作受限；除临时表空间外，所有数据库对象修改强制生成Redo日志。

Standby模式：仅支持联机备份、查询等只读操作。

（2）Redo日志、Redo日志传输与Redo日志重演

Redo日志记录主库的所有数据变更。主库将物理事务的修改记录打包为RLOG_PKG（Redo日志包），通过MAL系统发送至备库。MAL系统是基于TCP协议实现的一种内部通信机制，具有可靠、灵活、高效的特性。备库接收到Redo日志后，通过重演（Redo Apply）实现与主库的数据同步。

（3）守护进程（dmwatcher）与监视器（dmmonitor）

守护进程是管理数据守护系统的核心部件。它部署于每台数据库服务器上，负责实时监控数据库实例状态与网络连通性，执行故障检测、故障处理、故障恢复等各种功能。

监视器负责监控守护系统内守护进程和数据库实例的信息，执行用户输入的命令，监控实例故障，实现自动切换等。监视器一般部署在数据库实例和守护进程以外的独立机器上。监视器分为确认监视器和普通监视器两种——自动切换模式必须配置确认监视器。

（4）三元协同架构

DM数据守护采用“主库—备库—守护进程”三元协同架构。数据库实例向本地守护进程发送信息，接收守护进程的消息和命令；监视器接收守护进程的消息并向守护进程发送命令；数据库实例与监视器之间没有直接的消息交互。守护进程通过心跳机制（默认60秒）监控节点状态，形成了立体化的监控网络。
DM数据守护的系统结构图如图所示：

整个系统通过心跳机制构建立体化监控网络。在物理部署上，MAL系统通常需要在数据库服务器上单独规划网卡，并与业务网络隔离。

3.2 Oracle DataGuard架构

Oracle Data Guard配置由以下核心组件构成：

（1）主数据库与备用数据库

一个Data Guard配置包含一个主数据库和一个或多个备用数据库。主数据库是大多数应用程序访问的生产数据库，可以是单实例Oracle数据库或Oracle RAC集群。备用数据库是与主数据库在事务上保持一致的副本，同样可以是单实例数据库或Oracle RAC集群，一个主库最多可配置九个备库。备用数据库是主数据库的事务一致性副本。它最初由主数据库的备份副本创建，创建完成后，Data Guard通过将主数据库的Redo数据传输到备用系统并应用Redo日志来自动维护备用数据库。备用数据库可分为两种类型，物理备用数据库和逻辑备用数据库。

（2）日志传输服务（Log Transport Services）与日志应用服务（Log Apply Services）

日志传输服务控制Data Guard配置中重做数据的自动传输，将重做数据从主系统传输到一个或多个归档目标。日志应用服务将从主库传输过来的重做数据应用到备库——如果配置了备库Redo日志文件，则采用实时应用方式；否则需要先将日志归档再应用。日志应用服务使备库与主库保持同步。

Data Guard使用多个后台进程协同完成日志传输与应用：

LGWR（Log Writer） ：主库上负责将重做日志写入本地联机日志文件，同时可通过网络将重做数据传输到备库。

NSS/NSA（Network Server Process） ：主库上负责将重做数据从日志缓冲区发送到备库。

ARCn（Archiver Process） ：主库和备库上都存在，负责归档日志文件的写入与传输。

RFS（Remote File Server） ：备库上接收来自主库的重做数据。

MRP（Managed Recovery Process） ：备库上负责将接收到的重做日志应用到备数据库。

（3）Data Guard Broker

Data Guard Broker是一个分布式管理框架，用于自动化并集中化Data Guard配置的创建、维护和监控。通过Broker，管理员可以使用命令行接口（DGMGRL）或图形化界面（Oracle Data Guard Manager）来管理主库和备库。Broker配置最多可包含253个成员，包括主数据库、备用数据库、Far Sync实例和零数据丢失恢复设备等。

（4）Far Sync实例

Far Sync实例是Oracle Data Guard的一种轻量级组件，它接收来自主库的重做数据但不应用这些数据。Far Sync实例可以部署在远程站点，通过同步方式接收主库的重做数据，再以异步方式转发给远程的备库，从而在长距离灾备场景下兼顾零数据丢失与主库性能。

（5）网络通信

Data Guard配置中的数据库通过Oracle Net会话传输重做数据和控制消息。与DM数据守护要求独立的MAL网络不同，Oracle Data Guard的数据同步依赖于普通的业务网络。

3.3 架构对比小结

对比维度	DM数据守护	Oracle Data Guard
核心组件	主库、备库、Redo日志、守护进程（dmwatcher）、监视器（dmmonitor）	主库、备库、日志传输服务、日志应用服务、Data Guard Broker
进程模型	单进程多线程（dmserver主进程）	多进程协作（LGWR、NSS、ARCn、RFS、MRP等）
管理监视	监视器（dmmonitor）统一管理	Data Guard Broker分布式管理框架
网络要求	MAL系统独立网络，建议与业务网络隔离	Oracle Net，依赖普通业务网络

4 备库模式与保护模式

DM数据守护与Oracle Data Guard在数据保护机制上都围绕一个核心问题展开：如何在数据安全与主库性能之间取得平衡。DM以“备库模式”为粒度定义同步策略，Oracle以“保护模式”为粒度定义，在数据保护和延迟容忍度上实时备库对应最大性能模式，异步备库对应最大可用性模式，

4.1 最大性能模式与异步备库模式

4.1.1 最大性能（Maximum Performance）

这是Oracle Data Guard的默认保护模式。主数据库处理事务时，LGWR 将 redo 日志先写本地，Redo数据异步传输到备用数据库。主数据库上的提交操作不等待备用数据库确认收到Redo数据即可完成写入操作。如果任何备用目标不可用，主数据库的处理继续，对主数据库性能影响很小。

最大性能模式在数据保护与主库性能之间偏向后者——RPO>0，但主库性能几乎不受影响。

4.1.2 异步备库（Asynchronous Standby）

异步备库是三种模式中对主库性能影响最小的一种。对应最大性能模式，主库事务提交后无需等待备库任何确认即可返回，Redo日志由主、备库上配置的定时器触发，根据异步备库的KEEP LSN信息扫描本地归档目录获取Redo日志，并通过MAL系统发送到异步备库。

当主库故障时，异步备库可能存在分钟级的数据延迟（RPO>0），一般用于历史数据统计、周期报表等对数据实时性要求不高的业务场合。异步归档时机可以选择在源库空闲的时候，可避免源库的业务高峰期同步数据对性能的影响。

4.2 最大可用性模式与同步备库

4.2.1 最大可用性（Maximum Availability）

最大可用性模式要求至少一个同步备库确认写入后才提交，在正常情况下与最大保护模式行为一致。核心区别在于降级策略：当备用数据库不可用时，保护模式自动降级为最大性能模式，主数据库继续处理事务。故障修复后，备用数据库与主数据库重新同步，模式自动恢复。

最大可用性模式在备库可用时保证RPO=0，同时通过自动降级机制保障了主库的持续可用性。

4.2.2 同步备库（Synchronous Standby）

根据最大可用性模式的特点：备库不可用时，主库不会关闭，而是自动降级为“最大性能”模式继续运行。在DM DataWatch里最相似的是同步备库。
同步备库最能对应最大可用模式的降级策略——归档失败时不会导致主库切换到Suspend状态，而是直接将备库归档状态改为Invalid，主库继续正常提供服务。当备库故障恢复后，主库将归档状态从Invalid改为Async_send，开始同步历史数据到备库，同步完成后恢复为Valid状态，主备库数据重新一致。
同步备库在备库可用时保证RPO=0，同时通过“不阻塞主库”的机制保障了主库的持续可用性，与Oracle最大可用性模式的语义最为接近。

4.3 最大保护模式与实时备库（事务一致模式）

4.3.1 最大保护（Maximum Protection）

最大保护模式提供最高级别的数据保护。数据从主数据库同步传输到备用数据库，只有当Redo数据在至少一个配置为此模式的备用数据库上可用时，事务才会在主数据库上提交。如果最后一个配置为此模式的备用数据库不可用，主数据库的处理将停止。

最大保护模式保证零数据丢失（RPO=0） ，但代价是主库可用性可能受影响。Oracle官方建议运行在最大保护模式下的配置应包含至少两个物理备用数据库。

4.3.2实时备库（事务一致模式）

实时备库是DM数据守护中最常用的同步模式。主库在写入联机日志之前，通过MAL通道同步发送Redo日志到备库，备库实时重演日志，收到备库确认（ACK）后主库才完成本地写入。延迟可达毫秒级。

实时备库通过ARCH_WAIT_APPLY配置项分为两种模式：
高性能模式（ARCH_WAIT_APPLY=0）：备库收到即响应，异步重演，存在短暂延迟
事务一致模式（ARCH_WAIT_APPLY=1）：备库重演完成后响应，严格保证事务一致性
其中事务一致模式在语义上与Oracle最大保护模式最为接近：
同步传输：主库在写入联机日志前发送Redo，备库确认后才完成写入
零数据丢失：备库重演完成后主库才提交，RPO=0
备库不可用时阻塞：主库发送日志到实时备库失败后，会进入Suspend状态，与最大保护模式“主库停止处理”的语义一致
当主库故障时，备库完成日志重演后可自动切换为主库。实时备库适合对数据一致性要求极高、可接受主库在备库故障时短暂挂起的核心交易场景。

订阅备库适合核心金融、支付等对数据丢失零容忍的场景，但需要接受主库可用性可能受影响的风险。

4.4 对应关系

综合上述分析，DM三种备库模式与Oracle三种保护模式可建立如下映射关系：

5 数据同步机制对比

数据同步机制是主备集群最核心的技术环节。DM数据守护与Oracle Data Guard虽然都基于Redo日志实现数据同步，但在技术实现上还存在显著差异。

5.1 Oracle Data Guard同步机制

5.1.1 基本原理

Data Guard的工作原理是通过网络将主数据库的重做数据传输到备用数据库，然后在备用数据库上应用这些重做数据，以确保数据的一致性。Data Guard的数据同步过程可分为三个阶段：日志传输、日志接收、日志应用。

主库在运行过程中会不断地产生Redo日志，这些日志需要发送到备库，发送动作有两种传输方式：ARCH进程（传归档日志） 和LGWR进程（传重做日志）。

5.1.2 日志传输

5.1.2.1 ARCH进程传输（传归档日志）

ARCH方式是Oracle Data Guard默认的传输方式。其工作流程如下：

主库：LGWR将Redo日志写入在线重做日志（Online Redo Log）。当在线重做日志写满或发生日志切换时，ARC0进程将该日志归档至主库本地的归档目录。

主库：归档完成后，ARC1进程将归档日志传输到备库。

ARCH方式的特点：只有在主库日志归档的时候才会发送日志到备库。这种方式下，如果发生主库宕机，在线重做日志（Online Redo Log）中的数据就会丢失。

5.1.2.2 LGWR进程传输（传重做日志）

使用LGWR进程传输与ARCH方式有显著区别——不需要等主库完成日志切换后再传输，只要有新的Redo日志产生即可触发传输。LGWR传输分为SYNC（同步） 和ASYNC（异步） 两种模式。

ASYNC模式（异步传输）

主库侧：

只要有新的Redo日志产生，LGWR进程触发LNSn进程，将新生成的Redo日志传输到备库。ASYNC模式下，LNSn在Redo Buffer保存到Online Redo Log之后才开始传输。LGWR无需等待LNS的确认信息，备库几乎对主库没有任何性能影响。

备库侧：

RFS进程接收日志后写入Standby Redo Log（备用重做日志） 。如果备库开启了实时应用（Real-time Apply） ，则立即做日志应用；如果没有开启，则等Standby Redo Log归档后再应用。

SYNC模式（同步传输）

主库侧：

Redo Buffer中只要有新的变更产生，LGWR进程触发LNSn进程将新生成的Redo日志传输到备库。与ASYNC模式的关键区别在于：SYNC模式下，LNSn在Redo Buffer时就开始传输，也就是说从内存中就开始传输，并不写入Redo Log。

当事务提交时，LGWR从Log Buffer中读取Redo Record并将其写入Online Redo Logs，与此同时等待LNS进程的确认。LNS从Redo Buffer中读取相同的Redo Record，通过Oracle Net将其传输到备库。只有当LNS确认日志被传输到备库并且已经写入磁盘后，主库上的Commit操作才会被认为成功。

备库侧：

RFS进程接收日志后写入Standby Redo Log。如果备库开启了实时应用，立即做日志应用；否则等Standby Redo Log归档后再应用。备库需要给主库一个回复，证明传输成功。

SYNC模式能保护所有的数据都不会丢失，但是有可能会影响到主库的性能。

Fast Sync模式（12c新增）

从Oracle 12c开始，Data Guard增加了Fast Sync模式。该模式结合了SYNC和ASYNC的优势——主库等待备库确认收到Redo日志，但不等待Redo日志写入磁盘，在保障极低数据丢失风险的同时降低了对主库性能的影响。

5.1.3 日志接收与日志应用

（1）日志接收

备库的RFS进程负责接收从主库传输过来的Redo日志。RFS接收日志后的处理方式取决于传输方式和备库配置：

如果配置了Standby Redo Log：RFS将日志写入Standby Redo Log → Standby Redo Log做Log Switch形成归档日志 → 应用归档日志做恢复

如果没有配置Standby Redo Log：RFS接收日志后直接放到备库的归档目录下，再应用该日志做恢复

（2）日志应用

日志应用根据备库类型不同而不同：

物理备用数据库（Physical Standby） ：通过MRP（Managed Recovery Process）进程执行Redo Apply，以物理块为单位应用Redo日志，是主库逐块对应的精确物理副本

逻辑备用数据库（Logical Standby） ：使用逻辑进程将Redo日志转换为SQL语句执行（SQL Apply）

5.2 DM数据守护同步机制

5.2.1 基本原理

DM数据守护的实现逻辑非常清晰：主库将产生的Redo日志传输至备库，备库接收并重新应用（重演）该日志，从而实现与主库的数据同步。其核心思想是通过监控主备库状态及数据同步情况，针对Redo日志传输与重演过程中可能出现的异常提供解决方案。

5.2.2 Redo日志包（RLOG_PKG）

DM中Redo日志的基本传输单位是RLOG_PKG（Redo日志包） 。RLOG_PKG是DM数据库批量保存Redo日志的数据单元，以物理事务（PTX）为单位保存日志，一个日志包内可以连续保存一个或多个PTX。物理事务提交时将Redo日志写入日志包，在数据库事务提交或日志包被写满时触发日志刷盘动作。

主库产生的日志数据以RLOG_PKG为单位，通过达梦专用的MAL系统发送到备库。各种不同数据守护类型的区别，就在于主库发送RLOG_PKG的时机，以及备库收到Redo日志后的处理策略。

5.2.3 归档类型与日志传输

DM的日志传输通过MAL系统完成，这是一套专用的内部通信机制。根据功能与实现方式的不同，DM 数据库的归档可以分为 6 类：本地归档、远程归档、实时归档、即时归档、异步归档和同步归档。其中，本地归档日志的内容与写入时机与数据库模式相关；主库 Redo 日志写入联机日志文件后，再进行本地归档；备库收到主库产生的 Redo 日志后，直接进行本地归档，同时启动 Redo 日志重演。主要介绍以下几种归档模式：

（1）本地归档（Local）

本地归档是将Redo日志写入本地归档日志文件的过程。Normal/PRIMARY模式库在Redo日志写入联机Redo日志文件后，将对应的RLOG_PKG由专门的归档线程写入本地归档日志文件中。STANDBY模式库收到主库产生的Redo日志后，直接进行本地归档，写入本地归档日志文件中，同时启动Redo日志重演。

主库与备库归档内容的差异：

库模式	归档日志来源	归档内容与联机日志的关系
PRIMARY	当前节点产生的Redo日志	一致
STANDBY	主库产生的Redo日志	不完全一致——备库重演产生的Redo只写入联机日志，归档保存的是主库的Redo日志

这种设计确保了数据守护系统中所有节点的归档日志文件内容完全一致。

（2）实时归档（Realtime）

实时归档将主库产生的Redo日志通过MAL系统传递到备库，是实时主备和MPP主备的实现归档在主库生效，一个主库最多可配置1~8个实时备库。

执行流程：

主库在Redo日志（RLOG_PKG）写入联机日志文件前，将RLOG_PKG发送到备库

备库收到RLOG_PKG后标记为KEEP_RLOG_PKG，加入日志重演任务系统，并立即响应主库（不等待重演完成）

主库收到备库确认消息后，再将Redo日志写入联机日志文件

模式	配置值	备库响应时机	一致性保证
高性能模式	ARCH_WAIT_APPLY=0（默认）	收到即响应，异步重演	存在短暂延迟
事务一致模式	ARCH_WAIT_APPLY=1	重演完成后响应	严格事务一致性

实时归档通过ARCH_WAIT_APPLY配置项可分为两种模式：

实时归档默认采用高性能模式。

（3）即时归档（Timely）

即时归档与实时归档的核心区别在于Redo日志的发送时机不同——主库在Redo日志写入联机日志文件后，再通过MAL系统发送到备库。一个主库最多可配置1~8个即时备库。

即时归档同样通过ARCH_WAIT_APPLY配置项分为两种模式，但默认值与实时归档相反——默认采用事务一致模式（ARCH_WAIT_APPLY=1）：

事务一致模式下，同一事务的SELECT语句无论是在主库还是在备库执行，查询结果都满足READ COMMIT隔离级要求。高性能模式则通过牺牲一致性获得更高的吞吐量。

（4）异步归档（Async）

异步归档由主备库上配置的定时器触发，根据异步备库的KEEP LSN信息，扫描本地归档目录获取Redo日志，并通过MAL系统发送到异步备库。异步备库的Redo日志重演过程与其他归档类型完全一致。

核心特点：

每个PRIMARY或STANDBY模式数据库最多可配置8个异步备库

支持级联配置——异步备库本身也可以作为源库配置异步备库

归档时机可调度，可选择源库空闲时段触发

主库事务提交无需等待备库任何确认

（5）同步归档（Sync）
同步归档在主库归档日志刷盘后，通过MAL系统将Redo日志发送到备库。备库收到RLOG_PKG后加入日志重演任务系统，并立即响应主库。一个主库最多可配置1~8个同步备库。
同步归档与实时归档的区别在于发送时机不同——实时归档在写入联机日志前发送，同步归档在归档日志刷盘后发送。并且同步归档备库不具备KEEP_RLOG_PKG机制。当主库发送同步归档失败后，直接将该备库的归档状态改为Invalid，并且不会让主库切换到Suspend状态。备库故障恢复后，主库将归档状态从Invalid改为Async_send，开始同步历史数据到备库，同步完成后恢复为Valid状态。
（6）订阅归档（Subscribe）
订阅归档（Subscribe）是一种改进的异步归档，仅配置在备库上。订阅备库需要在归档配置文件中指定源库连接串，直接通过该连接串连接源库，订阅备库与源库之间不依赖 MAL 系统进行通讯，无需配置 dmmal.ini。订阅备库通过定时器定时获取源库的归档日志并重演。
订阅归档失败时，不会导致源库Suspend，仅将该归档状态置为无效，等待下次定时触发继续尝试。
订阅备库适合需要备库主动拉取日志的场景（如跨网络防火墙、源库不便开放入站连接等），本质上属于异步归档，始终存在rpo，不保证零数据丢失。

5.2.4 日志重演机制

备库接收到主库的Redo日志后，通过日志重演进程对Redo日志进行解析和重演操作。重演进程严格按照日志产生的顺序进行解析和修改相应物理页的数据。在备库重演过程中产生的Redo日志会写入备库的联机日志文件中。

5.3 对比小结

综合5.1和5.2的分析，DM数据守护与Oracle Data Guard虽然在数据同步的基本理念上一致——均基于Redo日志的传输与重演——但在以下关键技术维度上存在显著差异：

（1）传输粒度的差异

Oracle以Redo Record为单位逐条传输，实时性高但网络开销相对较大；DM以RLOG_PKG为批量传输单位，一个包内可包含多个物理事务的Redo日志，网络效率更高但单次传输延迟略大。

（2）发送时机的差异

Oracle的ARCH方式仅在日志切换后发送，LGWR方式在Redo产生时即可发送；DM的发送时机由归档类型决定——实时归档在联机日志写入前发送，即时归档在联机日志写入后发送，异步归档由定时器触发发送，同步归档在归档日志刷盘后发送。DM提供了更丰富的发送时机选择。

（3）确认粒度的差异

Oracle的确认粒度是固定的——备库RFS收到Redo并写入Standby Redo Log即向主库返回确认。DM提供了可配置的确认粒度——在实时归档和即时归档中均可通过ARCH_WAIT_APPLY配置为“收到即确认”（高性能模式）或“重演完成才确认”（事务一致模式），后者提供更强的一致性保障。

（4）传输通道的差异

Oracle通过标准的Oracle Net Services传输，依赖业务网络；DM采用专用的MAL系统传输，通常需单独规划网卡并与业务网络隔离。MAL专用通道在传输稳定性和隔离性上更有优势，但增加了网络规划的复杂度。

（5）备库日志机制的差异

这是两者在实现哲学上的一个本质区别：Oracle物理备库应用Redo日志时不产生新的Redo日志；DM备库在重演Redo日志时，会生成自己的Redo日志并写入联机日志文件，同时归档保存的是主库的Redo日志而非备库自身重演产生的日志。DM的这种设计使主备库的归档日志内容完全一致，为备份恢复和故障重建提供了统一的基础。

（6）发送进程的差异

Oracle为每个备库启用一个独立的LNSn进程，多备库场景下进程资源消耗较大但相互隔离；DM采用内置发送线程统一管理所有备库的日志发送，资源消耗更低。

6 小结

本文围绕架构设计、备库模式与保护模式、数据同步机制三个维度，对DM数据守护与Oracle Data Guard进行了系统性的对比分析。
在架构层面，两者均采用主备架构，依赖Redo日志同步实现数据一致性，但在实现方式上存在显著差异。Oracle采用多进程协作模型（LGWR、LNSn、ARCn、RFS、MRP等），通过Data Guard Broker进行集中化管理；DM采用单进程多线程模型，通过守护进程（dmwatcher）与监视器（dmmonitor）分工协作实现监控与切换决策。在传输通道上，Oracle依赖业务网络，DM则采用MAL专用通道，支持独立组网。
在备库模式与保护模式上，两者均提供三种级别的同步策略——Oracle的最大性能、最大可用性、最大保护模式，与DM的异步备库、同步备库、实时备库的事务一致性模式形成对应关系。而DM在实时备库和即时备库中通过ARCH_WAIT_APPLY参数提供了可选的确认粒度（高性能模式/事务一致模式），为DBA提供了更灵活的配置选择。
在数据同步机制上，两者的核心差异体现在几个方面：Oracle以Redo Record为单位逐条传输，DM以RLOG_PKG为单位批量传输；Oracle依赖Oracle Net，DM采用MAL专用通道；Oracle为每个备库启用独立的LNSn进程，DM采用内置发送线程统一管理；DM备库在重演过程中会生成自身的Redo日志并写入联机日志，归档日志直接保存主库Redo日志，使主备库归档日志内容完全一致。
综上，Oracle Data Guard凭借长期积累和丰富生态，在功能全面性和复杂企业级场景中具有优势。DM数据守护则在部署效率、架构简洁性（单进程多线程）、同步策略灵活性（可配置不同归档类型和主备模式）以及国产化自主可控等方面形成了自身特点。