Oracle11gR2 Aactive DataGuard(手动)安装部署及维护文档（三）之升级及rman

l 第六部分: dataguard其它管理问题

一．滚动升级DG

升级概要：

1. 升级备用数据库。

2. 将应用程序转移至备用数据库。

3. 升级主数据库。

4. 将应用程序转移回原来的主数据库。

逻辑、物理DG具体升级过程：

逻辑DG滚动升级过程：

１. 停止恢复逻辑备库。

２. 升级逻辑备库。

３. 备库断续恢复完成”弥补”

４. 将备用库转换为主数据库。

５. 将原始的主库转换为备库，然后进行升级。

６. 升级完成后，最后再次角色反转，原来的主库作为新的主库。

物理DG滚动升级过程：

１. 将物理备库转换成临时的逻辑备库。

SQL> alter database recover to logical standby keep identity;

Database altered.

２. 停止恢复逻辑备库。

３. 升级逻辑备库。

４. 备库断续恢复完成”弥补”

５. 将备用库转换为主数据库。

６. 将原始的主库转换为备库，然后进行升级。

７. 升级完成后，然后再次角色反转，原来的主库作为新的主库。

８. 最后把此时的逻辑备库转为物理备库。

注意：通过上面的步骤可以看出，升级物理DG的操作只是多了一步把逻辑备库转换成主物理备库，然后的步骤和升级逻辑DG相同。升级完成后再把逻辑备库转换成物理备库。

详细信息见：

http://download.oracle.com/docs/cd/B28359_01/server.111/b28294/rollup.htm#BABGHIGF

二．11g其它DG特性

１. 网络超时

Data Guard 环境的工具原理是：连接备用服务器端的数据库实例，向备用服务器发送重做数据。如果实

例没有及时响应，日志传输服务将等待指定的超时值，然后放弃。可以在 Oracle 数据库中使用

net_timeout 参数设置超时值。在最大限度的保护模式下，日志传输服务将尝试 20 次后放弃。

但首选您要知道日志传输中当前的延迟。新视图 v$redo_dest_resp_histogram 以直方图形式表示了该时

间值：

SQL> desc v$redo_dest_resp_histogram

Name Null? Type

---------------------- ------- --------------

DEST_ID NUMBER

TIME VARCHAR2(20)

DURATION NUMBER

FREQUENCY NUMBER

该视图在给定圆柱中向您显示了传输花费时间中的次数。如果运行几天后再查看此视图，您可以清楚要设

置的超时时间。然后可使用以下命令设置超时时间：

alter system set log_archive_dest_2 = 'service=pro11sb LGWR ASYNC

valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=pro11sb compression=enable net_timeout=20'

这还是来自于上面的示例。注意参数值中的子句“net_timeout=20”。

２. 可动态修改的参数

在运行逻辑备用数据库环境的过程中，您需要调整该过程并修改一些参数值。在 Oracle 数据库 11g 中，

这些参数中的大部分可以在线更新。您可以通过查询视图 dba_logstdby_parameters 来查看这些参数。

col name format a30

col value format a10

col unit format a10

col setting a6

col setting format a6

col dynamic format a7

select *

from dba_logstdby_parameters

order by name

/

NAME VALUE UNIT SETTIN DYNAMIC

------------------------------ ---------- ---------- ------ -------

APPLY_SERVERS 5 SYSTEM YES

EVENT_LOG_DEST DEST_EVENT SYSTEM YES

S_TABLE

LOG_AUTO_DELETE TRUE SYSTEM YES

LOG_AUTO_DEL_RETENTION_TARGET 1440 MINUTE SYSTEM YES

MAX_EVENTS_RECORDED 10000 SYSTEM YES

MAX_SERVERS 9 SYSTEM YES

MAX_SGA 30 MEGABYTE SYSTEM YES

PREPARE_SERVERS 1 SYSTEM YES

PRESERVE_COMMIT_ORDER TRUE SYSTEM NO

RECORD_APPLIED_DDL FALSE SYSTEM YES

RECORD_SKIP_DDL TRUE SYSTEM YES

RECORD_SKIP_ERRORS TRUE SYSTEM YES

RECORD_UNSUPPORTED_OPERATIONS FALSE SYSTEM YES

注意列 DYNAMIC，其中显示了值是否可动态修改。几乎所有的参数都是动态的。例如，要更改参数

APPLY_SERVERS 同时不停止备用数据库，您可以使用：

SQL> begin

2 dbms_logstdby.apply_set('APPLY_SERVERS',2);

3 end;

4 /

这会将 apply_servers 设置为 2，从而无需关闭备用数据库即可完成这一任务。

３. SQL 应用事件表

在 Oracle 数据库 10g 中，与 SQL Apply 相关的事件将写入到警报日志中，这没有很大的用处，因为您可

能想编写脚本检查它们，用于警报或报告。在 Oracle 数据库 11g 中，默认将事件写入 SYSTEM 模式下的

新表 LOGSTDBY$EVENTS。下面是一个查询示例：

select event_time, error

from system.logstdby$events

order by 1;

EVENT_TIME ERROR

----------------------------- -------------------------------------------------

13-JAN-08 11.24.14.296807 PM ORA-16111: log mining and apply setting up

13-JAN-08 11.24.14.320487 PM Apply LWM 2677727, HWM 2677727, SCN 2677727

14-JAN-08 07.22.10.057673 PM APPLY_SET: APPLY_SERVERS changed to 2

14-JAN-08 07.22.11.034029 PM APPLY_SERVERS changed to 2

14-JAN-08 07.45.15.579761 PM APPLY_SET: EVENT_LOG_DEST changed to DEST_ALL

14-JAN-08 07.45.16.430027 PM EVENT_LOG_DEST changed to DEST_ALL

将事件保存在表中非常有用，原因众多，其中之一就是操作和报告更加方便。但有时将它们保存在警报日

志中也很有用，特别是当使用一些监视工具来扫描警报日志以获取错误和消息时。您可以将逻辑备用数据

库应用参数“event_log_dest”设置为“DEST_ALL”来达到这一目的：

begin

dbms_logstdby.apply_set('EVENT_LOG_DEST','DEST_ALL');

end;

该任务可以动态完成，现在事件将同时传输到表和警报日志中。执行这一命令后，您可以检查警报日志，

除可能的大量的 SQL Apply 事件外，它至少还更改了这两行：

LOGSTDBY: APPLY_SET: EVENT_LOG_DEST changed to DEST_ALL

LOGSTDBY status: EVENT_LOG_DEST changed to DEST_ALL

三．在data guard环境用RMAN

１. ORACLE推荐使用的RMAN和DB配置

1) 配置假定说明：

下面配置步骤假设满足下面环境的情况

Ø standy库是一个物理的备库，而且仅在standby库进行备份

Ø 使用recovery catalog进行备份，以便在一个服务器上的备份能恢复到另一个服务器上，而且recovery catalog有足够空间存储rman的备份信息；catalog备份服务器能从物理上隔离主库和备，当灾难发生后，不影响很久之前备份的恢复，所以oracle推荐使用recovery catalog方法做备份

Ø 数据库配置环境是oracle 11gR1

Ø 使用oracle 安全备份软件和第三方介质管理软件配置RMAN备份到磁带上

2) 主库和备库的环境配置

在DG环境中，下面的配置是被推荐使用在每个主库和备库。

Ø 配置一个FRA（快速闪回区）在本地位置，配置下面的参数

DB_RECOVERY_FILE_DEST =

DB_RECOVERY_FILE_DEST_SIZE =

Ø 使用Spfile参数文件，以便rman能备份spfile参数文件。

Ø 开启数据库闪回功能，以便能闪回数据库到比较早的时点。

3) 在主库的RMAN配置

下面是在主库被推荐使用的rman配置

A. 用RMAN连接主库和recovery catalog

B. 配置备份保存策略，如下

RMAN>CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

RMAN>CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF DAYS;

C. 配置归档删除策略

如果是设置日志传送完成后删除归档如下：

CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY;

如果是设置日志应用完成后删除归档如下：

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED TO ALL STANDBY;

D. 配置连接串在主和备库，配置RMAN的主备库DB_UNIQUE_NAM参数：

当使用下面的命令时所用到RESYNC CATALOG FROM DB_UNIQUE_NAME。配置方法如下：

CONFIGURE DB_UNIQUE_NAME BOSTON CONNECT IDENTIFIER 'boston_conn_str';

注意：主备库密码文件的sysdba密码必需相同，'boston_conn_str'是在主库配置备库的的tns连接服务别名。

RMAN> CONFIGURE DB_UNIQUE_NAME 'HTDB2' CONNECT IDENTIFIER 'htdb2_242';

RMAN> CONFIGURE DB_UNIQUE_NAME 'HTDB3' CONNECT IDENTIFIER 'htdb3_243';

RMAN> LIST DB_UNIQUE_NAME OF DATABASE;

数据库列表

数据库关键字 数据库名称 数据库 ID 数据库角色 Db_unique_name

------- ------- ----------------- --------------- ------------------

1 HTDB2 1139129460 PRIMARY HTDB1

1 HTDB2 1139129460 STANDBY HTDB3

1 HTDB2 1139129460 STANDBY HTDB2

RMAN> RESYNC CATALOG FROM DB_UNIQUE_NAME 'HTDB2';

从 DB_UNIQUE_NAME 为 HTDB2 的数据库进行重新同步

在执行完上面的resync语句后，主库的CONFIGURE就会同步到备。可以分别用show all查看主备库配置。

4) 在备库执行备份的RMAN配置

在standby库上做备份的库上，下面的RMAN配置是推荐使用的。

A. 使用rman连接目标备库和recovery catalog.

B. 启用controlfile和spfile文件自动备份

CONFIGURE CONTROLFILE AUTOBACKUP ON;

C. 跳过在已经存在的末发变化有效的数据文件备份

CONFIGURE BACKUP OPTIMIZATION ON;

D. 使用介质管理软件配置磁带备份通道

CONFIGURE CHANNEL DEVICE TYPE SBT PARMS '';

E. 配置归档删除策略，如：

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;

注意：因为在standby库执行了日志备份，建议再进行配置BACKED UP选项为日志删除策略。如：

backup as compressed BACKUPSET archivelog all not backed up delete all input;

5) 在备库未执行备份的RMAN配置

在未执行备份的备库上，下面的RMAN配置是建议使用的

A. 使用rman连接目标备库和recovery catalog.

B. 启动归档自动删除策略。

如果在备库配置了下面的参数，在备库归档被应用之后，备库会根据FRA的存储空间自动删除归档日志

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;