一、在Oracle的DG中，RFS、LNSn、MRP、LSP进程的作用分别是什么？

1.RFS进程

RFS（Remote File Server）进程主要用来接受从主库传送过来的日志信息。对于物理备库而言，RFS进程可以直接将日志写进Standby Redo logs，也可以直接将日志信息写到归档日志。

2.LNSn（LGWR Network Server process）进程

DG可以使用ARCn、LGWR来传送日志，但它们都是把日志发送给本地的LNSn（如果有多个目标备库，那么会启动相应数量的LNSn进程，同时发送数据）进程，然后备库的RFS进程接收数据，接收到的数据可以存储在备库的备用Redo日志文件中或备库的归档日志中，然后再应用到备库中。

3.MRP（Managed Recovery Process）进程

该进程只针对物理备库，作用为应用从主库传递过来的Redo日志到物理备库，称为Redo Apply。如果使用SQL语句“ALTER DATABASE RECOVER MANAGED STANDBY DATABASE”启用该进程，那么前台进程将会做恢复。如果加上DISCONNECT语句，那么恢复过程将在后台进程，发出该语句的进程可以继续做其它的事情，

4.LSP（logical standby process）进程

只有逻辑备库才会有该进程。LSP进程控应用Redo日志到逻辑备库。

二、Oracle DG的架构

  1.主库和备库：

主库是生产环境中的数据库，处理日常的业务操作。备库是主库的副本，用于在需要时接管主库的工作负载。主备库之间通过网络进行通信和数据传输。

   2.日志发送（Redo Send）:

主库（Primary Database）在运行过程中，会源源不断地产生Redo日志，这些日志需要发送到备库（Standy Database）端，这个发送动作可以由主库的LGWR或者ARCn进程完成，不同的归档目的地可以使用不同的方法，但是对于一个目的地，只能选用一种方法。

传输方式如下：

（1）使用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（异步）两种方式。

（2）使用LGWR进程的SYNC方式

①　主库产生的Redo日志要同时写到日志文件和网络，也就是说LGWR进程把日志写到本地日志文件的同时还要发送给本地的LNSn进程（LGWR Network Server Process），再由LNSn进程把日志通过网络发送给远程的目的地，每个远程目的地对应一个LNS进程，多个LNS进程能够并行工作。

②　LGWR必须等待写入本地日志文件操作和通过LNSn进程的网络传送都成功，主库上的事务才能提交，这也是SYNC的含义所在。

③　备库的RFS进程把接收到的日志写入到Standby Redo Log日志中。

④　主库的日志切换也会触发备库上的日志切换，即主库对Standby Redo Log的归档，然后触发备库的MRP或者LSP进程应用归档日志。

（3）使用LGWR进程的ASYNC方式：

使用LGWR SYNC方法的可能问题在于，如果日志发送给备库过程失败，那么LGWR进程就会报错。也就是说主库的LGWR进程依赖于网络状况，有时这种要求可能过于苛刻，这时就可以使用LGWR ASYNC方式。它的工作机制如下所示：

①　主库一旦产生Redo日志，LGWR就把日志同时提交给日志文件和本地LNS进程，但是LGWR进程只需成功写入日志文件就可以，不必等待LNSn进程的网络传送成功。

②　LNSn进程异步地把日志内容发送到备库，多个LNSn进程可以并发发送。

③　主库的联机Redo日志文件写满后发生Log Switch，触发归档操作，也触发备库对Standby Redo Log的归档；然后触发MRP或者LSP进程恢复归档日志

3.日志接收（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指定的位置。

4.日志应用(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。

三、ADG备库有哪几种类型

1.物理备库

物理DG使用的是Media Recovery技术，在数据块级别进行恢复，这种方式没有数据类型的限制，可以保证两个数据库完全一致。在Oracle 11g之前的物理DG只能在MOUNT状态下进行恢复，虽然可以以只读方式打开备库，但是不能应用日志，而到了Oracle 11g时备库可以在打开的情况下执行恢复操作了，这称为ADG（Active Data Guard）。物理DG实时应用进程为MRP进程。需要注意的是，主库在开启闪回数据库功能后，物理备库并不会开启闪回数据库的功能。

2.逻辑备库

逻辑DG使用的是LogMiner技术，通过把日志内容还原成SQL语句，然后通过SQL引擎执行这些SQL语句。逻辑DG不支持所有的数据类型，这些不支持的数据类型可以在视图DBA_LOGSTDBY_UNSUPPORTED中查看。如果使用了这些数据类型，那么不能保证主备库完全一致。Logical Standby可以在恢复的同时进行读写操作。逻辑DG实时应用进程为LSP进程。需要注意的是，在逻辑DG中，SYS用户下的对象不会同步。要想创建一个逻辑备库需要先创建一个物理备库，然后再将其转换成逻辑备库。

3.快照备库

当Physical Standby转换为Snapshot Standby时，它是一个完全可更新的Standby数据库。Snapshot Standby依然会接收来自主库的归档文件，但是它不会应用。当Snapshot Standby转换为Physical Standby时，所有在Snapshot Standby数据库的操作被丢弃之后，Physical Standby数据库才会应用Primary数据库的Redo数据。

最后需要说明的一点是，物理DG可以转换为逻辑DG，但是逻辑DG不能转换为物理DG。快照DG和物理DG可以相互转换。

四、ADG保护模式（Protection Mode）：

1.最大保护

最大保护模式能够确保绝无数据丢失，该模式要求主库所有的事务在提交前其Redo不仅被写入到本地的Online Redo Logs，还要同时写入到备库的Standby Redo Logs，并确认Redo数据至少在一个备库中可用（如果有多个的话），然后才会在主库上提交。如果出现了导致备库不可用故障（例如网络中断），那么主库会被关闭。因此，在该保护模式下，数据库必须配置SYNC传输模式，且必须和备库连通，否则会导致主库不能启动。

2.最高可用

最高可用模式在不影响主库可用地前提下，提供最高级别的数据保护。其实现方式与最大保护模式类似，也是要求本地事务在提交前必须至少写入一台备库的Standby Redo Logs中，不过与最大保护模式不同的是，如果出现故障导致备库无法访问，那么主库并不会被关闭，而是自动转为最高性能模式，等备库恢复正常之后，主库又会自动转换成最高可用模式。最高可用模式适用于想要确保获得零数据丢失保护，但不想让生产数据库受网络/备用服务器故障影响的企业。

3.最高性能

在最高性能模式下，事务可以随时提交。如果网络条件理想的话，那么这种模式能够提供类似最高可用性的数据保护，而仅对主库的性能有轻微影响。这也是在创建备库时，系统的默认保护模式。最高性能模式区别于最大保护模式的地方是，它并不需要将日志信息实时的传递到备库上，也不需要确保日志在其中的至少一台备库上应用。

五、Switchover和Failover的区别

1.Switchover是指主库转换成备库，然后将原备库转换成新主库；而Failover是指将备库转换成主库。

2. 使用场合不同：Switchover用于有准备的、计划之中的切换，通常是系统升级、数据迁移等常态任务；Failover用于意料之外的突发情况，例如异常断电、自然灾难等等。

3.数据丢失程度不同：Switchover不会丢失数据，Failover通常意味着有部分数据丢失。

4.善后处理的不同：Switchover之后DG环境不会被破坏，仍然有Primary、Standby两种角色的系统存在，但是Failover之后，DG环境就会被破坏，一般情况下需要重建。但是，若主库或备库开启了闪回功能，则都可以通过闪回数据库功能恢复DG环境。