一、DataGuard架构介绍

1、基本介绍

在DG环境中，至少会有两个数据库，一个数据库处于Open状态，对外提供服务，这个数据库叫做primary Database。第二个数据库处于恢复状态，叫做Standby Database。

运行时Primay Database对外提供服务，用户在Primary Database上进行操作，操作被记录在日志文件中。这些日志通过网络传送到Standby Database。这些日志会在Standby Database上重演，从而实现了数据的同步。

Oracle 的DG对这个过程进一步的优化设计，使得日志的传送、恢复工作更加自动化、智能化。

如果是可预见因素需要关闭Primay Database，例如软硬件的升级，可以把Standby Database切换为Primary Database继续对外提供服务，并且数据不会丢失。
如果是因为异常原因导致Primary Database不可用，也可以把Standby Database强制切换为Primary Database继续对外提供服务，这时数据损失程度和配置的数据保护级别有关系。

上面一大段话可以总结为以下三点：
1：primary Database上产生日志
2：primary Database将日志传给Standby Database
3：Standby Database根据接受到的日志进行重演
下面附上一张DG架构图，咱们就能更清晰的了解内部机制。

图中的data guard其实分为两种结构：

• 通过LGWR发送日志和通过ARCH发送日志。
  • 通过ARCH则不必要非常好的网络资源，但数据实时性也大打折扣。
• 通过LGWR也就意味着具有更高的实时性，数据丢失率较低。但也非常依赖网络资源，同样也受数据保护模式的影响。

2、DG相关的后台进程

ARCH (archiver) ：心跳检测，探测对方
LNS (log-write network-server) ：log传送
RFS (remote file server) ：远程接数据
FAL (Fetch Archive Log ) ：解决Redo的间隔Gap
MRP (Managed Recovery Process) :日志被应用，恢复的过程
LSP (Logical Standby Process)：逻辑数据库的后台进程，SQL转换

FAL介绍：

FAL（Fetch Archive Log）是 Oracle Data Guard 中的一个关键特性，它的作用是在备用数据库（Standby Database）上自动检测并解决归档日志的间隔（Gap）问题。这个过程确保了备用数据库能够持续与主数据库（Primary Database）保持同步，即使在归档日志传输过程中出现丢失或延迟的情况。

FAL 工作原理：

1. 归档裂缝（Archive Gap）：当主数据库上的事务日志（Redo Logs）由于某些原因未能及时传输到备用数据库时，就会在备用数据库上形成归档裂缝。这可能是由于网络问题、磁盘空间不足或其他原因导致的。
2. 裂缝检测：备用数据库会定期检测归档日志的完整性，一旦发现裂缝，即日志序列中断，就会触发 FAL 进程。
3. 日志请求：作为 FAL_CLIENT 的备用数据库会向配置为 FAL_SERVER 的主数据库或其他备用数据库发送请求，以获取缺失的归档日志。
4. 日志传输：FAL_SERVER 接收到请求后，会从其归档日志存储中检索出缺失的日志，并通过网络发送给 FAL_CLIENT。
5. 日志应用：备用数据库上的 FAL_CLIENT 接收到缺失的归档日志后，会将其传输给负责日志应用的进程（如 RFS - Redo File Services），这些进程将日志写入备用数据库的归档日志或在线重做日志中。
6. 数据同步：随后，备用数据库上的 MRP（Managed Recovery Process）或 LSP（Log Writer Process）进程会应用这些日志，以确保备用数据库的数据与主数据库保持一致。

FAL 的重要性：

数据一致性：通过自动解决归档裂缝，FAL 确保了备用数据库的数据与主数据库保持同步，这对于数据保护和灾难恢复至关重要。
高可用性：FAL 减少了人为干预的需求，提高了系统的自动化程度，从而增强了整个系统的可用性。
减少停机时间：在主数据库发生故障时，由于备用数据库始终保持最新状态，可以快速切换到备用数据库，最小化业务中断时间。

3、功能划分

相关服务按功能区分：

• 日志发送 （redo send）：
  Primary Database 运行过程中，会源源不断地产生Redo 日志，这些日志需要发送到Standy Database。 这个发送动作可以由Primary Database 的LGWR 或者ARCH进程完成， 不同的归档目的地可以使用不同的方法，但是对于一个目的地，只能选用一种方法。 选择哪个进程对数据保护能力和系统可用性有很大区别。
• 日志接收 （redo recieve）：
  Standby Database 的RFS（Remote File Server）进程接收到日志后，就把日志写到Standby Redo Log或者Archived Log文件中，具体写入哪个文件，取决于Primary 的日志传送方式和Standby database的位置。如果写到Standby Redo Log文件中，则当Primary Database发生日志切换时，也会触发Standby Database上的Standby Redo Log 的日志切换，并把这个Standby Redo Log 归档。 如果是写到Archived Log，那么这个动作本身也可以看作是个归档操作。
• 日志应用 （redo apply）：
  日志应用服务，就是在Standby Database上重演Primary Database日志，从而实现两个数据库的数据同步。 根据Standby Database重演日志方式的不同，可分为物理Standby（Physical Standby） 和 逻辑Standby（Logical Standby）。

4、DATA GUARD的三种数据保护模式

所谓数据保护模式是指在Standby Database和Primary Database之间数据同步的程度。Data Guard允许定义三种数据保护模式，分别是最大保护（maxmium protection）、最大可用（maxmium availability）、最大性能（maxmium performance）。

最大保护模式（maxmium Production）
这个级别保证Standby Database和Primary Database的数据是完全同步的，即使Primary Database突然宕机，在Standby Database上不会有任何数据丢失。
这种模式下，Primary Database上的每个事务的Redo日志必须在本地和Standby Database上都写入日志文件后才能提交，如果不能写入到Standby Database，Primary Database就会自动关闭以防止数据丢失。
这种方式要求Standby Database必须配置Standby Redo log，而Primary Database必须使用LGWR、SYNC、AFFIRM方式归档到Standby Database。（AFFIRM,磁盘io控制，保证主备库日志同时写完）

最大性能（Maxmium Performance）
这个模式是缺省模式，他更加侧重对Primary Database的可用性不造成任何影响。
Primary Database上的事务的Redo日志只要写到本地日志文件就可以提交，不必等待到Standby Database的传递完成。
Primary Database的Redo流可以异步的发送到Standby Database。
这种模式通过LGWR ASYNC或者ARCH实现，Standby Database也不要求使用Standby Redo Log。

最大可用性（Maxmium Availability）
这种模式会尽量避免数据丢失，Primary Database每个事务的Redo日志要写到本地和Standby Database中才能提交。
这个和最大保护模式不同的是，如果写入到Standby Database失败，Primary Database不会自动关闭。这时Primary Database会自动转换为Maxmium Performance模式，等待问题解决并且Standby Database再次和Primary Database同步之后，Primary Database会自动的转换为Maxmium Availability。
这种模式会尽量的避免数据丢失，但不能绝对保证数据完全一致。
这种模式要求Standby Database必须配置Standby Redo log，而Primary Database必须配置为LGWR、SYNC、AFFIRM方式归档。

如果要修改数据保护模式，则可以按照以下操作进行。

shutdown immediate;
startup mount;
# 修改模式（这里以最大可用性为例）
alter database set standby database to maxmium availability;
# 打开数据库
alter database open;
# 确认模式已经修改
select protection_mode,protection_level from v$database;

二、DG原理

tip：ARCH的结构和LGWR的结构均为日志发送 （redo send）内容

1、ARCH的结构

1、Primary Database不断的产生Redo Log，这些日志被LGWR进程写到联机日志
2、联机日志写满以后，发生日志切换，触发ARC0完成本地归档
归档位置采用LOG_ARCHIVE_DEST_1=‘LOCATION=/path’
3、完成本地归档以后，联机日志可以被覆盖重用
4、ARCH1进程通过Net把归档日志发送给Standby Database的RFS进程
5、Standby Database端的RFS(Remote File Server)进程把接受到的日志写入到归档日志
6、Standby Database端的MRP(media recover process)进程（Redo Apply）或者LSP进程（SQL Apply）在Standby Database上应用这些日志，进而同步数据

这种方式最大的问题是：
Primary Database只有在发生归档时才会发送日志到Standby Database，如果Primary Database异常宕机，联机日志中的Redo内容会丢失，因此这种方式没法避免数据丢失的问题。
要想避免数据丢失，就必须使用LGWR，而使用LGWR又有SYNC和ASYNC两种方式。

2、LGWR的结构

LGWR又分为同步（SYNC）和异步（ASYNC）两种方式，下面分别介绍一下这两种方式

LGWR SYNC 同步方式

1、Primary Database产生的Redo日志要同时写到日志文件和网络。也就是说LGWR进程把日志写到本地日志文件的同时还要发给本地的LNSn进程（Network Server Process），再由LNSn进程把日志通过网络发送到远程目的地，每个远程目的地对应一个LNS进程，多个LNS进程能够并行工作。
2、LGWR必须等待写入本地日志文件的操作和通过LNSn进程的网络传送都成功，Primary Database上的事务才能够提交，这也是SYNC的含义所在。
3、Standby Database的RFS进程把接收到的日志写入到Standby Redo Log日志中
4、Primary Database的日志切换也会触发Standby Database上的日志切换，即Standby Database对Standby Redo Log的归档，然后触发Standby Database的MRP或者LSP进程恢复归档日志

因为Primary Database的Redo是实时传送的，于是Standby Database端可以使用两种恢复方式：
实时恢复（Real-Time Apply），只要RFS把日志写入Standby Redo Log就会立即进行恢复；
归档时恢复，在完成对Standby Redo Log归档才触发恢复。
Primary Database默认使用ARCHN进程，如果使用LGWR进程必须明确指定。使用LGWR SYNC方式时，可以同时使用NET_TIMEOUT参数，这个参数单位是秒，代表如果多长时间内网络发送没有响应，LGWR进程就会抛出错误。

LOG_ARCHIVE_DEST_2=‘SERVICE=ST LGWR SYNC NET_TIMEOUT=30’

使用LGWR SYNC方法的可能问题在于，如果日志发送给Standby Database过程失败，LGWR进程就会出错，也就是说Primary Database进程依赖于网络状况。一般也可以使用异步的LGWR模式，也就是LGWR ASYNC。

LGWR ASYNC 异步方式

1、Primary Database一端产生Redo日志后，LGWR把日志同时提交给日志文件和本地LNS进程，但是LGWR进程只需要成功写入日志文件即可，不必等待LNSn进程的网络传送成功。
2、LNSn进程异步地把日志内容发送到Standby Database，多个LNSn进程可以并发发送
3、Primary Database的Online Redo Log写满后发生Log Switch，触发归档操作，也触发Standby Database对Stand Redo Log的归档，然后触发MRP或LSP进程恢复归档日志

因为LGWR进程不会等待LNSn进程的响应结果，所以配置LGWR ASYNC方式时不需要NET_TIMEOUT参数

LOG_ARCHIVE_DEST_2=‘SERVICE=boston LGWR ASYNC’

3、日志接收（Redo Receive）

Standby Database的RFS进程接收到日志后，就把日志写到Standby Redo Log或者Archived Log文件中，具体写入哪种文件，取决于Primary的日志传送方式和Standby Database的配置。
如果是写到Standby Redo Log文件中，则当Primary Database发生日志切换时，也会触发Standby Database上的Standby Redo Log的日志切换，并把这个Standby Redo Log归档。
在日志接收中，需要注意的是归档日志被放在什么位置，Standby Database选择归档目录的算法如下。

1、如果配置了STANDBY_ARCHIVE_DEST参数，则使用这个参数指定的目录
2、如果某个LOG_ARCHIVE_DEST_n参数明确定义了VALID_FOR=(STANDBY_LOGFILE,*)选项，则使用这个参数指定的目录
3、如果数据库的COMPATIBLE参数大于等于10.0，则选取任意一个LOG_ARCHIVE_DEST_n的值
4、如果STANDBY_ARCHIVE_DEST_n和LOG_ARCHIVE_DEST_n参数都没有配置，使用缺省的STANDBY_ARCHIVE_DEST参数，这个缺省值是$ORACLE_HOME/dbs/arch

4、日志应用（redo apply)

日志应用服务，就是在Standby Database上重演Primary Database的日志，从而实现两个数据库的数据同步。

根据应用方式划分

根据Standby Database重演日志方式的不同，可分为物理Standby（Physical Standby）和逻辑Standby（Logical Standby）两种类型。
Physical Standby使用的是Media Recovery技术（MRP)），在数据块级别上进行恢复，这种方式没有数据类型的限制，可以保证两个数据库完全一致。Physical Standby数据库只能在Mount状态下进行恢复，也可以打开，但是只能以只读方式打开，并且打开时不能进行恢复操作。
Logical Standby使用的是Logminer技术(LSP)，通过把日志内容还原成SQL语句，然后SQL引擎执行这些语句，Logical Standby不支持所有数据类型，可以在视图dba_logstdby_unsupported中查看不支持的数据类型。如果使用了这种数据类型，则不能保证数据完全一致。Logical Standby数据库可以在恢复的同时进行读写操作。
Physical Standby的SCN号和主库保持一致，而Logical Standby仅保持数据层面的一致。一般在应用过程中BUG会较多，建议使用Physical Standby。

根据发生时间划分

根据Redo Apply发生的时间又可以分成两种

一种是实时应用（Real-Time Apply），这种方式必须使用Standby Redo Log。每当日志被写入到Standby Redo Log时，就会触发恢复，使用这种方式的好处在于可以减少数据库切换的时间（Switchover或Failover），因为切换时间主要用在剩余日志内容的恢复上。
另一种是归档应用，这种方式是在Primary Database发生日志切换，触发了Standby Database的归档操作，归档完成后会触发恢复，这也是缺省的恢复方式。
如果是Physical Standby，可以使用下面的命令启用Real-Time：

 alter database recover managed standby database using current logfile;

如果是Logical Standby，可以使用下面的命令启用Real-Time：

 alter database start logical standby apply immediate;

查看是否使用Real-Time Apply：

select recovery_mode from v$archive_dest_status;

5、自动裂缝检测和解决

当Primary Database的某些日志没有成功发送到Standby Database，这时候发生了归档裂缝（Archive Gap）。
缺失的这些日志就是裂缝（Gap）。Data Guard能够自动检测，解决归档裂缝，不需要DBA的介入。这需要配置FAL_CLIENT，FAL_SERVER 这两个参数（FAL: Fetch Archive Log）。

从FAL 这个名字可以看出，这个过程是Standby Database主动发起的“取”日志的过程，Standby Database 就是FAL_CLIENT. 它是从FAL_SERVER中取这些Gap， 10g中，这个FAL_SERVER可以是Primary Database， 也可以是其他的Standby Database。
如：FAL_SERVER=‘PR1,ST1,ST2’;
FAL_CLIENT和FAL_SERVER两个参数都是Oracle Net Name。FAL_CLIENT 通过网络向FAL_SERVER发送请求，FAL_SERVER通过网络向FAL_CLIENT发送缺失的日志。 但是这两个连接不一定是一个连接。 因此FAL_CLIENT向FAL_SERVER发送请求时，会携带FAL_CLIENT参数值，用来告诉FAL_SERVER应该向哪里发送缺少的日志。 这个参数值也是一个Oracle Net Name，这个Name是在FAL_SERVER上定义的，用来指向FAL_CLIENT.

当然，除了自动地日志缺失解决，DBA 也可以手工解决。 具体操作步骤如下：

1） 查看是否有日志GAP： 
SQL> SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG; SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; 
2） 如果有，则拷贝过来
3） 手工的注册这些日志： 
SQL> ALTER DATABASE REGISTER LOGFILE '路径';