[DATAGUARD]

 

Oracle10g版本DataGuard通过以下三种机制实现主备之间的同步：

  • Redo Transport Services
  • Log Apply Services
  • Fetch archive log(FAL)

 

Redo传输服务(Redo Transport Service),负责主备之间redo data的传输和接收。这里的redo data可以是archive log也可以是online redo data。

Primary端，DataGuard可以选择使用归档进程(ARCn)或是日志写进程(LGWR)收集redo data并传输到Standby端。

注意：不能同时使用ARCn和LGWR进行传输redo data到同一个地址，但是你可以使用LGWR归档日志，使用ARCn传输redo data到另外一个地址,这需要定义不同的log_archive_dest_n参数。

 

另外，当主备之间出现GAP时，DataGuard通过FAL机制进行GAP archive log的自动检查和传输。

1 Using Archiver Processes (ARCn) to Archive Redo Data

默认，redo传输服务使用ARCn进程归档online redo log，但是仅在dataguard的最大性能保护模式上使用ARCn进程传输redo data，这是因为最大性能保护模式并不要求主备之间的实时同步，符合支持ARCn传输archive log的异步模式环境，而dataguard的其他两种模式则对主备之间的实时同步要求比较高。

DataGuard的其他两种保护模式（最高可用性和最大保护）必须使用LGWR进程传输redo data到standby端。

1.1 ARCn Archival Processing

DataGuard最大性能模式下，主备之间通过ARCn进程传输redo data的过程如下:

1. Primary端，ARC0进程归档online redo log至本地的LOG_ARCHIVE_DEST_1位置
2. ARC0归档完成后，ARC1进程传输该归档日志文件至本地LOG_ARCHIVE_DEST_2定义的Standby端

Primary上的这两步基本上没有争议，但standby端如何接收并apply归档日志一直没有确认，官方文档上这一段也写的相当不负责任。以至于google到的也主要有两种说法，如下：

观点1，参见《oracle实验记录 (oracle 10G dataguard(4)redo传输&进程)》：

1. standby rfs进程将redo写到 standby redo logfile中
2. standby的ARCn进程将standby redo logfile中的数据归档
3. standby的mrp(redo apply)或者lsp(sql apply)进程应用这些归档中的redo到standby database

这种观点认为，standby端由RFS进程接收由ARC1进程传过来的archive log并写入到本地的standby redo logfile中，然后在本地再次归档，然后由MRP进程(redo apply)或是LSP进程(sql apply)应用这些redo data至standby database里。

观点2，参见《physical data guard (Standby)的原理》：

1. RFS进程接收primary端传送的archive log
2. MRP进程使用此archive log进行redo apply

这种观点认为，standby端接收archive log后直接由MRP进程进行redo apply，并不使用standby redo logfile。

个人同意观点2，因为使用ARCn进程传输archive log至standby端时，主备之间至少已经有一个archive log的GAP了，既然并非real-time sync，所以此时ORACLE没有必要将传输过来的archive log解析后重新写入standby redo logfile，然后应用到本地库后再重新归档，完全可以直接apply了。

2 Using the Log Writer Process (LGWR) to Archive Redo Data

ARCn传送的是archive log，LGWR的传输机制与之不同，不再需要等待primary端的online redo logfile切换及归档后才开始传输。

Standby端apply节点的LGWR进程会选择一个standby redo logfile对应着primary端redo log的sequence号及大小。这样，当primary端有redo产生的时候，redo data也会传送至standby端。

根据LOG_ARCHIVE_DEST_n参数定义的SYNC或是ASYNC属性，LGWR传输redo data可以分为同步和异步两种方式。

注意：
1. 同步方式只能在DataGuard的最大保护(maximum protection)或是最高可用(maximum availability)的模式下实现，因为最大性能模式(max perfermance)的机制就是异步的。
2. redo传输服务必须在primary库的LOG_ARCHIVE_DEST_n参数定义LGWR以及SERVICE属性，才能使用LGWR进程传输redo data至standby端

2.1 LGWR SYNC Archival Processing

LGWR SYNC方式，需要在primary端配置参数如下：

LOG_ARCHIVE_DEST_1='LOCATION=/arch/'
LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR SYNC NET_TIMEOUT=30'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE

注意：LOG_ARCHIVE_DEST_2定义的”SERVICE=standby”，其中standby取值本地tnsnames.ora定义的standby apply node的Oracle Net名称。

LGWR SYNC传输redo data的过程如下：

1. Primary端产生redo data后，LGWR进程将redo data写入online redo logfile，同时提交redo data给多个网络服务(LNSn)进程
2. LNSn进程通过ORACLE Net服务将redo data传送至standby端
3. Standby端的RFS进程接收传输过来的redo data后，负责写入standby database上的standby redo logfile里。
4. 直到standby端所有定义了LGWR SYNC的LOG_ARCHIVE_DEST_n地址都接收完传过来的redo data后，primary端transactions才会commit

Primary端的log switch会触发standby上的日志切换，启动standby上的ARCn进程归档standby redo logfile。然后，MRP(redo apply)或者LSP(sql apply)进程将会应用redo data到standby database。

如果使用real-time apply，当RFS进程将redo data写入至standby redo logfile里，DataGuard会直接从current standby redo logfiles恢复redo data。

2.2 LGWR ASYNC Archival Processing

LGWR ASYNC方式，需要在primary端配置参数如下：

LOG_ARCHIVE_DEST_1='LOCATION=/arch/' 
LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR ASYNC' 
LOG_ARCHIVE_DEST_STATE_1=ENABLE 
LOG_ARCHIVE_DEST_STATE_2=ENABLE

注意：异步机制下，primary端不需要确认standby端的网络传输，故不用设置NET_TIMEOUT参数。

与同步模式不同的是，LGWR ASYNC不再等待Standby端的redo data传送完毕后才提交事务，流程如下：

1. Primary端产生redo data后，LGWR进程将redo data写入online redo logfile
2. 网络服务LNSn进程通过ORACLE Net服务非同步的将redo data传送至standby端
3. Standby端的RFS进程接收传输过来的redo data后，并负责写入standby database上的standby redo logfile里。
4. primary端LGWR不用确认LNSn进程的传输状态，直接将新的redo data写入online redo logfile

异步模式下的redo data recover与LGWR SYNC原理一样。

---最后总结---