DATAGUARD原理（三）--核心服务详解

物理DG的流程如下图：

Data Guard Services是整个DG体系的核心，共有三个Services：

（1）Redo Transport Services

        这个服务在主库上，用来把主库的redo 数据传到指定的归档路径上去。 这个传输过程是自动实现的。

（2）Apply Services

        这个服务器用在备库上，其用来应用redo data，已保持主备库数据的一致性。Redo data 可以通过归档日志来应用，如果启用了real-time apply，当数据写入到standby redo log后，就会直接进行apply，不需要先在备库进行归档切换操作。

（3）Role Transitions

        这个服务用来控制主备库角色的切换，可以使用switchover 或者failover进行。

========================================================================

一、Redo Transport Services

    Redo transport services 在不同Oracle 数据库之间自动传送redo data。 注意这里强调的是redo data不是redo log。 它使用Oracle Net sessions来传送redo data。 这些redo 传送session 使用Secure Socket Layer (SSL) 协议或者远程密码文件来进行验证。 SSL 是一个产业标准的网络连接协议。 SSL 使用RSA 公用密码或者对称密码来提供验证，加密和数据完整性功能。当Oracle Net能够匹配到LOG_ARCHIVE_DEST_n 和FAL_SERVER 初始化参数的值，那么就会使用SSL。   如果SSL 认证不可用，那么每个数据库都必须包含一个remote login password file。 在DG 环境下，所有的physical standby 和 snapshot standby 数据库必须要从primary 数据库copy 一份password file。

Redo transport services 主要负责如下工作：

（1）根据参数配置，把主库的redo data 传送到备库。

（2）管理gap的进程。

（3）自动检测备库上缺失或者损坏的归档文件，把这些归档日志重新发送。

配置 Redo Transport Services

首先必须要知道DG的数据保护模式，有三种：

1.最大保护（Maximum Protection）

        这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其REDO不仅被写入到本地的Online Redo logs，还要同时写入到Standby数据库的Standby Redo logs，并确认REDO数据至少在一个Standby数据库中可用（如果有多个的话），然后才会在Primary数据库上提交。

        使用这种方式要求Standby Database  必须配置Standby Redo Log，而Primary Database必须使用LGWR，SYNC，AFFIRM 方式归档到Standby Database.

如果出现了什么故障导致Standby数据库不可用的话（比如网络中断），Primary数据库会被hang，以防止数据丢失。

2.最高可用性（Maximum availability）

        这种模式在不影响Primary数据库可用前提下，提供最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求本地事务在提交前必须至少写入一台Standby数据库的Standby Redologs中，不过与最大保护模式不同。

        如果出现故障导致Standby数据库无法访问，Primary数据库并不会被Shutdown，而是自动转为最高性能模式，等Standby数据库恢复正常之后，Primary数据库又会自动转换成最高可用性模式。

        这种方式虽然会尽量避免数据丢失，但不能绝对保证数据完全一致。这种方式要求Standby Database  必须配置Standby Redo Log，而Primary Database必须使用LGWR，SYNC，AFFIRM 方式归档到Standby Database.

3.最高性能（Maximum performance）

        缺省模式。 这种模式在不影响Primary数据库性能前提下，提供最高级别的数据保护策略。事务可以随时提交，当前Primary数据库的REDO数据至少需要写入一个Standby数据库，不过这种写入可以是不同步的。如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护，而仅对Primary数据库的性能有轻微影响。这也是创建Standby数据库时，系统的默认保护模式。

这种方式可以使用LGWR ASYNC 或者 ARCH 进程实现，Standby Database也不要求使用Standby Redo Log。

关于数据保护模式的修改步骤如下：

a.关闭并启动到mount状态

b.ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE}; 

c.alter database open;--打开数据库

d.确认修改成功：select protection_mode,protection_level from v$database; 

了解了DG的数据保护模式我们再来看Redo Transport的配置，那官方文档中的例子来看：

DB_UNIQUE_NAME=BOSTON

LOG_ARCHIVE_CONFIG='DG_CONFIG=(BOSTON,CHICAGO,HARTFORD)' 

LOG_ARCHIVE_DEST_2='SERVICE=CHICAGO ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) REOPEN=60 COMPRESSION=ENABLE  DB_UNIQUE_NAME=CHICAGO' 

LOG_ARCHIVE_DEST_STATE_2='ENABLE' 

LOG_ARCHIVE_DEST_3='SERVICE=HARTFORD SYNC AFFIRM NET_TIMEOUT=30 VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) REOPEN=60 COMPRESSION=ENABLE   

DB_UNIQUE_NAME=HARTFORD' 

LOG_ARCHIVE_DEST_STATE_3='ENABLE'

这是一个主库参数配置的实例，从中可以看到BOSTON将redo分别以异步和同步的方式发送到CHICAGO和HARTFORD，参数含义如下:

SERVICE: 这个是一个强制的属性，而且也必须是第一个属性值。SERVICE 指定Oracle Net Service Name。就是tnsnames.ora 里面配置的名称。

SYNC/ ASYNC: 该属性用来指定使用同步/ 异步 方式来传送redo data 到destination。 默认使用ASYNC.

NET_TIMEOUT：该属性控制LGWR进程在中断网络连接之前等待网络服务进程状态的时间长短。如果在NET_TIMEOUT参数设置的值内还没有响应，LGWR进程就会返回错误信息。

DB_UNIQUE_NAME：该属性用来指定redo transport destination。 如果LOG_ARCHIVE_CONFIG 参数和DG_CONFIG属性已经配置，那么该属性必须指定，并且该值也必须匹配DG_CONFIG中的一个值。 如果匹配失败，就不会传送日志。

REOPEN ：该属性来用指定在之前ARCn 进程或LGWR 进程在错误过后多少秒之后重新连接并传送日志。

    standby库的2个进程：RFS（Remote File Server ）和ARCn。其中RFS 进程是专门用来接受并将日志写入standby的current standby redo log的。

    每个standby redo log file 至少要和primary database的redo log 一样大，为了方便管理，Oracle 建议主备库的redo log 设置成一样的大小。

Standby redo log group 至少要比primary database的redo log group 多一组。 可以在primary 库查询v$log视图，来确定主库有多少组redo log groups。 standby log 的存放位置由 STANDBY_ARCHIVE_DEST 或者LOG_ARCHIVE_DEST_n 参数指定。

    SQL> SELECT GROUP#, BYTES FROM V$STANDBY_LOG;