这篇文章主要讲解了“分析Oracle中11g DataGuard”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“分析Oracle中11g DataGuard”吧！

专注于为中小企业提供成都网站制作、网站建设服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业华亭免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了1000+企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。

1、什么是DataGuard

DataGuard是Oracle推出的一项专门针对oracle数据库的高可用技术，在8i之前被称之为Standby Dtabase，从9i开始正式更名为DataGuard。通常情况下至少会有两个数据镜像节点构成的主备关系。通过redo日志的同步技术来保证数据的实时同步，可以实现数据库的主备快速切换实现数据的容灾。

2、为什么要用DataGuard

DataGuard 中文名又叫数据卫士，顾名思义，是为了保证数据安全ORACLE推出的一项技术，主要用于对数据安全性重视程度比较高的一些场合，比如：银行，电信等行业他们都在应用了非常多套的DataGuard数据卫士来保障数据的安全。

当然同时也用于数据库日常维护而不中断业务，比如例行停机，测试改变，升级维护等等。

3、DataGuard所带来的价值

可以实现数据的零丢失，维护的零停机，保证业务的持续在线运行，通过读写分离有效的分担数据库压力，降低由于各种原因宕机的风险。

4、DataGuard的体系架构

5、DataGuard 是否安全

DataGuard的同步是通过redo传输并且在standby端应用实现数据的同步，那么它的同步链路是建立在Oracle Net之上，通过Oracle Net来进修数据的传输，其之间走的是SSL协议，SSL使用RSA公钥密码和对称密钥加密，提供身份验证、加密和数据完整性。SSL是自动用于重做运输验证在两个Oracle数据库。如果SSL身份验证需求没有得到满足,每个数据库必须使用远程登录密码文件。在一个DataGuard配置,所有物理和快照备用数据库必须使用密码文件的一个副本从主数据库，刷新副本须当SYSOPER或SYSDBA特权授予或撤销后,任何用户的密码与这些特权是改变

当一个密码文件是用于redo传输验证，密码文件中的的用户帐户用于redo传输各数据库之间的比较启动一个redo传输会话和目标数据库。密码必须是同样在两个数据库中。默认情况下,系统用户的密码是用于验证重做运输会话密码文件时使用。

6、DataGuard的三种保护模式

最大保护模式:

1）这种模式提供了最高级别的数据保护能力；
2）要求至少一个物理备库收到重做日志后，主库的事务才能够提交；
3）主库找不到合适的备库写入时，主库会自动关闭，防止未受保护的数据出现；
4）优点：该模式可以保证备库没有数据丢失；
5）缺点：主库的自动关闭会影响到主库的可用性，同时需要备库恢复后才能提交，对网络等客观条件要求非常的高，主库的性能会因此受到非常大的冲击。

最大可用性模式:
1）该模式提供了仅次于“最大保护模式”的数据保护能力；
2）要求至少一个物理备库收到重做日志后，主库的事务才能够提交；
3）主库找不到合适的备库写入时，主库不会关闭，而是临时降低到“最大性能模式”模式，直到问题得到处理；
4）优点：该模式可以在没有问题出现的情况下，保证备库没有数据丢失，是一种折中的方法；
5）缺点：在正常运行的过程中缺点是主库的性能受到诸多因素的影响。

最大性能模式:
1）该模式是默认模式，可以保证主数据库的最高可用性；
2）保证主库运行过程中不受备库的影响，主库事务正常提交，不因备库的任何问题影响到主库的运行；
4）优点：避免了备库对主数据库的性能和可用性影响；
5）缺点：如果与主库提交的事务相关的恢复数据没有发送到备库，这些事务数据将被丢失，不能保证数据无损失；

简单来看由三部分组成：主库，备库，中间层（各种服务+日志、归档文件），中间层我们放到后面说，先看一下主库和备库：

Primary Database

DG环境包含一个主库。 主库可以是单实例，也可以是RAC 集群。备库至少有一个standby 数据库组成。 主备库之间通过oracle Net进行通信，主备库不受地理位置的限制。

Standby Databases

Standby 数据库与主库一致保持事务一致。一个主库可以对应多个备库。备库的种类在11g中有三种：

1.物理备库

2.逻辑备库

3.快照备库

物理standby（Physical standby database）

        物理standby是对主库进行physically identical copy。 这是一种Media recovery，是基于block-for-block的恢复。在数据块级别进行恢复，这种方式没有数据类型的限制，可以保证两个数据库完全一致。

        在Oracle 11g之前，standby 数据库只能在Mount 状态下进行恢复，也可以是打开，但只能已只读方式打开，并且打开时不能执行恢复操作。到了11g，standby 可以启动到read-only状态并同步，这样standby 数据库就可以用来进行一些数据查询操作，提高数据库的利用率。

逻辑standby（Logical standby database）

        逻辑standby 的同步使用的是SQL Apply。这种方式 像logminer挖掘日志，但是通过Logminer 技术，通过把日志内容还原成SQL 语句，然后SQL引擎执行这些语句，Logminer Standby不支持所有数据类型，可以在视图 DBA_LOGSTDBY_UNSUPPORTED 中查看不支持的数据类型，如果使用了这种数据类型，则不能保证数据库完全一致。

快照 standby（Snapshot Standby Database）

Snapshot standby 是Oracle 11g中的新特性，也是对standby database的一次升级。Snapshot standby 和 物理standby，逻辑standby 一样，也会从主库接收归档文件，但是不同的是，snapshot standby 不会应用这些接收的归档。

Snapshot Standby Database和逻辑备库都建立在物理standby基础上，如果我们想在standby 库上做一些测试，因为主库我们不能动，我们可以在备库测。 那么我们就可以把这个standby 切换成snapshot standby。 

切换语句如下：

SQL> alter database convert to snapshot standby;

把snapshot standby 数据库打开，进行我们的测试。

SQL> alter database open;

测试完毕后，我们把数据库重启到mount 状态。 执行命令将数据库从snapshot状态切换到之前的状态，如物理standby或者逻辑standby。

SQL> alter database convert to physical standby;

从snapshot standby的功能看来oracle是逐渐弱化逻辑备库的，在11g中使用物理备库和快照备库将是主流

一、为何要设置数据库强制归档？

alter database force logging;

Oracle日志记录的三种模式：logging,force logging,nologging

logging：在创建数据库对象时（视图，索引，序列等）将日志信息写入联机重做日志文件，logging相当于

对象的一个属性，用来标记创建对象时是否记录了REDO日志，包括在DML时是否记录了REDO日志。

force logging：强制记录日志，对数据所有的操作都产生日志信息，并将信息写入联机重做日志文件。

nologging：相反，较少的记录日志。

在做DATA GUARD时要保证数据的一致性，所以打开数据库强制归档模式。

二、为什么要在mount状态下开启数据库归档？

Oracle数据库启动的三个阶段，nomount,mount,open，分别加载的文件为参数文件，控制文件，数据文件，

将数据库启动到mount阶段时，数据库根据参数文件中指定的控制文件路径打开控制文件，

获取数据文件和日志文件的信息，此时可对数据库进行维护，开启归档模式，Oracle规定要在mount实例下开启归档。

三、为什么要配置静态监听参数？

在DATA GUARD架构中，在数据库mount状态下，动态监听无法将服务注册到数据库，静态监听则可以完成这个任务。

典型监听文件listen.ora分为两个部分，LISTENER注册的是服务，SID_LIST_LISTENER注册的是实例。

四、参数文件中各项参数的意义是什么？

1、*.db_name='orcl' 

数据库名，需要保持同一个DATA GUARD中所有的数据库db_name一致

2、*.db_unique_name='orcl_p'

每一个数据库都要有唯一的名称

3、*.log_archive_config='dg_config=(orcl_p,orcl_s)'

该参数用于控制发送归档日志到远程位置，以及接收远程归档日志，并指定DATA GUARD配置的唯一数据库名，

默认值为SEND，RECEIVE，NODG_CONFIG， 当该

            参数为SEND时，会激活发送归档日志到远程位置，

            参数为NOSEND时，会禁止发送归档日志到远程位置；

            参数为RESEIVE时，会激活接收远程归档日志；

            参数为NORECEIVE时会禁止接收远程归档日志；

            参数为DG_CONFIG时，可以指定最多9个惟一数据库名；

            参数为NODG_CONFIG时，会禁止指定惟一数据库名，

该参数是动态参数，可以使用alter system set log_archive_config='SEND';来修改。

4、*.log_archive_dest_1='location=/u01/arch valid_for=(all_logfiles,all_roles) db_unique_name=orcl_p'

log_archive_dest_1是DG重做日志传输的主要参数，一般在主库中起作用，在处理级联备库的时候会在备库发挥作用，

该参数也可指定在线重做日志（ORL）和备库重做日志(SRL)产生归档日志的传输目的地。

（1）service：指定备库的网络连接名

（2）sync：指定使用同步的方法传送重做数据，即客户端事务的提交会发生在LGWR进程收到备库LNS发来的

信息确认之后，对于最大可用及最大保护模式，需要至少一个备库net_timeout指定LGWR进程

等待LNS进程响应时间，如果期间没有收到响应，则认为备库发生故障（failed),默认为30s，

等待期间需要做以下事情：

                    a：停止旧的LNS进程

                    b：启动新的LNS进程

                    c：与备库建立连接

                    d：检测并停止旧的RFS进程

                    e：启动新的RFS进程

                    f：选择并打开新的SRL

                    g：初始化SR头，即备库的重做日志数据库

                    h：响应LNS进程告知已经完成准备工作

完成上面的操作后，LNS进程会通知LGWR备库连接成功，如果该过程超过了30s，则会继续放弃备库。

（3）reopen：属性控制主库尝试重新连接已经发生故障的备库的等待时间，默认为30s

（4）db_unique_name属性要在log_archive_dest_n中使用的话同时要在log_archive_config中设置，否则DATA GUARD会拒绝连接这个目标库，必须在主备库中将db_unique_name添加到log_archive_config参数中，当主库发起连接时，它将会发送自己的db_unique_name到备库，同时要求备库返回惟一的db_unique_name。在备库中将会检查log_archive_config参数，以确保主库的db_unique_name存在，如果不存在，那么连接请求就会被拒绝，如果存在，备库会把自己db_unique_name返回主库的LNS进程，如果返回值与主库该值不匹配，连接就会被终止。

（5）valid_for：属性定义了何时使用目标参数log_archive_dest_n以及作用于何种类型的日志文件

                            日志文件的合法值有以下三种：

                                        online_logfile仅在归档ORL中有效

                                        standby_logfile仅在归档SRL中有效

                                        all_logfiles无论哪种重做日志文件类型都有效

                            角色的合法值有以下三种：

                                        primary_role仅在主库中有效

                                        standby_role仅在备库中有效

                                        all_roles主备库都有效   

（6）affirm：属性是使用sync方式目标的默认值

5、*.log_archive_dest_state_1=enable

用来指定归档目录是否可用。

6、*.standby_file_management='auto'

在主库创建数据文件时备库会自动创建数据文件

7、*.log_file_name_convert='/u01/app/oracle/oradata/orcl','/u01/app/oracle/oradata/orcl'

      *.db_file_name_convert='/u01/app/oracle/oradata/orcl','/u01/app/oracle/oradata/orcl'

log_file_name_convert与db_file_name_convert来保证主备库数据文件路径一致

8、*.fal_server='orcl_s'

FAL指获取归档日志（fetch archive log)，因为网络中断或者资源紧张等问题导致主备日志不同步，

MRP（Managed recovery process)/LSP(Logical Standby Process)不能直接与主库连接来获取丢失的归档日志，因此需要用到FAL来解决，fal_server后对应备库的db_unique_name

五、Oracle DATA GUARD进程结构是怎样的？

1、存在于主库的进程：

（1）LGWR：收集事务日志，更新联机日志，在同步模式下，LGWR将redo信息直接传送到备库的RFS进程，主库在继续处理前等待备库的确认。在非同步的情况下，也是直接将日志信息传到备库的RFS进程，但是不等待备库的确认信息。

（2）ARCH：在归档的同时，传递日志到备库RFS进程，可以用于解决GAP日志不连续问题。

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

2、存在于备库的进程：

（1）FAL：只有物理备库才有的进程，FAL指获取归档日志（Fetch Archive Log),因为网络中断或者资源紧张等问题导致主备日志不同步，MRP（Managed recovery process)/LSP(Logical Standby Process)不能直接与主库连 接来获取丢失的归档日志，因此需要用到FAL来解决。

（2）RFS(Remote File Server):主要用于接收从主库传过来的日志信息。arch进程归档重做日志，由MPR应用到备库。

（3）MRP(Managed Recovery Process)：只针对于物理备库，应用归档日志到备库

（4）LSP(Logic Standby Process)：只有逻辑备库拥有，控制归档日志应用到逻辑备库。

3、Oracle DG通过同步日志文件来保证主库与备库的一致性

如果一个数据库与单个或者多个备库之间连接出现问题，那么主库产生的日志文件便无法传输到备库上去，使用归档日志进程(FAL)提供一个客户服务机制，用于在主库与备库中断连接后将归档日志发送到备库上，以实现自动填充间隔和重新同步。在备库上，Oracle DATA GUARD使用远程文件服务器(RFS）进程从主数据库接收重做记录，使用管理恢复进程（MRP）将重做信息应用到物理备库中，使用逻辑备用进程（LSP）将经过SQL转换的重做信息应用到逻辑备库中。

4、Oracle DATA GUARD三种保护模式

保护模式

出现灾难时数据丢失风险

重做传输机制

最大保护

零数据丢失；双重故障保护

LGWR SYNC

最高可用性

零数据丢失；单故障保护

LGWR SYNC

最高性能

最小数据丢失

LGWR SYNC 或ARCH

默认保护模式为最高性能模式，可以使用alter database set standby database to maximize (protection|availability|performance}; 来切换保护模式

最大保护模式保证在事务提交时同时写到主库与备库的日志文件中来保证一致性，优点是安全，缺点是在备库出现故障时，主库也无法正常使用。

最高可用性相同与最大保护模式基本一样，不同点在于当备库出现故障时主库会立即切换为最高性能模式。

最高性能只需要确保提交的事务写到主库的日志文件中即可。

感谢各位的阅读，以上就是“分析Oracle中11g DataGuard”的内容了，经过本文的学习后，相信大家对分析Oracle中11g DataGuard这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！

文章名称：分析Oracle中11gDataGuard
文章出自：http://myzitong.com/article/pedjge.html