redo传输服务：redo transport service

主库的LNS进程从SGA的log buffer中读取日志，交给oracle net服务传输到备库，备库的RFS进程负责接收并写入SRL中，其中LNS的进程数量与备库RFS数量相等

redo的传输方式有：

• SYNC
• ASYNC
• ARCH

1）SYNC

SYNC的传输过程：

• 主库的LGWR将log buffer中的日志写入ORL之后将等待LNS的确认
• 主库LNS进程从log buffer中读取日志交给oracle net传输到备库，备库的RFS进程接收日志并写入SRL中
• RFS写入SRL完成后将从磁盘收到一个消息，并通过oracle net传回给主库的LNS，LNS通知LGWR传输完成，此时前台才会收到commit完成的消息

SYNC的优势：
确保主库提交的每一个事务得到保护，当主库崩溃时，不会造成任何数据损失

SYNC的劣势：
影响主库的性能，因为LGWR只有接收到LNS返回消息才能处理下一个事务。以下几个因素决定SYNC方式对主库性能的影响：

• 传输redo的大小
• 网络带宽，网络延迟
• 备库写入SRL的I/O

SYNC传输对应的LNS进程为NSS，官方解释如下：
NSSn

Redo Transport NSS1 Process

Acts as a slave for LGWR when SYNC transport is configured for a remote standby destination

NSSn can run as multiple processes, where n is 1-9 or A-V.

See Also: Oracle Data Guard Concepts and Administration

Database instance, Data Guard

2）ASYNC

ASYNC的传输过程：

• 与SYNC的不同之处在于LGWR无需等待LNS的确认消息，其他与SYNC方式几乎相同。
• 当LNS的进度赶不上LGWR写入ORL的进度时，LNS会转到ORL的当前日志读取redo传送到备库
• 当日志切换时，如果LNS仍然没有读取完该ORL，LNS将继续读取该ORL，读取完成后再读取当前的ORL
• 当LNS赶上LGWR的进度时，LNS将转回读取log buffer里的redo

X$LOGBUF_READHIST记录了log buffer的命中率

ASYNC的优势：
几乎不影响主库的性能。除了LNS进度赶不上LGWR时，会造成读取ORL的I/O消耗

ASYNC的劣势：
无法像SYNC一样对数据进行零丢失的保护，LGWR的进度-LNS的进度叫作transport lag，如果某个时刻，主库崩溃，若transport lag>0，那么transport lag所包含的所有已提交的事务将丢失

ASYNC传输对应的LNS进程为NSA，对应的官方解释如下：

NSAn

Redo Transport NSA1 Process

Ships redo from current online redo logs to remote standby destinations configured for ASYNC transport

NSAn can run as multiple processes, where n is 1-9 or A-V.

See Also: Oracle Data Guard Concepts and Administration

Database instance, Data Guard

3）ARCH
ARCH传输方式，在11g已经不推荐了。但在处理GAP时，使用的是ARCH模式

ARCH的传输过程：
当ORL归档完成后，由ARCH进程读取归档日志给oracle net
备库由RFS进程负责接收，写入备库的本地归档而不是SRL

Asynchronous Transport Architecture

Asynchronous redo transport (ASYNC) transmits redo data asynchronously with respect to transaction commitment. A transaction can commit without having to wait for an acknowledgement that the redo generated by that transaction has be successfully transmitted to a remote standby database. With Data Guard ASYNC, the primary database LGWR will continue to acknowledge commit success even if limited bandwidth prevents the redo of previous transactions from being sent to the standby database immediately (picture a sink filling with water faster than it can drain). Data Guard ASYNC uses an LNS process to transmit redo directly from the log buffer of the primary database. If LNS is unable to keep pace and the log buffer is recycled before the redo can be transmitted to the standby, the LNS automatically transitions to reading and sending from the online redo log file (ORL) on disk. Once LNS transmission has caught up with current redo generation it automatically transitions back to reading/sending directly from the log buffer. If ASYNC redo transport falls behind to the degree that the LNS is still in the ORL at log switch time, LNS will continue until it completes sending the contents of the original ORL. Once complete, it seamlessly transitions back
to reading/sending from the current online log file. When the LNS catches up with the LGWR, it seamlessly transitions back to reading/sending from the redo log buffer. In the rarer case in which there are two or more log switches before the LNS has completed sending the original ORL, the LNS will still transition back to reading the contents of the current online log file. Any ORLs that were archived in between the original ORL and the current ORL are transmitted via Data Guard’s gap resolution process.

redo传输压缩

11gr2：

 

SYNC方式只支持处理gap时使用压缩

Redo transport compression is no longer limited to compressing redo data only when a redo gap is being resolved. When compression is enabled for a destination, all redo data sent to that destination is compressed

The COMPRESSION attribute is used to specify that redo data is transmitted to a redo transport destination in compressed form. Redo transport compression can significantly improve redo transport performance on network links with low bandwidth and high latency. (启用redo传输压缩，会增加CPU使用率)

自动GAP处理

GAP处理过程：

• 在产生GAP期间，主库的ARCH进程会连续ping备库来确定备库状态，如果正常，主库ARCH进程会通过备库的RFS进程查询备库的控制文件，以确定备库从主库收到的最后一个完整的日志
• 使用其他的ARCH进程传输相应的归档日志到备库
• 当主库进行下一次日志切换时，LNS会连接备库开始传输log buffer的redo，ARCH继续处理GAP
• 备库的日志应用进程会读取备库归档日志进行recover，当备用应用进程进度赶上当前主库产生redo的进度时，改为读取SRL进行recover

ASYNC传输优化

• 增加log buffer
• 启用redo压缩

1）优化LNS读取redo速度（增加log buffer）
通过select bufsize,hitrate from x$logbuf_readhist where bufinfo=’CURRENT’查询log buffer命中率，如果命中率很低，说明LNS经常读取ORL。由于内存读取速度比磁盘读取速度快很多，所以增加log buffer可以提高LNS的读取速度。

2）优化LNS传输redo的速度（启用压缩）
经验：

• 当网络带宽超过100M/s时，redo压缩带来的收益并不明显，毕竟压缩是需要消耗CPU
• redo中是否含有大量的非结构化数据（如blob），因为非结构化数据压缩率极低。

 

启用redo压缩

• _redo_transport_compress_all=true
• async模式传输redo
• log_archive_dest_n的compression=enable

满足上述3个设置，即会为ASYNC的redo传输和发生GAP时ARCH发送归档的传输都启用压缩。当传输模式为sync时且compression=enable时，仅仅只对发生GAP时ARCH发送归档的传输启用压缩。