Oracle 11g Data Guard 物理备库快速配置指南

Oracle 11g Data Guard 物理备库快速配置指南

[日期：2015-04-17]

来源：Linux社区  做者：cloudsnowe

[字体：大 中 小]

缘起
最近作了Oracle 10g和11ｇ的物理备库配置实验，发现 Data Guard 其实很容易，可是缺乏好文档。我是参考官方文档作的实验，以为它写的不是很清楚的。

Google 出来两个pdf文档，读了以为比官方文档强不少。翻译下，也许会对某些朋友有用。翻译的同时我也好更熟悉下这两个文档。很久没翻译过英文了，能够顺便练练手。

原文档下载地址（墙外）：

Configure Dataguard 11gR2 Physical Standby Part 1
Configure Dataguard 11gR2 Physical Standby Part 2

第一部分
简介
Data Guard 是 Oracle 数据库的一个功能，可以提供数据库的冗余。冗余是经过建立一个备用（物理复制）数据库实现，备库最好是在不一样的地理位置或者在不一样的磁盘上。备库经过应用主库上的变化来保持数据同步。备库可使用重作日志应用(物理备库)或SQL应用同步(逻辑备库)。

本文旨在说明 Data Guard 的配置并不复杂，不须要特殊的技能或者培训才能学会搭建。它将快速展现给读者搭建一个物理备库的过程。个人目标是，即便你第一次接触 Data Guard，刚考虑要使用它或担忧它会不会很难配置，本文将帮助你快速搭建起一个正常运行起来的物理备库。

为何使用 Data Guard
每种 Oracle 高可用性工具都有其目的。使用 Data Guard 的理由有：

整个数据库的冗余
故障时的快速恢复
故障后客户端能自动重连
在备库运行备份
较好的故障平均修复时间
并不复杂
系统环境
在写完本文后，我使用 DBCA 建立了一个新数据库 JED，而后从新运行了文中的配置步骤，确认其对一个基本的 Oracle 11g 数据库适用。主库叫 JED，运行在一台叫 dev-db1的服务器上。备库叫JED2，运行在一台叫 dev-db2 的服务器上。

不须要提的基本前提
有一些任何生产库都应该有的基本的设置。其中一个就是归档模式。对于生产库，这应该是一个明显的必须配置。若是你的生产库没有适用归档模式，你要么须要立刻开始读点书，要么你得有一个很是很是好的理由。我不大肯定谁真能找出一个理由，但任何准则都有例外。

如何修改你的数据库为归档模式：

SQL> shutdown immediate
SQL> startup mount
SQL> alter database archivelog;
SQL> alter database open;
SQL> archive log list;

主库准备
首先，备库要成为主库的彻底相同的复制，它必须接收来自主库的重作日志。Oracle 数据库中，一个用户能够用指定某操做不产生日志(好比使用 NOLOGGING 语句）。对于备库来讲，这是个问题。你必须确认用户没法指示数据库不产生重作日志，这须要启用数据库的强制日志功能。启用方法以下：

SQL> alter database force logging;
SQL> select name, force_logging from v$database;

你应该看到 force_logging 列为 YES。

其次，你要确认当主库添加或删除数据文件时，这些文件也会在备库添加或删除。启用此功能的方法以下：

SQL> alter system set standby_file_management = 'AUTO';

再次，咱们要确认书库有备用日志文件(Standby Log Files)。备库使用备用日志文件来来保存从主库接收到的重作日志。主库上也创建备用日志文件有两个缘由，一是主库可能转换成备库，备库须要备用日志，二是若是主库建了备用日志，备库会自动建。备用日志应该跟在线日志同样大，组数应该至少跟在线日志同样多，或者更多。我喜欢给备用日志一个跟在线日志不一样范围的编号，好比在线日志组是1到6，备用日志就是11到16。建立备用日志的方法以下：

SQL> alter database add standby logfile group 11 ('/oradata/JED/g11m01.sdo','/oradata/JED/g11m02.sdo') size 50M;

若是你不是使用 SSL 作重作日志传输验证(通常来讲不会)，那么你须要使用密码文件作验证。你必须建立密码文件，而且设置参数 REMOTE_LOGIN_PASSWORDFILE 为 EXCLUSIVE 或 SHARED。通常数据库默认就有密码文件，而且此参数默认为 EXECUSIVE。先检查下这两项，若是不是默认，设置方法以下：

SQL> alter system set remote_login_passwordfile=exclusive scope=spfile;
OS> orapwd password=<sys 用户密码>

最后，检查数据库的 db_unique_name 参数是否设置。若是没有，使用 alter system 进行设置：

SQL> show paramter db_unique_name;
SQL> alter system set db_unique_name=some_name scope=spfile;

闪回数据库
我强烈建议开启数据库闪回功能。闪回容许你将数据库还原到之前的某一时间点。当发生故障转移时，这个功能很是有用，它能让你将老的主库闪回到故障前，而后将其转换为备库。若是没有启用闪回功能，你就必须重建备库，意味着要再复制一次数据文件。除了这个好处，闪回还能在某些状况下让你避免从备份恢复数据。

启用闪回功能，必须先配置快速恢复区(Flash/Fast Recovery Area). 方法以下：

SQL> alter system set db_recovery_file_dest='&快速恢复区目录或ASM磁盘组名';
SQL> alter system set db_recovery_file_dest_size=400G;

配置好快速恢复区后，就能够启用闪回日志功能：

SQL> alter database flashback on;
SQL> select flashback_on from v$database;

FLASHBACK_ON 这列的值应该是 YES。若是你碰到 ORA-01153 报错，那必定是在备库进行此操做。你须要先取消重作日志应用，启用闪回日志，而后从新启用日志应用。

在主库启用闪回日志，不会同步备库也启用。你必须手动在主库和备库上均启用闪回日志。若是不启用闪回日志，当出现故障转移时，你将须要彻底从新开始建立一个备库。

SQL*NET 配置
在建立备库前，要确认两台服务器的数据库之间能通讯，若是咱们要用 RMAN 的 duplicate from active database 命令建立备库的话。咱们须要配置监听和 TNS 名。你能够手动配置，也可使用网络配置工具(netca)。我更喜欢手动配置，由于我比较老派，而且这些配置文件又不复杂，

首先须要配置主备库的监听。虽然数据库会自动注册监听，但若是要使用 RMAN 的 duplicate 命令建立备库，备库必须首先处于 NOMOUNT 状态。在 NOMOUNT 状态下，数据库实例不会自动注册监听，你必须配置静态监听。另外必需要注意的一点是，NOMOUNT 状态下的数据库必须使用专用模式(dedicated server)链接。

两台服务器上的 TNS 名字文件必须配置好，让主备库能用 LOG_ARCHIVE_DEST_N 和 FAL_SERVER 参数（稍后会介绍这些参数）中的服务名(Service Names）找到对方。具体配置应相似下例。

主库(dev-db1)的监听配置：

SID_LIST_LISTENER=
    (SID_LIST =
        (SID_DESC =
            (GLOBAL_DBNAME = JED)
            (ORACLE_HOME = /oracle/product/11.2.0)
            (SID_NAME = JED)
        )
    )

备库(dev-db2)的的监听配置：

SID_LIST_LISTENER=
    (SID_LIST =
        (SID_DESC =
            (GLOBAL_DBNAME = JED2)
            (ORACLE_HOME = /oracle/product/11.2.0)
            (SID_NAME = JED2)
        )
    )

主库的 TNS 名字文件配置：

JED2 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = dev-db2)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = JED2)
    )
  )

备库的 TNS 名字文件配置：

JED =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = dev-db1)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = JED)
    )
  )

重作日志传输配置
如今主备库之间依旧能够互相通讯了，下一步是配置归档位置和重作日志传输。咱们将先在主库上进行配置，而后等备库建立好后，修改备库的配置。

配置归档位置：

SQL> alter system set log_archive_dest_1 = 'location=use_db_recovery_file_dest valid_for=(all_logfiles, all_roles) db_unique_name=JED';

这个命令指定快速恢复区做为归档位置，此归档位置用于在全部数据库角色下归档全部的日志文件。官方文档里说使用 valid_for=(online_logfiles, all_roles)，这将致使备库没法归档备用日志文件，由于它们不是在线日志。但若是使用 all_logfiles 选项，主备库将都能归档在线以及备用日志。若是你想在备库进行备份，并同时备份归档日志的话，必须使用 all_logfiles。

而后配置重作日志传输到备库：

SQL> alter system set log_archive_dest_2 = 'service=JED2 async valid_for=(online_logfile,primary_role) db_unique_name=JED2';

这条语句说，若是这是主库，就使用服务名 JED2 传输在线日志，目标库名叫 JED2。

要注意STANDBY_ARCHIVE_DEST 参数不须要，已经被官方弃用。当调试时，很多人好心建议我设置此参数，但设置此参数后启动数据库，只会报 ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance 错。

另外一个要设置的参数是 FAL_SERVER。这个参数指定当日志传输出现问题时，备库到哪里去找缺乏的归档日志。它用在备库接收的到的重作日志间有缺口的时候。这种状况会发生在日志传输出现中断时，好比你须要对备库进行维护操做。在备库维护期间，没有日志传输过来，这时缺口就出现了。设置了这个参数，备库就会主动去寻找那些缺乏的日志，并要求主库进行传输。

SQL> alter system set fal_server = 'JED2';

注意 FAL_CLIENT 参数在11g里已经弃用。

而后咱们要让主库知道 Data Guard 配置里的另一个库的名字：

SQL> alter system set log_archive_config = 'dg_config=(JED,JED2)';

这一步作完后，咱们就能够准备好备库的环境，并开始建立备库了。

备库环境准备
如今开始准备备库环境。有不少种方法来执行这些步骤。我这里写的是我以为最适合个人方法。你应该实验多种方法，看哪一种比较适合你。

首先，咱们要为备库建立密码文件和参数文件(spfile)。密码文件能够直接复制过去，只须要改下名字就行。好比，主库上的密码文件是 $ORACLE_HOME/dbs/orapwJED。咱们把它复制到备库服务器的相同位置，用备库的 SID 取代主库，修改其名字为 orapwJED2。

为了建立备库 spfile，先建立一个启动参数文件(pfile)：

SQL> create pfile from spfile;

我想介绍一个看起来挺不错新功能，使用 RMAN 建立备库 SPFILE。我不使用这个功能的理由是：

反正我也须要复制密码文件到备库服务器，因此它并无节省我复制文件的时间。
要使用这个功能，你仍然须要使用 parameter_value_convert 参数作不少替换工做，还有使用 SPFILE 语句和多个 SET 语句以确保一切正确。
我发现复制 pfile 过去更容易(你甚至能够直接粘贴复制)，只要改下名字，而后改几个里面的参数就行。这很容易，你也能够在手动修改和调试的过程当中学到不少。我发现手动改比用 RMAN 的 SPFILE建立功能更快。

建立好了主库的 pfile 后，将其复制到备库服务器的相同位置，使用备库的 SID 修改其名字。你须要对 pfile 作以下修改：

根据你备库的配置和文件位置，你可能须要修改 AUDIT_FILE_DEST，CONTROL_FILES 和 DISPATCHERS 参数（也许还有其余须要修改的参数）。
LOG_ARCHIVE_DEST_1 参数中的 db_unique_name 修改成备库的相应惟一名（这里是 JED2）。
LOG_ARCHIVE_DEST_2 参数，修改成主库对应的服务名和数据库惟一名（这里是 JED）。
FAL_SERVER 参数修改指向主库的服务名。
增长以下参数：
db_unique_name=JED2
db_file_name_convert 和 log_file_name_convert。若是主备库的数据文件、日志文件位置不一样，须要设置这两个参数。
而后在备库服务器上建立所需目录结构和修改相关文件。至少须要修改以下建立目录和文件：

$ORACLE_BASE/admin/$ORACLE_SID
$ORACLE_BASE/admin/$ORACLE_SID/adump（audit_file_dest配置的目录）
数据文件目录
控制文件目录
日志文件目录
快速恢复区目录
将备库信息加到 /etc/oratab 文件
如今能够准备启动备库实例来建立数据库了。在启动过程当中建立一个 spfile。

SQL> startup nomount pfile=initJED2.ora
SQL> create spfile from pfile;
SQL> shutdown
SQL> startup nomount
SQL> show parameter spfile
SQL> exit

show parameter spfile 显示 spfile 的位置，这时备库处于 NOMOUNT 状态。

备库建立
就像以前的步骤同样，建立数据库这一步也能够有多种方法。在11g中，我将使用 RMAN 的复制功能，由于它很容易。在上一步里，咱们复制了密码文件和参数文件到备库服务器，修改好了参数文件，并建立了 spfile。这让使用 RMAN 复制功能更加容易，固然，你也能够跳过手工复制密码和参数文件这步，让 RMAN 使用 SPFILE，PARAMETER_VALUE_CONVERT 和 SET等命令帮你自动完成。

使用 RMAN 建立备库的命令很是简单。它指示 RMAN 直接复制当前活动的数据库（主库）到辅助数据库（备库）。这样你就不须要现将主库的备份复制到备库服务器上，再还原数据库。在今天的存储技术下，咱们有更快更简单的方式复制数据库，但为了展现11g的这个新功能，而且这个功能又很简单，我喜欢尽量使用它。

RMAN> connect target sys@JED
RMAN> connect catalog <catalogowner>@<catalogdb>
RMAN> connect auxiliary sys@JED2
RMAN> duplicate target database for standby from active database;

在 11.2.0.2.0 版本后，你能够直接使用 connect target 链接辅助数据库，但若是不指定用户名和密码，在复制到备库时将报 invalid username/password 错。

当复制命令在执行时，我喜欢 tail 备库的告警日志文件，观察复制进行到了哪一步和查看是否有报错。注意，针对在线和备用日志文件报 ORA-27037: unable to obtain file status 错是正常的。

你也能够并行复制以提升性能。须要分派主库和备库多个通道后，再执行复制命令：

run
{
    allocate channel chan1 type disk;
    allocate channel chan2 type disk;
    allocate channel chan3 type disk;
    allocate channel chan4 type disk;
    allocate auxiliary channel aux1 type disk;
    allocate auxiliary channel aux2 type disk;
    allocate auxiliary channel aux3 type disk;
    allocate auxiliary channel aux4 type disk;
    duplicate target database for standby from active database;
}

若是一切正常，你将看到 RMAN 报出相似以下信息：

Finished Duplicate Db at 07-MAY-10

当备库复制完成后，我喜欢在备库启用闪回日志：

SQL> alter database flashback on;

启动重作日志应用
启动或者中止重作日志应用很是容易。启动日志应用：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE

DISCONNECT FROM SESSION;

这个命令指示备库开始使用备用日志文件进行恢复。它也告诉备库命令完成后回到命令行界面。若是你想中止恢复：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

确认日志应用正常
你要确认重作日志正在应用到备库。首先咱们要确认主备库里的归档目的地配置都是有效的：

SQL> select DEST_ID, STATUS, DESTINATION, ERROR from V$ARCHIVE_DEST where DEST_ID<=2;

目的地状态应该显示为 VALID。

而后确认重作日志是否真的被应用了，在主库执行：

SQL> select SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED, ARCHIVED from V$ARCHIVED_LOG where name = 'JED2' order by FIRST_TIME;

若是归档和日志应用均正常，APPLIED 和 ARCHIVED 列都应该是 YES。不少教程里都让这个查询以 SEQUENCE# 列排序，但我不推荐。若是以 SEQUENCE# 列排序，当你作了一次故障转移后，序列号会再从1开始，这时使用这个查询，你将不能在结果最后看到最新的记录。我曾经很奇怪为何查不到新记录，实际上是由于新记录不是出如今最后，我没看到。因此，这个查询都是以 FIRST_TIME 列排序。

若是你发现日志没有被应用，那多是重作日志有了缺口，这种状况下备库没法进行日志应用。但若是你的 FAL_SERVER 参数设置正确，这应该不会有问题。你能够在主库上检查是否有重作日志缺口：

SQL> select STATUS, GAP_STATUS from V$ARCHIVE_DEST_STATUS where DEST_ID = 2;

若是一切正常，应该返回 VALID 和 NO GAP。若是你想测试下 FAL_SERVER 这个参数是怎么工做的。能够先把备库关掉，而后在主库切换几回日志，等一会，启动备库，再切换一第二天志。这样缺口很快就会出现。若是 FAL_SERVER 设置正常，缺乏的重作日志会被传输过来并应用。

V$DATAGUARD_STATUS 视图对查找错误和了解发生了什么很是有用。能够在主备库上执行如下查询查看数据库状态：

SQL> select * from V$DATAGUARD_STATUS order by TIMESTAMP;

有时候你手工想确认下数据真的同步了。一个更让人信服的方法是，直接查询备库，看新数据是否存在。你能够将备库打开为只读状态，首先取消日志应用，再执行以下命令：

SQL> ALTER DATABASE OPEN READ ONLY;

这时你能够查询变化了的数据是否同步过来。11g已经支持活动备库，可让数据库在只读状态下打开，同时启动日志应用。

总结
如今你有一个配置好的 Data Guard，也就有了一个冗余的数据库。我不想留下主备转换、故障转移、重建库等不讲，这些主题将放到本文的第二部分。

我但愿本文能帮助你更容易和更快速地建立你的 Data Guard 环境。

--------------------------------------分割线 --------------------------------------

Oracle Data Guard 重要配置参数 http://www.linuxidc.com/Linux/2013-08/88784.htm

基于同一主机配置 Oracle 11g Data Guard http://www.linuxidc.com/Linux/2013-08/88848.htm

探索Oracle之11g DataGuard http://www.linuxidc.com/Linux/2013-08/88692.htm

Oracle Data Guard （RAC+DG) 归档删除策略及脚本 http://www.linuxidc.com/Linux/2013-07/87782.htm

Oracle Data Guard 的角色转换 http://www.linuxidc.com/Linux/2013-06/86190.htm

Oracle Data Guard的日志FAL gap问题 http://www.linuxidc.com/Linux/2013-04/82561.htm

Oracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby 处理方法 http://www.linuxidc.com/Linux/2013-03/82009.htm

--------------------------------------分割线 --------------------------------------

更多详情见请继续阅读下一页的精彩内容： http://www.linuxidc.com/Linux/2015-04/116345p2.htm