物理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)自动检测备库上缺失或者损坏的归档文件,把这些归档日志重新发送。
首先必须要知道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;