DATAGUARD 原理

DATAGUARD 原理

Dataguard原理图

•Dataguard本质上是物理备份的异机恢复，其性能受限于：

Ø日志的网络传输速度：主要跟网络带宽有关

Ø日志的应用（apply）速度：主要跟存储I/O和CPU有关

详细的结构图

DG的几个重要进程

1）RFS进程

RFS（Remote File Server）进程主要是用来接收从主库传送过来的日志信息。对于物理备份库而言，RFS进程可以直接将日志写入Standby Redo logs，也可以直接将日志信息写到归档日志中。一般可以在主库的告警日志中看到相关信息。

2）LNSn进程

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

一般情况下，主库切换（alter system switch logfile），日志可以启动LNSn进程。

需要注意的是，若在Oracle 10g中采用LGWR传输日志的时候，则进程表现为LNSn，但在Oracle 11g中，若采用LGWR ASYNC（异步方式）来传输日志的时候，则进程表现为nsa，若采用LGWR SYNC（同步方式）来传输日志的话，则进程表现为nss。且通过视图GV$MANAGED_STANDBY查询的结果不尽相同。

3）MRP进程

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

4）LSP进程

Logical Standby Process，只有逻辑备库才会有该进程。LSP（SQL Apply）进程应用Redo日志到逻辑备库。

5）FAL进程

Fetch Archive Log，从FAL名称就可以看出，这个过程是Standby Database主动发起的“取”日志的过程，Standby Database是FAL_CLIENT，但是Standby Database从哪里取这些日志呢？这个哪里就是FAL_SERVER。

日志传输模式

•ARCH ASYNC：对生产库的性能影响相对较小

•LGWR ASYNC/SYNC：对生产库的性能有着不同程度的影响

•Oracle 10.2使用ARCH进程传输日志最佳实践：

Ø设置LOG_ARCHIVE_MAX_PROCESSES为较大值

Ø在数据库参数LOG_ARCHIVE_DEST_n中设置MAX_CONNECTIONS（最大为5）

Ø从性能角度来讲，最好的方式是写脚本自己传输在线日志或者归档日志。

Ø使用Oracle进程传输日志，容易牵一发而动全身。

网络传输优化

•所需网络带宽的大小由归档量决定，归档量越大，所需网络带宽越大。其优化思路如下：

Ø不使用Oracle进程（ARCH/LGWR进程）传输日志

Ø在LOG_ARCHIVE_DEST_n中设置COMPRESSION，开启压缩传输特性（Oracle 11g以上使用）

见mos文章 Redo Transport Compression in a Data Guard Environment (文档 ID 729551.1)

Ø在LOG_ARCHIVE_DEST_n中设置ASYNC （默认属性），开启异步传输日志

•Debug日志传输过程，设置参数log_archive_trace 。详见MOS文档 ID 1604963.1（Troubleshooting Data Guard Log Transport Services）：

•如果日志不会自动传输（在参数配置正确的前提下）则做如下操作：

（1）在生产库进行以下操作：

SQL> alter system set log_archive_dest_state_2='defer';

SQL> alter system switch logfile;

SQL> show parameter log_archive_dest_2

SQL> alter system set log_archive_dest_2 = '........';

SQL> alter system switch logfile;

（2）在备库做如下操作：

SQL> alter database recover managed standby database cancel;

SQL> shutdown immediate

（3）在生产库进行以下操作：

ps -ef | grep -i arc

kill -9...

Or

SQL> alter system set log_archive_max_processes=4;

（4）在备库进行如下操作：

SQL> startup mount;
SQL> alter database recover managed standby database [using current logfile] disconnect;

（5）在生产库进行如下操作：

SQL> alter system set log_archive_dest_state_2='enable' ;

日志应用速度优化

•日志应用分为应用归档日志和在线日志。其应用速度取决于：

Ø生产库归档量的大小和数量

Ø归档日志涉及数据块的物理离散程度

Ø备份库的存储的I/O能力

•可以查询如下视图观察日志应用的进度：

ØV$RECOVERY_PROGRESS

•日志应用分为三个阶段（每个归档日志）：

Ø恢复进程读取standby/arch日志

ü使用并行恢复（默认情况下由cpu_count决定）

ü设置参数parallel_execution_message_size（最大64k）

Ø恢复进程读取data block至buffer cache

ü加大buffer cache，缩小shared/keep/recycle pool

ü设置参数_media_recovery_read_batch=[512 or 1024]

Øcheckpoint过程，即DBWR进程将dirty block写至datafile中

ü增加DBWR数量或者slave数量（DBWR_IO_SLAVES）

ü文件系统使用CIO属性、调整存储参数

ü设置参数DB_BLOCK_CHECKING = FALSE

•Oracle每次应用一个归档日志都会重复上述过程，所以可以考虑加大日志文件的大小来加快日志应用速度

•备库的日志应用速度必须快于生产库的日志产生速度

•查看视图v$session_wait.event，观察数据库的性能瓶颈

•设置event 10871，观察警告日志：

•在生产库（Oracle 10g以上）设置COMMIT_WRITE = BATCH,NOWAIT

优化成果：

•在同等硬件的条件下，不同数据库版本下日志应用速度有所提升：

Active Dataguard

•Oracle 11g开始推出active dataguard（ADG）功能，即可以在备库进行查询工作，但不能进行如下操作：

ØAny DMLs (excluding simple SELECT statements) or DDLs

ØQuery accessing local sequences

ØDMLs to local temporary tables

•使用@?/rdbms/admin/sb*脚本监控ADG的性能

（详见MOS文档 ID 454848.1）

•启动ADG功能对日志应用速度的影响

配置DG注意点

•生产库没有设置FORCE LOGGING

•生产库设置不恰当的数据库参数

•备库设置不恰当的数据库参数

•在业务高峰期首次全同步数据库

•

管理DG注意点

•备份库的归档日志积压

•生产库的归档日志断档

•在生产库新路径下添加数据文件

•没有定期检查备库数据文件是否损坏

•主库运行环境发生变化

DG切换注意点

•检查主备主机的操作系统时间

•检查备库的数据库参数(如undo_tablespace)是否能满足系统运行

•检查备库的在线日志数量和大小是否能满足系统正常运行

•检查备库归档日志的应用情况，如果应用延迟比较大，则建议应用完成之后再切换

•分别在主备主机上检查能否用SQLPLUS连接对方数据库

•为加快切换速度，切换之前建议先重启生产库

传输模式

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进程把接受到的日志写入到归档日志；

（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进程，不需要特别的指定，例如下面这个配置的例子

LOG_ARCHIVE_DEST_2=‘SERVICE=ST’

2、使用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’

3、使用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对Stand Redo Log的归档，然后触发MRP或LSP进程恢复归档日志

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

LOG_ARCHIVE_DEST_2=‘SERVICE=boston LGWR ASYNC’

日志接收（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重演日志方式的不同，可分为物理Standby（Physical Standby）和逻辑Standby（Logical Standby）两种类型。

Physical Standby使用的是Media Recovery技术，在数据块级别上进行恢复，这种方式没有数据类型的限制，可以保证两个数据库完全一致。Physical Standby数据库只能在Mount状态下进行恢复，也可以打开，但是只能以只读方式打开，并且打开时不能进行恢复操作。

Logical Standby使用的是Logminer技术，通过把日志内容还原成SQL语句，然后SQL引擎执行这些语句，Logical Standby不支持所有数据类型，可以在视图dba_logstdby_unsupported中查看不支持的数据类型。如果使用了这种数据类型，则不能保证数据完全一致。Logical Standby数据库可以在恢复的同时进行读写操作。

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

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

另一种是归档应用，这种方式是在Primary Database发生日志切换，触发了Standby Database的归档操作，归档完成后会触发恢复（触发LSP或MRP），这也是缺省的恢复方式。

如果是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：

SQL>select recovery_mode from v$archive_dest_status;

数据保护模式

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

这三种模式的区别在于，当Primary Database发生故障时，Standby Database的数据会和Primary Database有多少差别？

最大保护模式（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。

最大可用性（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方式归档。

尽量保证，先保证最大保护，不行就保证最大性能。

最大性能（Maxmium Performance）

这个模式是缺省模式，他更加侧重对Primary Database的可用性不造成任何影响。

Primary Database上的事务的Redo日志只要写到本地日志文件就可以提交，不必等待到Standby Database的传递完成。

Primary Database的Redo流可以异步的发送到Standby Database。

这种模式通过LGWR ASYNC或者ARCH实现，Standby Database也不要求使用Standby Redo Log。

主归档以后，传给从，从慢慢应用

LGWR ASYNC或者ARCH只能使用最大性能模式

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

SQL>shutdown immediate;

SQL>startup mount;

修改模式

SQL>alter database set standby database to maxmium availability;

打开数据库

SQL>alter database open;

确认模式已经修改

SQL>select protection_mode,protection_level from v$database;

自动裂隙检测解决

当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可以是Primary Database，也可以是别的Standby Database。

参数FAL_SERVER是用来定义要从那些数据库获得缺少的日志。这个参数值是Oracle Net Name。

Oracle 10.2开始，Standby Database不仅可以从Primary Database获得，还可以从其他Standby Database获得缺少的日志，因此这个参数可以定义一个Net Name列表：

FLA_SERVER=‘pr1,st1,st2’;

参数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使用命令手工注册这些日志

 alter database register logfile ‘logfilename’;