Data Guard原理

文章来源于网络整理

DG通过提供冗余数据来提供数据保护
1.常用于异地容灾和小企业的高可用解决方案
2.虽然可以在Standby机器上执行只读查询，从而分散Primary数据库的性能压力，但是绝不是性能解决方案

DataGuard介绍
在DG环境中，至少会有两个数据库，一个数据库处于Open状态，对外提供服务，这个数据库叫做Primary Database。第二个数据库处于恢复状态，叫做Standby Database。
运行时Primay Database对外提供服务，用户在Primary Database上进行操作，操作被记录在日志文件中。这些日志通过网络传送到Standby Database。这些日志会在Standby Database上重演，从而实现了数据的同步。
Standby Database和Primary Database可以互相转化，继续对外提供服务

Data Guard结构
有三个点需要我们注意
1、在Primary Database上产生日志
2、产生的日志传送给Standby Database数据库
3、Standby Database重演这些日志
分别对应着
日志发送
日志接收
日志应用

日志发送（Redo Send）
Primary Database运行过程中，会源源不断的产生Redo日志，这些日志需要发送到Standby Database。
这个发送动作可以由Primary Database的LGWR或者ARCH进程完成。
选择哪个进程对数据保护能力和系统可用性有很大的不同。

使用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进程把接收到的日志写入到归档日志
6、Standby Database端的MRP进程（Redo Apply）或者LSP进程（SQL Apply）在Standby Database上应用这些日志，进而同步数据

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

使用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归档才触发恢复

使用LGWR进程的ASYNC方式

使用LGWR SYNC方法的最大问题在于，如果日志发送给Standby Database过程失败，LGWR进程就会出错，也就是说Primary Database进程依赖于网络状况。
使用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对Standby Redo Log的归档，然后触发MRP或LSP进程恢复归档日志

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

日志接收（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归档。

日志应用（Redo Apply）
日志应用服务，就是在Standby Database上重演Primary Database的日志，从而实现两个数据库的数据同步。
Standby Database重演日志方式有两种类型：

1 Physical Standby使用的是Media Recovery技术，在数据块级别上进行恢复，这种方式没有数据类型的限制，可以保证两个数据库完全一致。Physical Standby数据库只能在Mount状态下进行恢复，也可以打开，但是只能以只读方式打开，并且打开时不能进行恢复操作。
2 Logical Standby使用的是Logminer技术，通过把日志内容还原成SQL语句，然后SQL引擎执行这些语句，Logical Standby不支持所有数据类型，可以在视图dba_logstdby_unsupported中查看不支持的数据类型。如果使用了这种数据类型，则不能保证数据完全一致。Logical Standby数据库可以在恢复的同时进行读写操作。

Redo Apply发生的时间分为两种

1.实时应用（Real-Time Apply），这种方式必须使用Standby Redo Log。每当日志被写入到Standby Redo Log时，就会触发恢复，使用这种方式的好处在于可以减少数据库切换的时间（Switchover或Failover），因为切换时间主要用在剩余日志内容的恢复上。
2.归档应用，这种方式是在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;

自动裂隙检测解决
当Primary Database的某些日志没有成功发送到Standby Database，这时就发生了归档裂隙（Archive Gap），缺失的这些日志就是裂隙（Gap）。

Dataguard能够自动检测、解决归档裂隙，不需要DBA的介入。
这需要配置FAL_CLIENT、FAL_SERVER两个参数（FAL是Fetch Archive Log的首字母缩写）。
从FAL名称就可以看出，这个过程是Standby Database主动发起的“取”日志的过程，Standby Database是FAL_CLIENT，但是Standby Database从哪里取这些日志呢？这个哪里就是FAL_SERVER。
参数FAL_SERVER是用来定义要从哪些数据库获得缺少的日志。这个参数值是Oracle Net Name。

参数FAL_CLIENT也是一个Oracle Net Name。

FAL_CLIENT通过网络发送请求， FAL_SERVER通过网络向FAL_CLIENT发送缺失的日志。
但是这不一定是一个连接。
因为FAL_CLIENT向FAL_SERVER发送请求的时候，会携带FAL_CLIENT参数值，用来告诉FAL_SERVER应该向哪里发送缺少的日志，这个参数也是一个Oracle Net Name，这个Name是在FAL_SERVER上定义的，用来指向FAL_CLIENT。

除了自动的日志缺失解决，DBA也可以手工解决，这需要作如下操作：

1、确认Standby Database上缺少的日志
2、把这些日志从Primary Database拷贝到Standby Database
3、在Standby Database使用命令手工注册这些日志
sql alter database register logfile 'logfilename';

DG 三种保护模式（级别递增）：Maximum Performance --> Maximum Availability --> Maximum Protection
根据oracle文档的解释，最高可用性数据保护模式需要先满足以下几个条件：


第二篇：
LGWR还分为LGWR ASYNC(异步)和LGWR SYNC(同步)两种。

1.最大性能(maximize performance):这是data guard默认的保护模式。primary上的事务commit前不需要从standby上收到反馈信息（主数据库的提交操作不等待STANDBY），该模式在primary故障时可能丢失数据，但standby对primary的性能影响最小。
可以使用LGWR ASYNC或者ARCH两种传输模式。 ARCH传输模式：Primary DB上的online redo log写满或其他条件引起redo log写归档的时候，redo log生成的archived log file写到本地归档目录的同时，写入了Standby归档目录。只是Primary db上的online redo log切换不必等Standby上的写归档动作结束。

2.最大可用(maximize availability):在正常情况下，最大可用模式和最大保护模式一样；在standby不可用时，最大可用模式会自动降低成最大性能模式，所以standby故障不会导致primary不可用。在问题纠正之后，Standby和主数据库进行再同步，至少有一个standby可用的情况下，即使primary down机，也能保证不丢失数据。(不过当问题修复，再同步之前有必要FAILOVER,那么有些数据可能会丢失)。最大可用性模式Standby必须配置Standby Redo log，Oracle推荐最大可用模式使用LGWR ASYNC（异步）模式传输。 采用最大可用的data guard模式，主库往备库传递在线日志(online redo log)信息，在线日志信息写入备用库的standby redo log,这些standby redo log归档后，备用库应用归档日志。

3.最大保护(maximize protection):最高级别的保护模式。primary上的事务在commit前必须确认redo已经传递到至少一个standby上，如果所有standby不可用，则primary会挂起。该模式能保证零数据丢失。对于最大保护和最高可用性模式，Standby数据库必须配置standby redo log，并且oracle推荐所有数据库都使用LGWR ASYNC模式传输。 采用最大保护必须符合以下条件：
1.主库在LOG_ARCHIVE_DEST_n的参数设置中必须用到LGWR SYNC AFFIRM属性来归档到standby数据库
2.standby数据库必须配置standby redo日志
3.至少有一个standby数据库是可用的。

Physical standby直接从主库接受archived log，然后直接做基于block的物理恢复（更新或调整变化的block），所以physical standby在物理文件一级完全都等同于主库。physical standby恢复只是底层的block apply, OS层面的工作,数据库SCHEMA，包括索引都是一样的。它是直接应用REDO或归档实现同步的 。不会涉及temp ,undo等。
物理STANDBY的模式：只读模式（OPEN READONLY）和恢复模式（MANANGED RECOVERY）。

逻辑STANDBY中，逻辑信息是相同的，但物理组织和数据结构可以不同，它和主库保持同步的方法是将接收的REDO转换成SQL语句，然后在STANDBY上执行SQL语句（SQL Apply）。逻辑STANDBY除灾难恢复外还有其它用途，比如用于用户进行查询和报表。

第三篇：
那么对于oracle dataguard（简称DG）有两种传输模式：async（异步）和sync（同步），在介绍这两种传输模式前，说一下dg的重做传输进程架构。

在主库使用LNS进程从sga中的重做缓冲区中获得相应redo数据，然后通过网络服务传送到备库，那么在备库通过RFS进程接收redo数据存在standby log file中，然后在应用（sql apply或是redo apply）数据。
同步传输模式：
顾名思义同步含有实时确认的意思。见如下图

当用户在主库提交数据的时候，会在sga的redo缓冲区中首先记录redo信息，在提及操作的时候lgwr会将redo数据写入redo数据文件中，那么这个时候lns进程会实时的将redo数据从主库的redo缓冲区传送到备库，在备库使用rfs接收数据，传入standby logfile中，进而应用redo数据（sql apply）。在应用完成后rfs将信息返回主库进程，告知该redo条目已经在备库应用完毕，lgwr收到lns的确认消息，从而提示提交成功。
在最高可用性中，如果主库收不到备库应用的确认消息，那么会通过net_timeout值超时，继续完成本次操作，那么lns进程将不会在获得sga中的重做数据，只有当下次日志switch的时候才主动去尝试获得lns数据，如果期间还是没有和备库完成通信，当超过net_timeout参数的时候会继续停止，主机事务也继续完成，但当存在于最大保护模式下，那么必须等到备库应用redo的确认消息，否则就会停止数据库的运行操作。

异步传输模式：
异步传输模式就是指主库不必要等待备库应用redo的确认消息，就会完成提交工作（见下图），但是增加了数据丢失的风险性。

传输滞后：
主库和 备库因某种原因，导致lns进程无法传送数据到备库,就会传输滞后

当数据库运行最高可用性下，当主库无法与备库进行通信，那么主库依然可以完成事务的提交，lgwr依然可以写入online redo日志，在没法通信期间主库可能会产生很多归档日志，那么oracle为了在备库和主库能够再次通信应用redo日志的情况，会进行自动处理间隔操作。具体就是主库arch进程会不停ping备库，当和备库通信连接后，那么arch进程通过备库的rfs进程获得备库控制文件中最后应用的归档日志信息，将丢失的归档日志通过arch进程传送与备库进行应用。当在主库进行redo
日志切换的时候，lns进程会再次和备库的rfs进程通信继续完成redo条目的传送，arch传送的归档日志在后台进行应用。当备库和主库redo条目同步后arch的任务随即完成。

ADG
随着Oracle ADG的出现，Oracle在读写分离的支持上又进一步了，可以在延迟很少的情况下提供读，而且不会出现复制错误或者数据不一致的问题。
Active Dataguard Reader Farm架构至少存在以下优势：

1. 管理维护简单，DBA只要熟悉Data guard的管理即可，无需再额外学习其他方面的新知识；
2. Active Dataguard Reader Farm节点是灵活可扩展的，可以在线添加或者删除节点，并且可以线性扩展而不对生产系统造成影响；
3. 可以真正做到实时查询，不会应为大事务造成同步阻塞，性能有保障；
4. 没有数据类型的限制；
5. 高可用性，节点的宕机都不会影响到数据库的可用性。 但是同时也需要注意：
6. Active Dataguard是11g数据库单独的一个option，需要单独付费的。
7. 无法在Active Dataguard Reader Farm节点单独创建索引进行查询优化。
8. 在所有Active Dataguard Reader Farm节点上sql的执行计划最好保持一致。 以上仅仅只是对Active Dataguard和Active Dataguard Reader Farm做一个简单的介绍，以下是读写分离的架构图：