Oracle 11G Data Guard 知识总结

Oracle 11G Data Guard 知识点总结,为了更加清楚的了解Oracle 11G 的DG新特性和工作原理、参数配置等信息,作者花了较多时间查看官方文档并对其进行了翻译和整理了网上找到的一些资料,并希望通过整理后更加清晰明确的分享给大家,学习就是这种循序渐进、不断反思、取其根本的一个过程。

本文只是挑选部分官方文档内容进行了翻译,后续会有更多的相关文档发布,如果本文不能满足你知识量需求,可直接查看官方文档进行补充,如果翻译或理解有误的地方也希望能够反馈给我,共勉!

本文主要参考资料来源:

1、官方文档:http://docs.oracle.com/cd/E11882_01/server.112/e10700/toc.htm

2、DAVE的博客:《Oracle Data Guard 理论知识》http://blog.csdn.net/tianlesoftware/article/details/5514082

目录:

一、Oracle Data Guard 11G 新特性

二、Data Guard 初始化参数配置

三、LOG_ARCHIVE_DEST_n 参数属性

四、 Data Guard 架构

五、数据保护模式

六、物理Standby 和逻辑Standby 的区别

七、Log应用服务(Log Apply Services)

 

 

一、Oracle Data Guard 11G 新特性

1.1 Oracle Data Guard 11.1 新特性

1.1.1、REDO流量在网络上传输可以使用压缩属性,示例:
LOG_ARCHIVE_DEST_3=’SERVICE=denver SYNC COMPRESSION=ENABLE’
LOG_ARCHIVE_DEST_STATE_3=ENABLE
1.1.2、REDO 传输时间直方图
V$REDO_DEST_RESP_HISTOGRAM动态性能视图包含一个REDO SYNC到目的地备库的响应时间直方图。 这个视图中的数据可以用来帮助确定一个适当的值LOG_ARCHIVE_DEST_n NET_TIMEOUT属性。单位:秒 示例:
LOG_ARCHIVE_DEST_2=’SERVICE=stby1 SYNC NET_TIMEOUT=10′
LOG_ARCHIVE_DEST_STATE_2=ENABLE
1.1.3、更快的角色转换
1.1.4、强认证重做运输网络会话
1.1.5、重做交通网络会话现在可以使用SSL身份验证。 这提供了强大的身份验证和使远程登录密码文件的使用可选的数据保护配置。
1.1.6、异构数据保护 配置
1.1.7、允许Linux和Windows主和备用数据库在同一数据保护配置。

特定于REDO APPLY 11.1新特性

1.1.8、实时查询的物理备库,这个功能可以在物理备库只读打开的状态下应用REDO,称作 active data guard.
1.1.9、快照备份
1.1.10、物理备库失败写检测

特定于 SQL APPLY 11.1 新特性

1.1.11、对其他对象数据类型的支持和PL / SQL包
1.1.12、XML存储为CLOB
DBMS_RLS(行级安全或虚拟专用数据库)
DBMS_FGA
1.1.13、支持透明数据加密(TDE)
1.1.14、动态设置SQL APPLY 的参数
1.1.15、增强支持Oracle RAC 切换到逻辑备库
1.1.16、增强Oracle data guard sql apply 的DDL并行处理
1.1.17、使用PL/SQL DBMS_SCHEDULER包创建备用数据库调度工作

1.2 Oracle Data Guard 11.2 新特性

1.2.1、Oracle 11.2.0.2 data guard 完全集成 Rac的一个节点。
1.2.2、Data Guard 可以是1个主库和30个备库。
1.2.3、FAL_CLIENT初始化参数不在需要。
1.2.4、默认归档目的地使用Oracle自动存储管理(Oracle ASM)特性和快速恢复区功能已经从LOG_ARCHIVE_DEST_10 更改成 LOG_ARCHIVE_DEST_1。
1.2.5、重做传输压缩是不再局限于压缩的重做数据只有在重做的差距时。当启用压缩为一个目的地,所有重做数据发送到该目的地都是压缩的。
1.2.6、可以使用 ALTER SYSTEM FLUSH REDO 语句在故障转移时刷新重做从主库到备库,从而允许零数据丢失执行故障转移,即使主库不是在零数据丢失数据保护模式下运行。

特定于REDO APPLY 11.2新特性

1.2.7、您可以配置实时查询环境中应用延迟容忍STANDBY_MAX_DATA_DELAY参数。
1.2.8、你可以使用 ALTER SESSION SYNC WITH PRIMARY 语句确保适当配置主备库的同步声明。
1.2.9、增强 V$DATAGUARD_STATS 视图,增加例如 应用延迟和传输延迟列。
1.2.10、你可以查询V$STANDBY_EVENT_HISTOGRAM 视图,查看apply 滞后情况。
1.2.11、一个损坏的数据库块在主库自动替换为为受损的块在备库启用REAL-TIME QUERY模式,损坏的块在物理备库也可以自动替换为一个未受损的主库副本。

特定于 SQL APPLY 11.2 新特性

1.2.12、逻辑备用数据库支持表与基本表压缩,OLTP表压缩,和Hybrid Columnar 压缩。
1.2.13、逻辑备用和LogMiner工具支持与SecureFiles LOB列的表。压缩和加密也支持SecureFiles LOB列的操作。
1.2.14、更改XA全局事务上下文支持Oracle RAC主数据库复制到逻辑备用数据库。
1.2.15、在线重新定义在主数据库使用DBMS_REDEFINITION PL/SQL包透明复制逻辑备用数据库。
1.2.16、逻辑备用数据库支持流捕获。这允许您将处理从主数据库配置在单向信息传播,使传播信息的逻辑备用中心多个数据库。流捕获也可以传播变化是局部的逻辑备用数据库。
1.3Oracle Data Guar 11.2.0.3 新特性
1.3.1、支持XMLType数据存储为二进制XML
1.3.2、支持XMLType数据存储在object-relational格式

二、Data Guard 初始化参数配置

三、LOG_ARCHIVE_DEST_n 参数属性

AFFIRM and NOAFFIRM

AFFIRM:在主库REDO写进程进行之前,备库REDO LOG 必须传输同步写完成。
NOAFFIRM:主库REDO写进程不等待备库REDO LOG 传输同步写完成。
如果 AFFIRM NOFFIRM都没设置,那么SYNC默认是AFFIRM,ASYNC默认是NOAFFIRM
示例:

LOG_ARCHIVE_DEST_3='SERVICE=stby1 SYNC AFFIRM'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

ALTERNATE

指定一个替代目录,在原目的地目录失败的情况下。
如果REOPEN属性指定一个非零值,ALTERNATE属性将被忽略。 如果MAX_FAILURE属性也是一个非零值,如果失败数超过指定阈值(MAX_FAILURE),ALTERNATE属性被启用。 因此,ALTERNATE与一个非零的REOPEN属性值并不冲突。
LOG_ARCHIVE_DEST_11通过LOG_ARCHIVE_DEST_31不能被指定ALTERNATE值。
ALTERNATE属性是可选的。
这个ALTERNATE属性目的地可以做为多个替代目录。
示例:

LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY MAX_FAILURE=1
ALTERNATE=LOG_ARCHIVE_DEST_2'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='LOCATION=/disk2 MANDATORY'
LOG_ARCHIVE_DEST_STATE_2=ALTERNATE

COMPRESSION

是否在传输redo数据之前进行压缩。
示例:

LOG_ARCHIVE_DEST_3='SERVICE=denver SYNC COMPRESSION=ENABLE'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

DB_UNIQUE_NAME

为这个目的地指定一个唯一的数据库名称。
如果LOG_ARCHIVE_CONFIG=DG_CONFIG初始化参数是指定的,这个属性是必需的,如果这是一个远程(指定目的地SERVICE属性)。
示例:

DB_UNIQUE_NAME=boston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)'
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2='SERVICE=Sales_DR
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=chicago'

DELAY

一般设置延迟应用的需求都是基于容错方面的考虑,如Primary数据库端由于误操作,数据被意外修改或删除,只要Standby数据库尚未应用这些修改,你就可以快速从Standby数据库中恢复这部分数据。
DELAY属性影响备库应用REDO数据的延迟时间,单位分钟 默认值是30分钟,但不影响REDO数据的传输和归档到备库 。
如果你启用了实时应用,任何延迟设置将被忽略。
备库取消应用延迟

物理备库

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

逻辑备库

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;

示例:

LOG_ARCHIVE_DEST_1='LOCATION=/arch/dest MANDATORY'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='SERVICE=stbyB SYNC AFFIRM'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_3='SERVICE=stbyC DELAY=120'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

LOCATION and SERVICE

每个目的地必须指定的LOCATION或者是SERVICE属性来识别一个本地磁盘目录或一个远程数据库的目的地,。
LOG_ARCHIVE_DEST_1通过LOG_ARCHIVE_DEST_10可以用于LOCATION属性或SERVICE属性。
LOG_ARCHIVE_DEST_11通过LOG_ARCHIVE_DEST_31只能用于SERVICE属性。
验证当前的设置LOCATION和SERVICE属性查询V$ARCHIVE_DEST

示例1 Specifying the LOCATION Attribute

LOG_ARCHIVE_DEST_2='LOCATION=/disk1/oracle/oradata/payroll/arch/'
LOG_ARCHIVE_DEST_STATE_2=ENABLE

示例2 Specifying the SERVICE Attribute

LOG_ARCHIVE_DEST_3='SERVICE=stby1'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

MANDATORY

指定了在线日志文件必须成功归档到目的地才可以重用。
LOG_ARCHIVE_DEST_11通过LOG_ARCHIVE_DEST_31不支持的参数MANDATORY属性。
示例:

LOG_ARCHIVE_DEST_1='LOCATION=/arch/dest MANDATORY'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_3='SERVICE=denver MANDATORY'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

MAX_CONNECTION

MAX_CONNECTIONS 是可选的,默认值是1 ,此属性标识redo数据传输使用ARCn 进程数量。
如果 MAX_CONNECTIONS 设置的总数超过了 LOG_ARCHIVE_MAX_PROCESSES 值设置,那么Data Guard会使用尽可能多的 ARCn进程完成传输任务。
示例:

LOG_ARCHIVE_DEST_1='LOCATION=/arch/dest'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_3='SERVICE=denver MAX_CONNECTIONS=3'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

MAX_FAILURE

控制传输重做数据到目的地失败的次数。
当你指定MAX_FAILURE属性,您也必须设置REOPEN属性。
您可以查看失败数FAILURE_COUNT列在V$ARCHIVE_DEST视图。
故障计数复位为零(0)当目标被修改的ALTER SYSTEM SET声明。
一旦失败数大于或等于设定的值MAX_FAILURE属性,REOPEN属性值是隐式地设置为零,那么将使用ALTERNATE 设置的替代目录进行归档。

LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=5 MAX_FAILURE=3'
LOG_ARCHIVE_DEST_STATE_1=ENABLE

NET_TIMEOUT

指定LGWR后台进程等待Redo传输目的地确认收到Redo数据的秒数,如果确认没有在NET_TIMEOUT秒内收到,一个错误被记录,同时到该目的地的Redo传输会话被中断。
默认值为30秒,值的范围1到1200。
指定该参数必须指定SYNC属性。
通过在主数据库查询V$ARCHIVE_DEST.NET_TIMEOUT字段查看该属性的值。
虽然允许NET_TIMEOUT的最小值为1秒,Oracle推荐最小值在8到10秒,防止瞬时网络错误的情况下断开与Standby数据库的连接。
以下的例子显示如何在主数据库使用NET_TIMETOUT属性设置10秒的网络超时值:
示例:

LOG_ARCHIVE_DEST_2='SERVICE=stby1 SYNC NET_TIMEOUT=10'
LOG_ARCHIVE_DEST_STATE_2=ENABLE

NOREGISTER

表明归档重做日志文件的位置不应该被记录在相应的目的地。
NOREGISTER属性是可选的,如果备用数据库的目的地是数据保护配置的一部分。
NOREGISTER属性是必需的,如果目的地不是数据保护配置的一部分。
这个属性只属于远程目的地。 每个归档重做日志文件的位置总是记录在主数据库控制文件。
示例:

LOG_ARCHIVE_DEST_5='NOREGISTER'

REOPEN

该属性指定Redo传输服务尝试重新打开失败目的地等待的最小秒数,失败重试的时间间隔。
默认值为300秒,值应该大于0。
通过V$ARCHIVE_DEST视图的REOPEN_SECS和MAX_FAILURE字段可以获得相关信息。
在日志切换时Redo传输服务尝试重新打开失败的目的地。
Redo传输服务检查如果最后错误的时间加上REOPEN间隔小于当前时间,Redo传输服务尝试重新打开目的地。

REOPEN应用于所有的错误,不仅仅是连接失败。这些错误包括但不仅限于网络失败,磁盘失败,和权限异常。
如果为可选目的地指定了REOPEN,如果有任何的错误,Oracle数据库很可能覆盖在线Redo日志文件,如果对MANDATORY目的地指定了REOPEN,当不可能成功传输Redo数据,Redo传输服务可能拖延主数据库。当这种情况发生,考虑一下选项:
a).延迟该目的地,指定该目的地为可选目的地,或者改变SERVICE属性值。
b).指定ALTERNATE目的地。
c).禁用该目的地。

以下的例子显示了REOPEN属性:

LOG_ARCHIVE_DEST_3='SERVICE=stby1 MANDATORY REOPEN=60'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

SYNC and ASYNC

指定是否同步(SYNC)或异步(ASYNC)传输重做数据。
LOG_ARCHIVE_DEST_11通过LOG_ARCHIVE_DEST_31不支持的参数SYNC属性。
启用SYNC属性,生成的重做数据事务一定是到达目的地之后,事务才可以提交。
启用ASYNC属性,生成的重做数据事务不用等待到达目的地,事务就可以提交。

LOG_ARCHIVE_DEST_3='SERVICE=stby1 SYNC'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

TEMPLATE

在目的地对Redo日志文件名称定义特定目录和格式模板,模板参数用于在Redo目的地生成与LOG_ARCHIVE_FORMAT初始化参数定义的格式不同的文件名。
通过查询V$ARCHIVE_DEST的REMOTE_TEMPLATE和REGISTER字段可以查询相关信息。
如果没有指定TEMPLATE,归档Redo日志使用LOG_ARCHIVE_FORMAT初始化参数的值进行命名。
TEMPLATE属性只对远程目的地有效(通过SERVICE属性指定的目的地)。
指定的文件名模板必须包含%s,%t和%r指令:
%t 实例线程号。
%T 实例线程号,用0填充。
%s 日志文件序列号。
%S 日志文件序列号,用0填充。
%r resetlogs ID。
%R resetlogs ID,用0填充。

filename_template值被传送到目的地,是在创建文件名之前进行传输和验证。

VALID_FOR

重做数据是否被写入到目的地,取决于以下两种设置:redo_log_type和 database_role
VALID_FOR=(redo_log_type,database_role):
VALID_FOR参数默认值是:VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
REDO_LOG_TYPE
ONLINE_LOGFILE——目标是有效的只有当归档联机重做日志文件。
STANDBY_LOGFILE——目标是有效的只有当归档备用重做日志文件。
ALL_LOGFILES——这个目的地是有效归档联机重做日志文件或备用重做日志文件。
DATABASE_ROLE
PRIMARY_ROLE——主库。
STANDBY_ROLE——备库。
ALL_ROLES——主库或备库。

 

四、 Data Guard 架构

DG架构可以按照功能分成3个部分:

1) 日志发送(Redo Send)

2) 日志接收(Redo Receive)

3) 日志应用(Redo Apply)

4.1. 日志发送(Redo Send)

Primary Database 运行过程中,会源源不断地产生Redo 日志,这些日志需要发送到Standy Database。 这个发送动作可以由Primary Database 的LGWR 或者ARCH进程完成, 不同的归档目的地可以使用不同的方法,但是对于一个目的地,只能选用一种方法。 选择哪个进程对数据保护能力和系统可用性有很大区别。

ARCH和LGWR

作用:日志传输服务使用ARCH还是LGWR,
ARCH 进程通过Net 把归档日志发送给Standby Database的RFS(Remote File Server) 进程。

使用ARCH 进程

4.1.1)Primary Database 不断产生Redo Log,这些日志被LGWR 进程写到联机日志。
4.1.2)当一组联机日志被写满后,会发生日志切换(Log Switch),并且会触发本地归档,本地归档位置是采用 LOG_ARCHIVE_DEST_1=’LOCATION=/path’ 这种格式定义的。

alter system set log_archive_dest_1='LOCATION=/u01/arch' scope=both;

4.1.3)完成本地归档后,联机日志就可以被覆盖重用。
4.1.4)ARCH 进程通过Net 把归档日志发送给Standby Database的RFS(Remote File Server) 进程。
4.1.5)Standby Database 端的RFS 进程把接收的日志写入到归档日志。
4.1.6)Standby Database 端的MRP(Managed Recovery Process)进程(Redo Apply)或者LSP 进程(SQL Apply)在Standby Database上应用这些日志,进而同步数据。用ARCH模式传输不写Standby Redologs,直接保存成归档文件存放于Standby端。

说明:
逻辑Standby接收后将其转换成SQL语句,在Standby数据库上执行SQL语句实现同步,这种方式叫SQL Apply。
物理Standby接收完Primary数据库生成的REDO数据后,以介质恢复的方式实现同步,这种方式也叫Redo Apply。

注意:创建逻辑Standby数据库要先创建一个物理Standby数据库,然后再将其转换成逻辑Standby数据库。

使用ARCH进程传递最大问题在于: Primary Database 只有在发生归档时才会发送日志到Standby Database。 如果Primary Database 异常宕机,联机日志中的Redo 内容就会丢失,因此使用ARCH 进程无法避免数据丢失的问题,要想避免数据丢失,就必须使用LGWR,而使用LGWR 又分SYNC(同步)和ASYNC(异步)两种方式。

在缺省方式下,Primary Database使用的是ARCH进程,参数设置如下:
alter system set log_archive_dest_2 = ‘SERVICE=ST’ scope=both;

使用LGWR 进程的SYNC 方式

4.1.7)Primary Database 产生的Redo 日志要同时写道日志文件和网络。也就是说LGWR进程把日志写到本地日志文件的同时还要发送给本地的LNSn进程(Network Server Process),再由LNSn(LGWR Network Server process)进程把日志通过网络发送给远程的目的地,每个远程目的地对应一个LNS进程,多个LNS进程能够并行工作。
4.1.8)LGWR 必须等待写入本地日志文件操作和通过LNSn进程的网络传送都成功,Primary Database 上的事务才能提交,这也是SYNC的含义所在。
4.1.9)Standby Database的RFS进程把接收到的日志写入到Standby Redo Log日志中。
4.1.10)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默认使用ARCH进程,如果使用LGWR进程必须明确指定。使用LGWR SYNC方式时,可以同时使用NET_TIMEOUT参数,这个参数单位是秒,代表如果多长时间内网络发送没有响应,LGWR 进程会抛出错误。 示例如下:
alter system set log_archive_dest_2 = ‘SERVICE=ST LGWR SYNC NET_TIMEOUT=30’ scope=both;

 使用LGWR进程的ASYNC 方式

使用LGWR SYNC方法的可能问题在于,如果日志发送给Standby Database过程失败,LGWR进程就会报错。也就是说Primary Database的LGWR 进程依赖于网络状况,有时这种要求可能过于苛刻,这时就可以使用LGWR ASYNC方式。 它的工作机制如下:
4.1.11)Primary Database 一段产生Redo 日志后,LGWR 把日志同时提交给日志文件和本地LNS 进程,但是LGWR进程只需成功写入日志文件就可以,不必等待LNSn进程的网络传送成功。
4.1.12)LNSn进程异步地把日志内容发送到Standby Database。多个LNSn进程可以并发发送。
4.1.13)Primary Database的Online Redo Log 写满后发生Log Switch,触发归档操作,也触发Standby Database对Standby Database对Standby Redo Log 的归档;然后触发MRP或者LSP 进程恢复归档日志。

因为LGWR进程不会等待LNSn进程的响应结果,所以配置LGWR ASYNC方式时不需要NET_TIMEOUT参数。示例如下:
alter system set log_archive_dest_2 = ‘SERVICE=ST LGWR ASYNC ‘ scope=both;

4.2. 日志接收(Redo Receive)

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,那么这个动作本省也可以看作是个归档操作。

在日志接收中,需要注意的是归档日志会被放在什么位置:

4.2.1) 如果配置了STANDBY_ARCHIVE_DEST 参数,则使用该参数指定的目录。

4.2.2) 如果某个LOG_ARCHIVE_DEST_n 参数明确定义了VALID_FOR=(STANDBY_LOGFILE,*)选项,则使用这个参数指定的目录。

4.2.3) 如果数据库的COMPATIBLE参数大于等于10.0,则选取任意一个LOG_ARCHIVE_DEST_n的值。

4.2.4) 如果STANDBY_ARCHIVE_DEST 和 LOG_ARCHIVE_DEST_n 参数都没有配置,使用缺省的STANDBY_ARCHIVE_DEST参数值,这个缺省值是$ORACLE_HOME/dbs/arc.

4.3. 日志应用(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引擎执行这些语句,Logminer Standby不支持所有数据类型,可以在视图DBA_LOGSTDBY_UNSUPPORTED 中查看不支持的数据类型,如果使用了这种数据类型,则不能保证数据库完全一致。 Logical Standby数据库可以在恢复的同时进行读写操作。

Standby数据库的相关进程读取接收到的REDO数据(可能来自于Standby端的归档文件,也可能来自于Standby Redologs),再将其写入Standby数据库。保存之后数据又是怎么生成的呢?两种方式:物理Standby通过REDO应用,逻辑Standby通过SQL应用

根据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;

五、数据保护模式

Data Guard 允许定义3钟数据保护模式,分别是最大保护(Maximum Protection),最大可用(Maximum Availability)和 最大性能(Maximum Performance)。

 Data Guard 三种保护模式对应的参数设置

最大保护 最大可用 最大性能
进程 LGWR LGWR LGWR或ARCH
网络传输模式 SYNC SYNC LGWR时设置SYNC
磁盘写操作 AFFIRM AFFIRM NOAFFIRM
备用日志 Yes Phycal 备库需要 LGWR和物理需要
备用库类型 Phycal mode Phycal and logical Phycal and logical

1. 最大保护(Maximum Protection)

这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的,它要求所有的事务在提交前其REDO不仅被写入到本地的Online Redologs,还要同时写入到Standby数据库的Standby Redologs,并确认REDO数据至少在一个Standby数据库中可用(如果有多个的话),然后才会在Primary数据库上提交。如果出现了什么故障导致Standby数据库不可用的话(比如网络中断),Primary数据库会被Shutdown,以防止数据丢失。

使用这种方式要求Standby Database 必须配置Standby Redo Log,而Primary Database必须使用LGWR,SYNC,AFFIRM 方式归档到Standby Database.

2. 最高可用性(Maximum availability)

这种模式在不影响Primary数据库可用前提下,提供最高级别的数据保护策略。其实现方式与最大保护模式类似,也是要求本地事务在提交前必须至少写入一台Standby数据库的Standby Redologs中,不过与最大保护模式不同的是,如果出现故障导致Standby数据库无法访问,Primary数据库并不会被Shutdown,而是自动转为最高性能模式,等Standby数据库恢复正常之后,Primary数据库又会自动转换成最高可用性模式。

这种方式虽然会尽量避免数据丢失,但不能绝对保证数据完全一致。这种方式要求Standby Database 必须配置Standby Redo Log,而Primary Database必须使用LGWR,SYNC,AFFIRM 方式归档到Standby Database.

3. 最高性能(Maximum performance)

缺省模式。 这种模式在不影响Primary数据库性能前提下,提供最高级别的数据保护策略。事务可以随时提交,当前Primary数据库的REDO数据至少需要写入一个Standby数据库,不过这种写入可以是不同步的。如果网络条件理想的话,这种模式能够提供类似最高可用性的数据保护,而仅对Primary数据库的性能有轻微影响。这也是创建Standby数据库时,系统的默认保护模式。

这种方式可以使用LGWR ASYNC 或者 ARCH 进程实现,Standby Database也不要求使用Standby Redo Log。

 修改数据保护模式步骤

1)关闭数据库,重启到Mount 状态,如果是RAC,需要关闭所有实例,然后只启动一个实例到mount状态。

2)修改模式:

语法:ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};

如:SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;

3) 打开数据库: alter database open;

4) 确认修改数据保护模式:

SQL>select protection_mode,protection_level from v$database;

自动裂缝检测和解决

当Primary Database的某些日志没有成功发送到Standby Database, 这时候发生了归档裂缝(Archive Gap)。

缺失的这些日志就是裂缝(Gap)。 Data Guard能够自动检测,解决归档裂缝,不需要DBA的介入。这需要配置FAL_CLIENT(11G中已废弃此参数), FAL_SERVER 这两个参数(FAL: Fetch Archive Log)。

如:FAL_SERVER=’PR1,ST1,ST2′;

当然,除了自动地日志缺失解决,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 ‘路径’;

六、物理Standby 和逻辑Standby 的区别

Standby数据库类型分为两类:物理Standby和逻辑Standby。

1.物理Standby

我们知道物理Standby与Primary数据库完全一模一样,DG通过REDO应用来维护物理Standby数据库。

通常在物理Standby没有执行REDO应用操作的时候,可以将物理Standby数据库以READ ONLY模式打开,如果数据库中指定了Flashback Area的话,甚至还可以被临时性的置为READ WRITE模式,操作完之后再通过Flashback Database特性恢复回READ WRITE前的状态,以便继续接收Primary端发送的REDO并应用。

REDO应用。物理Standby通过REDO应用来保持与Primary数据库的一致性,所谓的REDO应用,实质是通过Oracle的恢复机制,应用归档文件(或Standby Redologs文件)中的REDO数据。恢复操作属于块对块的应用。如果正在执行REDO应用的操作,Oracle数据库就不能被Open。

READ ONLY模式打开。以READ ONLY模式打开后,可以在Standby数据库执行查询或备份等操作(变相减轻Primary数据库压力)。此时Standby数据库仍然能够继续接收Primary数据库发送的REDO数据,不过并不会应用,直到Standby数据库重新恢复REDO应用。

也就是说在READ ONLY模式下不能执行REDO应用,REDO应用时数据库肯定处于未打开状态。如果需要的话,你可以在两种状态间转换,如先应用REDO,然后将数据库置为READ ONLY状态,需要与Primary同步时再次执行REDO应用命令,切换回REDO应用状态。呵呵,人生就是循环,数据库也是一样。

提 示: Oracle 11g版本中增强物理Standby的应用功能,在11g版本中,物理Standby可以在OPEN READ ONLY模式下继续应用REDO数据,这就极大地提升了物理Standby数据库的应用场合,可以实现 Real-time apple Real-time query。

READ WRITE模式打开。如果以READ WRITE模式打开,那么Standby数据库将暂停从Primary数据库接收REDO数据,并且暂时失去灾难保护的功能。当然,以READ WRITE模式打开也并非一无是处,如你可能需要临时调试一些数据,但又不方便在正式库中操作,那就可以临时将Standby数据库置为READ WRITE模式,操作完之后将数据库闪回到操作前的状态(闪回之后,Data Guard会自动同步,不需要重建物理Standby,不过如果从另一个方向看,没有启动闪回,那就回不到READ WRITE前的状态了)。

物理Standby特点如下:

(1)灾难恢复及高可用性。物理Standby提供了一个健全、高效的灾难恢复,以及高可用性的解决方案。更加易于管理switchover/failover角色转换及在更短的计划内或计划外停机时间。

(2)数据保护。使用物理Standby数据库,DG能够确保即使面对无法预料的灾害也能够不丢失数据。前面也提到物理Standby是基于块对块的复制,因此与对象、语句无关,Primary数据库上有什么,物理Standby数据库端也会有什么。

(3)分担Primary数据库压力。通过将一些备份任务、仅查询的需求转移到物理Standby数据库,可以有效节省Primary数据库的CPU及I/O资源。

(4)提升性能。物理Standby所使用的REDO应用技术使用最底层的恢复机制,这种机制能够绕过SQL级代码层,因此效率最高。

2.逻辑Standby

逻辑Standby也要通过Primary数据库(或其备份,或其复制库,如物理Standby)创建,因此在创建之初与物理Standby数据库类似。不过由于逻辑Standby通过SQL应用的方式应用REDO数据,因此逻辑Standby的物理文件结构,甚至数据的逻辑结构都可以与Primary不一致。

与物理Standby不同,逻辑Standby正常情况下是以READ WRITE模式打开,用户可以在任何时候访问逻辑Standby数据库,就是说逻辑Standby是在OPEN状态执行SQL应用。同样有利也有弊,由于SQL应用自身特点,逻辑Standby对于某些数据类型及一些DDL/DML语句会有操作上的限制。可以在视图DBA_LOGSTDBY_UNSUPPORTED 中查看不支持的数据类型,如果使用了这种数据类型,则不能保证数据库完全一致。

逻辑Standby 的读写打开可以使它做报表系统,这样减轻系统的压力

除了上述物理Standby中提到的类似灾难恢复、高可用性及数据保护等特点之外,逻辑Standby还有下列一些特点:

(1)有效地利用备机的硬件资源。除灾难恢复外,逻辑Standby数据库还可用于其他业务需求。如通过在Standby数据库创建额外的索引、物化视图等提高查询性能并满足特定业务需要;又如创建新的SCHEMA(该SCHEMA在Primary数据库端并不存在),然后在这些SCHEMA中执行那些不适于在Primary数据库端执行的DDL或者DML操作等。

(2)分担Primary数据库压力。逻辑Standby数据库可以在保持与Primary同步时仍然置于打开状态,这使得逻辑Standby数据库能够同时用于数据保护和报表操作,从而将主数据库从报表和查询任务中解脱出来,节约宝贵的 CPU和I/O资源。

(3)平滑升级。可以通过逻辑Standby来实现如跨版本升级,为数据库打补丁等操作。应该说应用的空间很大,而带来的风险却很小(前提是如果你拥有足够的技术实力。另外虽然物理Standby也能够实现一些升级操作,但如果跨平台的话恐怕就力不从心了,所以此项没有作为物理Standby的特点列出),我个人认为这是一种值得可行的在线的滚动的平滑的升级方式,如果你的应用支持创建逻辑Standby的话。

七、Log应用服务(Log Apply Services)

Data Guard通过应用REDO维持Primary数据库与各Standby数据库之间的一致性,在后台默默无闻地支撑着的就是传说中的Log应用服务。Log应用服务又分以下两种方式:

REDO应用:物理Standby数据库专用,通过介质恢复的方式保持与Primary数据库的同步。

SQL应用:逻辑Standby数据库专用,核心是通过LogMiner分析出SQL语句在Standby端执行。

7.1  Log应用服务配置选项

默认情况下,Log应用服务会等待单个归档文件全部接收之后再启动应用,如果Standby数据库配置了Standby Redologs,就可以打开实时应用(Real-Time Apply),这样Data Guard就不需要再等待接收完归档文件,只要RFS进程将REDO数据写入Standby Redologs,即可通过MRP/LSP实时写向Standby数据库。

7.1.1.REDO数据实时应用

启动实时应用的优势在于,REDO数据不需要等待归档完成,接收到即可被应用,这样执行角色切换时,操作能够执行得更快,因为日志是被即时应用的。

要启动实时应用也简单,前提是Standby数据库端配置了Standby Redologs。

物理Standby要启用实时应用,要在启动REDO应用的语句后附加USING CURRENT LOGFIE子句,例如:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE  DISCONNECT ;

逻辑Standby要启用实时应用,只需要在启动REDO应用的语句后附加IMMEDIATE子句即可,例如:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

7.1.2.REDO数据延迟应用

有实时就有延迟,某些情况下你可能不希望Standby数据库与Primary太过同步,那就可以在Primary数据库端发送REDO数据的相应LOG_ARCHIVE_DEST_n参数中指定DELAY属性(单位为分钟,如果指定了DELAY属性,但没有指定值,则默认是30分钟)。

注意:该属性并不是说延迟发送REDO数据到Standby,而是指明归档到Standby后,开始应用的时间。

例如:设置LOG_ARCHIVE_DEST_3的DELAY属性为15分钟:

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_3=’SERVICE=DavePrimary ARCH VALID_ FOR=

(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=Dave DELAY=15′;

不过,如果DBA在启动REDO应用时指定了实时应用,那么即使在LOG_ ARCHIVE_DEST_n参数中指定了DELAY属性,Standby数据库也会忽略DELAY属性。

另外,Standby端还可以在启动REDO应用时,通过附加NODELAY子句的方式,取消延迟应用。

物理Standby可以通过下列语句取消延迟应用:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

逻辑Standby可以通过下列语句取消延迟应用:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;

一般设置延迟应用的需求都是基于容错方面的考虑,如Primary数据库端由于误操作,数据被意外修改或删除,只要Standby数据库尚未应用这些修改,你就可以快速从Standby数据库中恢复这部分数据。不过自Oracle从9i版本开始提供FLASHBACK特性之后,对于误操作使用FLASHBACK特性进行恢复,显然更加方便快捷,因此DELAY方式延迟应用已经非常少见了。

7.2  应用REDO数据到Standby数据库

7.2.1.物理Standby应用REDO数据

物理Standby启动REDO应用,数据库要处于MOUNT状态或是OPEN READ ONLY状态,启动REDO应用的命令相信大家已经非常熟悉了。

前台应用:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;

语句执行完成后,不会将控制权返回到命令行窗口,除非你手动中止应用。在这种情况下如果还需要对数据库进行操作,只能新开一个命令行连接,在Oracle 8i刚推出Standby特性时(那时不叫Data Guard),只提供了这种方式。

后台应用:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

这是现在比较通用的方式,语句执行完后,控制权自动返回到当前的命令行模式,REDO应用以后台进程运行。

启动实时应用,附加USING CURRENT LOGFILE子句即可:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

如果要停止REDO应用,执行下列语句即可:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

7.2.2.逻辑Standby应用REDO数据

SQL应用的原理是将接收到的REDO数据转换成SQL语句在逻辑Standby数据库端执行,因此逻辑Standby需要启动至OPEN状态。

(1)启动SQL应用。逻辑Standby数据库启动SQL应用没有前、后台运行之说,语句执行完之后,控制权就会自动返回当前命令行窗口。

要启动SQL应用,直接执行下列语句即可:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;

如果要启动实时应用,附加IMMEDIATE子句即可,例如:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

(2)停止SQL应用,如:

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

由于是执行SQL语句的方式应用REDO数据,因此上述语句的执行需要等待当前执行的SQL触发的事务结束,才能真正停止REDO应用的状态。

如果不考虑事务执行情况,马上停止REDO应用,可以通过下列的语句来完成:

SQL> ALTER DATABASE ABORT LOGICAL STANDBY APPLY;

发表评论