【DB笔试面试750】在Oracle中，请简单描述DG的架构。

2022-02-10 19:11:52

♣

题目部分

在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。