Dataguard三种保护模式

标签：

 Oracle Data Guard 提供三种高水平的数据保护模式来平衡成本、可用性、性能和事务保护。可以使用任意可用管理界面来轻松地设置这些模式。要确定适当的数据保护模式，企业需要根据用户对系统响应时间的要求来估量它们对数据保护的业务要求。下表从数据丢失风险的角度概述了各种模式的适用性。

10g中，物理Standby和逻辑Standby都支持这三种模式。

可以在V$DATABASE中查看到DataGuard的保护模式

SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE;

1.1 最大保护模式：

        最大保护模式为主数据库提供了最高水平的数据保护，从而确保了一个全面的零数据丢失灾难恢复解决方案。当在最大保护模式下运行时，重做记录由日志写入进程从主数据库同步地传输到备用数据库，并且直到确认事务数据在至少一个备用服务器上的磁盘上可用时，才在主数据库上提交事务。这种模式必须配置至少两个备用数据库，从而提供双重故障保护。当最后参与的备用数据库不可用时，主数据库上的处理将停止。这就确保了当主数据库与其所有备用数据库失去联系时，不会丢失事务。

        该模式下，主库和备库完全一致，在主库事务提交前，备库必须收到全部日志数据，如果因网络等原因导致日志无法传送时，将引起严重的性能问题，导致主节点宕机。此时备库不能正常关闭，必须保持和主库一致的模式，如果强行采用abort方式关闭备用数据库，可能引发主库挂起。推荐配置至少2个备库，因为如果其中一个不能从主库接收日志，主库还可继续运行。要保证备库的监听正常，保证主库到备库的连接正常。

1.2 最大可用模式：

       10g时该模式利用LNSn进程传送日志，备库必须添加Standby Redo Log。最高可用性模式拥有仅次于主数据库数据可用性，并提供零数据丢失和防止单组件故障。如同最大保护模式一样，重做数据由日志写入进程从主数据库同步地传输到备用数据库，直到确认事务数据在备用服务器的磁盘上可用时，事务才在主数据库上完成。不过，在这种模式下（与最大保护模式不同），如果最后参与的备用数据库变为不可用 — 例如由于网络连接问题，处理将在主数据库上继续进行。备用数据库与主数据库相比，可能暂时落在后面，但当它再次变为可用时，备用数据库将自动同步，而不会丢失数据。由于同步重做传输，这种保护模式可潜在地影响响应时间和吞吐量。可以通过配置一个低延迟网络，并为它分配足够应付高峰事务负载的带宽来将这种影响减到最小。最高可用性模式适用于想要在生产站点上出现严重中断时（假定没有其他故障）确保获得零数据丢失保护，但不想让生产数据库受网络/备用服务器故障影响的企业。与最大保护模式一样，采用LGWR方式传送，并且必须有standby redo log。为防止备用库发生网络故障，最好设置reopen参数，即使出现网络故障，也不会引发主库挂起，这时主库将从最大可用模式切换到最大性能模式。该模式下，允许数据分歧，允许异步传送。正常情况运行在最大保护模式下，在主库和备库之间网络断开或连接不正常时，自动切换到最大性能模式，主节点的操作继续，但这种自动切换是否及时是否高效，当前行内并无实际检验，因此在网络不好的情况下，也可能会有较大的性能影响。

1.3 最大性能模式：

        最高性能模式是默认的保护模式。它与最高可用性模式相比，提供了稍微少一些的主数据库数据保护，但提供了更高的性能。在这种模式下，当主数据库处理事务时，重做数据由日志写入进程异步传输到备用数据库上。另外，也可以将主数据库上的归档进程配置为在这种模式下传输重做数据。在任何情况下，均先完成主数据库上的写操作，主数据库的提交操作不等待备用数据库确认接收。如果任意备用目标数据库变为不可用，则处理将在主数据库上继续进行，这对性能只有很小的影响或没有影响。不过在这种情况下，数据库告警日志将记录错误消息，并可以通过 Enterprise Manager 相应地设置告警。在主数据库出现故障的情况下，可能有一些在主数据库上提交了的事务没有传输到备用数据库中。如果网络有足够的吞吐量来跟上重做流量高峰，则丢失的事务将非常少或者为零。当主数据库上的可用性和性能比丢失少量数据的风险更重要时，应该使用最高性能模式。这种模式还适合于 WAN 上的 Data Guard 部署，在 WAN 中，网络的内在延迟可能限制同步重做传输的适用性。在创建Data Guard时，默认创建的是最大性能模式，需要使用其他模式时必须再进行切换。该模式下，利用ARCn进程异步传送日志，无数据同步检查，可能丢失数据，但是能获得主库的最佳性能。

1.3.1  使用推荐

推荐使用最大性能模式。

1.4 其他介绍

1.4.1  Real-Time Apply和Redo Apply

         Redo信息传送到备库后，默认是Redo Apply方式，在最大保护模式下，确认redo信息传送到备机后主库提交，但并非立即在备库启用，而是等待主库发生redo日志切换后再在备库应用。最大性能模式下发生redo日志切换后，ARCn才将该日志传送至备库应用。在这种方式下允许设置日志应用的延迟时间间隔（delay）。当备库切换为生产前，需要首先应用已传送到备库但尚未被应用的redo（除非强制切换）。Real-TimeApply方式要求必须有Standby log file(默认最大性能模式下不必创建)，此时Redo信息传送到备库后被立即应用，此模式下如果有delay设置将被忽略。该方式可以提高备库转为生产的速度。

            对Redo Apply增加数据文件后，需要切换日志，备用数据库才能产生文件。

            对Real-TimeApply增加数据文件后，备用数据库很快就能产生文件。

 推荐在无delay需求的情况下，使用Real-Time Apply方式；在有delay需求的情况下，使用Redo Apply方式。

 在物理备用数据库上查看，是否real-time applyredo log

1.4.2  Delay的设置及确认

在一些情况下，会想在重做数据从主站点接收到它应用到备数据库的时间之间创建一个时间延迟。允许设置DELAY 指定时间间隔(分钟)来保护损坏或错误的数据的应用到备数据库。设置后，重做数据传输到备数据库不会有延迟，指定的时间延迟从重做数据完整地归档后开始。

使用LOG_ARCHIVE_DEST_n 初始化参数的DELAY=minutes 属性，在主和备数据库上设置时间延迟来延迟应用归档重做日志文件到备数据库。默认没有时间延迟。如果指定DELAY 而没有指定一个值，默认的延迟间隔是30 分钟。

取消时间延迟：

对于物理备数据库，使用 RECOVER MANAGED STANDBY DATABASE 字句的NODELAY关键词：

ALTERDATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

Dataguard三种保护模式

标签：

原文地址：http://www.cnblogs.com/hllnj2008/p/4797393.html