题目部分
在Oracle中，请简单描述DG的架构。
答案部分
DG架构图如下所示：
图 3-20 DG架构图
DG架构按照功能可以分成3个部分：
（1）日志发送（Redo Send）
（2）日志接收（Redo Receive）
（3）日志应用（Redo Apply）
下面分别来介绍这3个部分。
1、日志发送（Redo Send）
主库（Primary Database）在运行过程中，会源源不断地产生Redo日志，这些日志需要发送到备库（Standy Database）端。这个发送动作可以由主库的LGWR或者ARCn进程完成，不同的归档目的地可以使用不同的方法，但是对于一个目的地，只能选用一种方法。选择不同的进程在数据保护能力和系统可用性方面有很大区别。如果使用LGWR进程来传递日志，但是由于某些原因，LGWR进程变得无法归档到目的地了，那么重做传输将会使用ARCn进程来完成归档操作。
若不配置传输进程和模式的话，在Oracle 11g下则默认为LGWR ASYNC方式，在Oracle 10g下则默认为ARCH模式。下表列出了DG传输进程及其模式的关系。
表 3-31 DG传输进程及其模式表
版本 | 10g | 11g | ||||
|---|---|---|---|---|---|---|
传输模式 | LGWR ASYNC（异步） | LGWR SYNC（同步） | ARCH | LGWR ASYNC | LGWR SYNC | ARCH |
后台进程表现（ps -ef|grep -v grep|grep -E "ora_lns|ora_nsa|ora_nss"） | ora_lns1_mydg | ora_lnsb_mydg | ora_arc3_mydg | ora_nsa2_mydg | ora_nss2_mydg | ora_arc3_mydg |
视图GV$MANAGED_STANDBY | LNS | LGWR | ARCH | LNS | LGWR | ARCH |
切换日志的时候告警日志 | 出现过一次，LNS: Standby redo logfile selected for thread 1 sequence 13 for destination LOG_ARCHIVE_DEST_2，但再切换的时候就不出现了 | 无 | 无 | LNS: Standby redo logfile selected for thread 1 sequence 98 for destination LOG_ARCHIVE_DEST_2 | LNS: Standby redo logfile selected for thread 1 sequence 98 for destination LOG_ARCHIVE_DEST_2 | ARC0: Standby redo logfile selected for thread 1 sequence 102 for destination LOG_ARCHIVE_DEST_2 |
是否默认 | 否 | 否 | 是，默认采用归档进程传送 | 是，默认采用LGWR异步模式传送 | 否 | 否 |
（一）使用ARCH进程
① 主库（Primary Database）不断产生Redo日志，这些日志被LGWR进程写到联机日志。
② 当一组联机日志被写满后，会发生日志切换（Log Switch），并且会触发本地归档，本地归档位置是采用“LOG_ARCHIVE_DEST_1='LOCATION=/path'”格式定义的。例如，修改本地归档的SQL语句可以是：“ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/u01/arch' SCOPE=BOTH;”。
③ 完成本地归档后，联机日志就可以被覆盖重用。
④ ARCH进程通过网络把归档日志发送给备库（Standby Database）的RFS（Remote File Server）进程。
⑤ 备库端的RFS进程把接收的日志写入到归档路径中。
⑥ 若是物理DG的话，则备库的MRP（Managed Recovery Process）进程进行Redo Apply；若是逻辑DG的话，则备库的LSP（logical standby process）进程进行SQL Apply进而同步数据。
用ARCH模式传输不写Standby Redo Logs，直接保存成归档文件存放于Standby端。
逻辑备库接收日志后将日志转换成SQL语句，然后逻辑备库上的LSP进程执行这些SQL语句进而实现主备库的数据同步，这种方式叫SQL Apply。物理备库接收完主库生成的Redo数据后，MRP进程以介质恢复的方式实现同步，这种方式也叫Redo Apply。
使用ARCH进程传递最大问题在于：主库只有在发生归档时才会发送日志到备库。如果主库异常宕机，那么联机日志中的Redo内容就会丢失，所以，使用ARCH进程无法避免数据丢失的问题，要想避免数据丢失，就必须使用LGWR，而使用LGWR又分SYNC（同步）和ASYNC（异步）两种方式。
（二）使用LGWR进程的SYNC方式
① 主库产生的Redo日志要同时写到日志文件和网络，也就是说LGWR进程把日志写到本地日志文件的同时还要发送给本地的LNSn进程（LGWR Network Server Process），再由LNSn进程把日志通过网络发送给远程的目的地，每个远程目的地对应一个LNS进程，多个LNS进程能够并行工作。
② LGWR必须等待写入本地日志文件操作和通过LNSn进程的网络传送都成功，主库上的事务才能提交，这也是SYNC的含义所在。
③ 备库的RFS进程把接收到的日志写入到Standby Redo Log日志中。
④ 主库的日志切换也会触发备库上的日志切换，即主库对Standby Redo Log的归档，然后触发备库的MRP或者LSP进程应用归档日志。
（三）使用LGWR进程的ASYNC方式
使用LGWR SYNC方法的可能问题在于，如果日志发送给备库过程失败，那么LGWR进程就会报错。也就是说主库的LGWR进程依赖于网络状况，有时这种要求可能过于苛刻，这时就可以使用LGWR ASYNC方式。它的工作机制如下所示：
① 主库一旦产生Redo日志，LGWR就把日志同时提交给日志文件和本地LNS进程，但是LGWR进程只需成功写入日志文件就可以，不必等待LNSn进程的网络传送成功。
② LNSn进程异步地把日志内容发送到备库，多个LNSn进程可以并发发送。
③ 主库的联机Redo日志文件写满后发生Log Switch，触发归档操作，也触发备库对Standby Redo Log的归档；然后触发MRP或者LSP进程恢复归档日志。
2、日志接收（Redo Receive）
备库的RFS（Remote File Server）进程接收到日志后，就把日志写到Standby Redo Log或者Archived Log文件中，具体写入哪个文件，取决于主库的日志传送方式。如果写到Standby Redo Log文件中，那么当主库发生日志切换时，也会触发备库上的Standby Redo Log的日志切换，并把这个Standby Redo Log归档；如果是写到Archived Log，那么这个动作本身也可以看作是个归档操作。在日志接收中归档日志会被放在LOG_ARCHIVE_DEST_n指定的位置。
3、日志应用（Redo Apply）
日志应用服务，就是在备库上重演主库的日志，从而实现两个数据库的数据同步。
根据Redo Apply发生的时间不同可以分成两种：一种是实时应用（Real-Time Apply），这种方式必须包含Standby Redo Log，每当日志被写入Standby Redo Log时，就会触发恢复，使用这种方式的好处在于可以减少数据库切换（Switchover或者Failover）的时间，因为切换时间主要用在剩余日志的恢复上。另一种是归档应用，这种方式在主库上发生日志切换，会触发备库的归档操作，归档完成后触发恢复。这也是默认的恢复方式。
根据备库重演日志方式的不同，可分为Redo Apply和SQL Apply：若是物理DG的话，则备库的MRP（Managed Recovery Process）进程进行Redo Apply。物理备库接收完主库生成的Redo数据后，MRP进程以介质恢复的方式实现同步，这种方式叫Redo Apply。若是逻辑DG的话，则备库的LSP（logical standby process）进程进行SQL Apply进而同步数据。逻辑备库接收日志后将日志转换成SQL语句，然后逻辑备库上的LSP进程执行这些SQL语句进而实现主备库的数据同步，这种方式叫SQL Apply。
