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 = <mount point or Oracle ASM Disk Group>
DB_RECOVERY_FILE_DEST_SIZE = <disk space quota>
Ø 使用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 <n> 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 '<channel parameters>';
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;
145
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
