Data Guard 知识简介(一) 11g新特性、介绍及物理standby的配置

这篇文章主要从官方的Oracle 11g Data Guard Concepts and Administration和其它一些资料中摘一些相关的知识，来帮助理解Data Guard的体系结构。

RAC 11.2 体系结构（三）http://blog.csdn.net/wildwave/article/details/6882567也讨论了关于Data Guard的一些概念，在这里，重复的部分将略过

Oracle Data Guard 11.2的新特性

Redo apply和SQL Apply通用的新特性

• 一个Data Guard配置可以由一个主库和多达30个备库组成
• 不再需要FAL_CLIENT初始化参数
• Oracle ASM和快速恢复区域特性使用的默认归档路径从LOG_ARCHIVE_DEST_10变成了LOG_ARCHIVE_DEST_1
• Redo传输的压缩不再限制只在解决gap的时候使用，当一个目的地中指定了compression，所有发送到该目的地的redo数据都会被压缩
• 新增了一个ALTER SYSTEM FLUSH REDO 表达式，在故障切换时，该SQL语句可以从一个mounted状态的主数据库中将未传送的redo日志刷新到一个standby数据库，由此可以在主库没运行在零数据丢失的保护模式时，也能做到无数据丢失。

Redo Apply的新特性

• 你可以在实时查询环境中使用STANDBY_MAX_DATA_DELAY参数来设置容许的最大延迟时间
• 你可以使用ALTER SESSION SYNC WITH PRIMARY语句来确保物理standby数据库与主库同步
• V$DATAGUARD_STATS视图在很多字段上都更加准确了，包括apply lag和transport lag
• 可以通过查询新增的视图V$STANDBY_EVENT_HISTOGRAM来查看物理standby上应用延迟数值的直方图
• 在实时查询模式下，主库中的坏块会自动被物理standby数据库上该块的拷贝所替换。反过来也一样

SQL Apply的新特性

• 逻辑standby和LogMiner工具支持使用了基本表压缩、OLTP表压缩和混合列压缩的表(混合列压缩是Oracle Exadata的特性之一)
• 逻辑standby和LogMiner工具支持包含SecureFile LOB字段的表。在SecureFile LOB字段上的压缩和加密同样被支持。(不支持删除重复数据(De-duplication)和基于碎片(fragment-based)操作)
• Oracle RAC主数据库上XA(Extended Architecture)全局事务上下文中发生的改变，会在逻辑standby数据库上被复制。
• 在主数据库上使用DBMS_REDEFINITION包执行的在线重定义会被复制到逻辑standby数据库中
• 逻辑standby支持主数据库中的版本使用，包括使用基于版本的重定义来升级应用，从而最小化停机时间(关于基于版本的重定义edition-based redefinition可以在Oracle Database Advanced Application Developer's Guide中查看详情)
• 逻辑standby数据库支持流捕获。这个特性允许你将单向的信息传播从主库中卸载，并使用逻辑standby作为hub来将信息传播到多个数据库中。流捕获也可以把本地的更改传播到逻辑standby数据库中

Oracle Data Guard 11.1中的新特性

Redo apply和SQL Apply通用的新特性

• Redo流量压缩。当发生redo gap时，在讲redo通过网络传输前会对其进行压缩来提高传输性能
• Redo传输响应时间直方图。V$REDO_DEST_RESP_HISTOGRAM视图中含有每个SYNC redo传输的目的地的响应时间的直方图。视图中的数据可以帮助你确定LOG_ARCHIVE_DEST_n中的NET_TIMEOUT属性的合适的值
• 更快的角色转换
• 对redo传输网络会话进行有效验证(通过SSL)
• 简化Data Guard管理接口。通过弃用一些多余的SQL表达式和初始化参数
• 增强了DB_UNIQUE_NAME。在V$DATABASE中增加了一列PRIMARY_DB_UNIQUE_NAME来查询主库的DB_UNIQUE_NAME。11g中DB_UNIQUE_NAME相同的数据库之间不能进行通讯
• 使用物理standby数据库来滚动升级。通过在ALTER DATABASE RECOVER TO LOGICAL STANDBY中添加KEEP IDENTITY选项来临时将物理standby数据库转换成逻辑standby，来实现滚动升级
• 多样化的Data Guard 配置。 这个特性允许在同一个Data Guard配置中混合使用Linux和Windows的主库和备库

Redo Apply的新特性

• 物理standby的实时查询功能
• Snapshot standby
• 使用物理standby来检测写丢失(lost-wirte detection)
• 加强了与RMAN的结合

SQL Apply的新特性

• 支持更多的对象数据类型和PL/SQL包。(以CLOB方式存储XML；DBMS_RLS；DBNS_GFA)
• 支持透明的数据加密(TDE)
• 使用DBMS_LOGSTDBY.APPLY_SET包来实现SQL Apply参数的动态设置
• 当使用逻辑standby数据库，switchover对RAC的支持得到加强。不需要关闭任何实例
• 增强了SQL Apply的DDL处理能力。并行执行parallel DDL
• 使用DBMS_SCHEDULER包在standby数据库上创建调度任务

Data Guard 概念与管理

Data Guard 介绍

Data Guard 配置由一个产品数据库和一个或多个standby数据库组成。配置中的这些数据库可以分布在不同的地理位置，通过Oracle Net来连接。你可以通过SQL命令行或Data Guard broker接口来管理主备数据库，包括命令行接口DGMGRL，和Oracle EM上集成的图形用户接口。

DG配置中包含的那个产品数据库，也称作主数据库，作为primary角色，供大部分的应用来访问。主库可以是单实例数据库或RAC。

Standby数据库可以使用主库的备份拷贝来创建，并配置到DG中。DG通过传送和应用主库中的redo来自动维护standby数据库。和主库一样，standby数据库也可以是单实例或RAC数据库。Standby类型有物理standby、逻辑standby和snapshot standby。具体介绍参照RAC 11.2 体系结构（三）。

Data Guard 主要包含三种服务：Redo传输服务、应用服务和角色切换。

Redo传输主要的任务有：在主备系统之间传输redo数据、对由于网络问题造成的归档日志gap的解析过程进行管理、当检测到standby上的归档日志文件缺失或损坏时自动从主库或另一个standby数据库上检索对应的归档日志文件来进行替换。

在redo传输到standby数据库上以后，应用服务自动应用这些redo数据来与主库进行同步。可以参照一下的关系图。

上面是主库到物理standby数据库的日志传输应用的一个流程图。逻辑standby数据库不一样的地方是，使用SQL Apply代替Redo Apply，并且可以以read-write方式打开。

角色切换包含switchover和failover。switchover主要用在主库的计划停机维护中，不会有数据丢失。当主库不可用时，使用failover进行故障切换，数据是否可能丢失和选择的数据保护模式有关。

Data Guard broker是一个分布式的管理框架，可以使DG配置的创建、维护和监控自动化。你可以使用EM Grid Control提供的web接口来操作，也可以使用DGMGRL。使用后者的话，你可以通过脚本来进行维护和监控。

高可用架构要求数据库和数据库客户端都拥有快速故障切换的能力。有关客户端的故障切换最佳实践，可以参考http://www.oracle.com/goto/maa

Oracle提供了一些技术可以作为Data Guard的补充，来实现更高级别的高可用和数据保护：RAC，RAC和DG一起可以通过系统级别、站点级别和数据级别的数据保护；Flashback Database，提供了逻辑数据损坏和用户错误时的快速恢复；RMAN，可以通过duplicate命令从主库的备份中创建standby数据库，可以从物理standby上进行数据库的备份，在备份后自动删除已经备份的归档日志文件。

总体来说，Data Guard提供了如下的好处：灾难恢复、数据保护和高可用；完备的数据保护；高效的系统资源利用；数据保护的灵活性，可以在可用性和性能中进行平衡；自动gap检测和处理；管理的集中化和简单化；整合在Oracle Database中，不需要独立安装；自动角色切换，这个需要启用broker中的fast-start failover。

软硬件要求

Oracle 11g增强了Data Guard配置的灵活性，主备之间可以有不同的CPU架构、操作系统(比如window和linux)、操作系统二进制文件(32位/64位)、以及Oracle database 二进制文件(32位/64位)。这种混合平台的支持和限制可以参照metalink文档413484.1(物理standby)，1085687.1(逻辑standby)。为了简化操作和减少bug，尽量选择相同的平台。

尽管cpu和操作系统可以不同，但必须选择相同的Oracle版本，除非正在使用逻辑standby做数据库滚动升级(当一边完成升级而另一边未完成时，会出现版本的短暂不同)。

软件上，要求使用Oracle企业版(或者你愿意使用标准版通过操作系统的copy来模拟standby)；滚动升级前的Oracle数据库软件最低版本是10.1.0.3；数据库初始化参数中的COMPATIBLE在DG配置里的所有数据库中都必须一致，除非正在使用逻辑standby，它的COMPATIBLE可以比主库更高；主库必须运行在归档模式；主库和备库要有各自的控制文件；若主库和备库在同一个系统上，它们使用的目录结构必须不同，否则备库将覆盖主库的数据库文件；为了避免不产生日志的直接写入不能传送到standby数据库中，应该在主库为备库的创建进行备份前，打开FORCE LOGGING选项；用来管理主备库实例的用户必须具备SYSDBA系统权限；为了易于进行操作，Oracle建议为主库和备库使用对称的ASM和OMF，也就是说，如果DG配置中的一个数据库使用了ASM或OMF，其它的数据库也应该相应地使用，除非你处于迁移或维护的目的故意使用混合的配置。

创建物理Standby数据库

这部分通过创建物理Standby的一个例子来讲解物理Standby的配置，使用最大性能模式，这也是默认的模式。

准备工作

在创建备用数据库之前你需要确保主库已经正确配置。这些条件包括：启用Force Logging；配置redo传输验证；配置主库来接收redo数据；设置主库的初始化参数；启用归档。下面对这些方面进行具体说明

启用Force Logging

通过下面SQL语句来将数据库置于FORCE LOGGING模式

SQL>ALTER DATABASE FORCE LOGGING;

这个操作可能需要一定时间才能完成，因为它要等待所有unlogged的直接写I/O结束。

配置Redo传输验证

Data Guard使用Oracle Net会话来传输redo数据和控制信息，这些redo传输会话通过保密插口层(SSL)协议或远程的登录密码文件来验证。

使用SSL验证需要满足下面的条件：主备数据库拥有相同的Oracle网络目录(OID)企业域名且允许使用当前的用户数据库连接；与各数据库对应的初始化参数LOG_ARCHIVE_DEST_n和FAL_SERVER为SSL使用配置的Oracle Net连接描述符；每个数据库都有Oracle wallet或支持的硬件安全模块，后者包含一个带有是识别名(DN)的用户证书，它与数据库OID入口的DN相匹配。

如果不能满足SSL验证的先决条件，DG配置的所有成员必须配置为使用远程登录密码文件，并且每个物理standby数据库必须有主库的密码文件的最新拷贝。(如果你为一个用户授予或撤销SYSDBA或SYSOPER权限，或者修改了具有这些权限的用户的登录密码，你必须在每个物理standby或快照standby上将密码文件替换为主库密码文件的最新拷贝)

配置主库以接受redo数据

虽然这一步是可选的，但Oracle建议主库也做好这个配置。这样在进行角色切换后，主库可以迅速切换为standby并开始接收redo数据。

设置主库的初始化参数

在主库上，你需要配置一些初始化参数。下面是一个DG配置中主库初始化参数的例子(chicago为主库，boston是物理standby)

DB_NAME=chicago
DB_UNIQUE_NAME=chicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/chicago/control1.ctl', '/arch2/chicago/control2.ctl'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/chicago/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2=
'SERVICE=boston ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
LOG_ARCHIVE_MAX_PROCESSES=30

注意上面的LOG_ARCHIVE_DEST_2中的ASYNC，这是Oracle的建议设置，需要standby redo log
还有几个初始化参数，在主库切换为备库后生效，这样在角色切换后就不需要修改任何参数：

FAL_SERVER=boston
DB_FILE_NAME_CONVERT='boston','chicago'
LOG_FILE_NAME_CONVERT=
'/arch1/boston/','/arch1/chicago/','/arch2/boston/','/arch2/chicago/'
STANDBY_FILE_MANAGEMENT=AUTO

下面是一个简单的参数列表

参数	建议的设置
DB_NAME	在主库上在数据库创建后指定该名称；在物理standby数据库中，使用主库的DB_NAME
DB_UNIQUE_NAME	为每个数据库指定一个唯一的名称。这个名称设置好后就不再改变，即使主备数据库角色对换
LOG_ARCHIVE_CONFIG	这个参数的DG_CONFIG属性必须在每个数据库上明确设置，以激活Data Guard的全部功能。DG_CONFIG中要包含DG配置中所有数据库的DB_UNIQUE_NAME，中间以逗号隔开
CONTROL_FILES	在主库上指定控制文件的路径
LOG_ARCHIVE_DEST_n	指定redo数据在主库和备库中归档的位置。在上面的例子中，LOG_ARCHIVE_DEST_1用于归档本地的在线日志；LOG_ARCHIVE_DEST_2只对主库起作用，它指定将redo数据库传输到远程的物理standby目的地boston。提示：如果通过DB_RECOVERY_FILE_DEST初始化参数配置了快速恢复区，你不需要显式地通过LOCATION属性指定本地的归档路径，Data Guard会自动使用LOG_ARCHIVE_DEST_1(如果没有设置)作为默认的本地归档目的地。
LOG_ARCHIVE_DEST_STATE_n	设置为ENABLE来允许redo传输服务将redo数据传送到指定的目的地
REMOTE_LOGIN_PASSWORDFILE	如果使用远程登录密码文件来验证管理用户或redo传输会话，该参数必须设置为EXCLUSIVE或SHARED
LOG_ARCHIVE_FORMAT	指定归档日志的格式，%t代表线程，%s表示序列，%r表示resetlogs ID
LOG_ARCHIVE_MAX_PROCESSES	指定Oracle软件启动时调用的归档进程的最大数(1-30)，默认值是4
FAL_SERVER	指定FAL服务器的Oracle网络服务名(通常是运行在primary角色的数据库)。当Chicago数据库运行在standby角色，则使用Boston数据库作为FAL服务器，当Boston不能自动发送缺失的日志文件时，standby可以从该FAL服务器请求这些文件。
DB_FILE_NAME_CONVERT	指定主库数据文件的路径名，后面跟着standby的位置。该参数将主库的数据文件的路径名称转换到standby的数据文件路径名。如果主备库在同一个系统上，或主库和备库数据文件存储的路径不同时，需要指定这个参数。注意该参数只对物理standby有效，可以指定多对路径
LOG_FILE_NAME_CONVERT	作用同上，只不过这个参数对应的是在线日志文件路径
STANDBY_FILE_MANAGEMENT	设置为AUTO，这样当主库中的数据文件添加或删除时，备库也会发生对应的改变。

启用归档

如果未启用归档，使用下面的表达式来启用主库的归档日志模式，并自动归档

SQL>SHUTDOWN IMMEDIATE;
SQL>STARTUP MOUNT;
SQL>ALTER DATABASE ARCHIVELOG;
SQL>ALTER DATABASE OPEN;

逐步创建物理standby数据库

创建主库数据文件的备份拷贝

你可以使用主库的任何备份拷贝来创建物理standby数据库，只要你有足够的归档日志来进行恢复。Oracle建议使用RMAN工作来完成。(可以从Oracle Database High Availability Architecure and Best Practices中参考备份建议，按照Oracle Database Backup and Recovery User's Guide的说明来执行备份操作)

为standby数据库创建控制文件

如果备份过程需要关闭主数据库，则以下面的SQL*Plus命令来启动主数据库

SQL> STARTUP MOUNT;

然后，为standby数据库创建控制文件，并open主库。

SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/boston.ctl';

SQL> ALTER DATABASE OPEN;

注意，不能为主库和备库使用同一个控制文件。

为standby数据库创建参数文件

第一步，从主数据库使用的服务器参数文件(SPFILE)中创建参数文件(PFILE)

SQL> CREATE PFILE='/tmp/initboston.ora' FROM SPFILE;

第二步，修改上一步生成的参数文件。以下是个例子，与上面的例子对应

.
.
DB_NAME=chicago
DB_UNIQUE_NAME=boston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/boston/control1.ctl', '/arch2/boston/control2.ctl'
DB_FILE_NAME_CONVERT='chicago','boston'
LOG_FILE_NAME_CONVERT=
'/arch1/chicago/','/arch1/boston/','/arch2/chicago/','/arch2/boston/'
LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/boston/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2=
'SERVICE=chicago ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
STANDBY_FILE_MANAGEMENT=AUTO
FAL_SERVER=chicago
.
.

这里改变的参数有：DB_UNIQUE_NAME; CONTROL_FILES; DB_FILE_NAME_CONVERT; LOG_FILE_NAME_CONVERT; LOG_ARCHIVE_DEST_1; LOG_ARCHIVE_DEST_2; FAL_SERVER

确认主备数据库的初始化参数COMPATIBLE是一致的，否则redo传输服务不能将redo数据从主库传输到备库上。用SHOW PARAMETERS命令来确认没有其他参数需要改变是个好习惯。

从Primary系统中拷贝文件到Standby系统上

需要拷贝的文件有：创建的数据文件备份；standby控制文件；初始化参数文件

设置环境以支持standby数据库

第一步，如果standby数据库建在windows系统上，使用ORADIN工具创建一个windows服务：WINNT> oradim -NEW -SID boston -STARTMODE manual

第二步，从主库所在系统拷贝远程登录密码文件到standby系统上。如果主库有一个远程登录密码文件，将其拷贝到物理standby系统对应的目录中。如果管理员用户使用了操作系统验证，且redo传输使用了SSL验证，则这一步是可选的

第三步，配置主库和备库上的监听。使用Oracle Net Manager来配置监听，然后重启监听使其应用配置。详细参照Oracle Database Net Services Administrator's Guide

第四步，创建Oracle网络服务名。在所有主备系统中，使用Oracle Net Manager来为主库和备库创建一个网络服务名，供redo传输服务使用。

第五步，为standby数据库创建spfile。比如 CREATE SPFILE FROM PFILE='initboston.ora';

第六步，将主库的加密钱包拷贝到standby系统。如果主库使用了数据库加密钱包，将其拷贝到standby系统中，并配置standby数据库来使用该钱包。从Oracle Database Advanced Security Administrator's Guide中查看透明数据库加密的更多信息。

打开物理standby数据库

执行以下的步骤来启动物理standby数据库和redo应用：

第一步，打开物理standby数据库： SQL> STARTUP MOUNT;

第二步，为standby数据库做好准备接收redo数据。具体步骤在6.2.3章节中描述

第三步，在standby数据库上创建在线重做日志。虽然这一步是可选的，Oracle建议在创建standby数据库的时候这么做，根据最佳实践，standby数据库将做好准备快速切换到主库的角色。

第四步，打开redo应用。执行下面的命令：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;更多信息查看7.3章节，"应用redo数据到物理standby数据库"。

确认物理standby数据库正常运行

第一步，确认存在的归档日志文件。在standby数据库上，查询V$ARCHIVE_LOG视图来确认存在的归档日志文件。举个例子：SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

第二步，强制进行日志切换以归档当前的在线日志文件。在主库上，执行 ALTER SYSTEM SWITCH LOGFILE;

第三步，确认新的redo数据已经归档在standby数据库中。SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

第四步，确认接收到的redo已经被应用。 SELECT SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#; 如果日志已经被应用，APPLIED字段的值通常为IN-MEMORY或YES。

创建之后的步骤

这时候，物理standby数据库正在运行且可以提供最大性能级别的数据保护了。下面列出一些你可以在物理standby数据库上做的额外准备工作。

升级数据保护模式：DG配置默认为最大性能模式

启用FLASHBACK DATABASE：启用Flashback Database以后，在故障切换后就不需要重建主数据库了。你可以在主库和备库上启用这个特性，在13.2和13.3章节介绍如何在DG环境中使用Flashback Database