Oracle9i数据库Data Guard实施及维护手册
一．Data Guard介绍
备用数据库（standby database）是ORACLE 推出的一种高可用性(HIGH AVAILABLE)数
据库方案，在主节点与备用节点间通过日志同步来保证数据的同步，备用节点作为主节点的
备份，可以实现快速切换与灾难性恢复。
ORACLE 从7.3 才开始支持standby database。7.3.x-8.0.x 需要手工拷贝所有归档日志并
手工同步，从ORACLE815开始，开始支持多节点复制，并实现了自动同步，但是这种同步
是数据异步模式的，可能引起数据丢失。
Oracle9i的Data Guard是对Oracle8i中Standby Database功能的加强，而Standby Database技术出现的主要初衷就是为了容灾（Disaster Recovery），所以具有更强大功能的Data Guard毫无疑问成了Oracle数据库高可用性解决方案中首选使用的产品。
Oracle 提供支持高可用性 (high availability) 相关产品主要有下面几种：
(1) Oracle Fail Safe on NT
(2) Oracle Real Application Cluster (RAC)
(3) Oracle Parallel Fail Safe
(4) Oracle Advanced Quening
(5) Oralce Advanced Replication
(6) Oracle Data Guard
这几种产品中，最让人困惑的是如何在 RAC，Data Guard 和 Advanced Replication 中选择适合自己生产环境的高可用性产品。
因此我就先将这三种产品做一下比较：
RAC (Oracle Real Application Cluster)
RAC的前身是Oracle8i中的OPS（Oracle Parallel Server），RAC 是多个单CPU机或
SMP(Symmetric Multi-Processing system) 或者MPP(Massively Parallel Processing)的cluster 。cluster 里面不同的服务器使用一个(一般是一个)或多个oracle instances 与一个database 连接。 主要的技术特点：
(1) 数据库中所有的数据文件，控制文件和重作日志文件都是建立在裸设备（raw devices）上的，虽然随着OCFS的推出，在某些平台上面已经开始支持Cluster文件系统，但是总体来说RAC在技术方面对操作系统的设置有很高的依赖性，需要有Cluster软件的支持，难度比较大。
(2)每个数据库实例都有自己单独的联机重作日志组，因此在做备份和恢复的时候，需要特殊的处理。
(3)RAC的存储方面并没有额外的冗余，因此在介质损坏的情况下，还是需要依靠RAID 等磁盘冗余方案来支持。
软件许可证方面，RAC并未包括在数据库使用许可证 (license) 之内，需要额外购买；同样，Oracle 产品的技术支持，也需在数据库支持之外另外购买 OPS/RAC 部分。
总体来说，RAC的设置与维护还是比Data Guard复杂和昂贵得多。
高级复制(Advanced Replication )
主要的技术特点：
(1) Replication 使用分布式数据库技术在多个站点之间共享数据。
(2) Replicated Database 和Distributed Database 并不一样，在分布式数据库系统中数据在
多个站点同时有效，但是一个表只会存在于一个站点中，而对于Replication 来说相同
的数据将同时存在于多个站点中。
(3) 使用replication 的原因：
1) Availability：也就是提供了优秀的failover保护
2) Performance：由于有多个server，所以可以将用户业务分布在不同的server 上
3) Disconnected computing：实体化视图允许用户在和master 断开后使用数据库
的子集，在重新连接上master 之后再进行两者的同步。
4) Network load reduction：由于有多个server，所以可以减少master 的网络请
求
5) Mass deployment：通过变量产生自定义的实体化视图以满足多种需求
(4) 在不同的Oracle 发行版本之间以及不同操作系统的Oracle 之间都可以使用Advanced Replication。这是高级复制的最大优势所在。而RAC和Data Guard都需要操作系统和数据库版本相同。
高级复制不需要除数据库之外额外的使用许可 (license) 。
高级复制要对需要同步的每个数据库对象都进行单独的复制生成准备工作，所以当数据库中存在大量对象需要同步的话，高级复制的初期准备工作非常耗时。而且高级复制对于DDL操作不能很好支持，必须要使用特殊的包来执行DDL操作，才能将操作复制到远方数据库。所以高级复制作为一个整体数据库的容灾方案并不十分理想，只有在由于费用问题，要求灾备数据库和主数据库的硬件架构不同的情况下，才应该选择这种方案。
Data Guard
与RAC或者OPS比较 Data Guard 在高可用性方面的使用性，可以从几个方面来探讨：
(1) 数据库备份：Data Guard克隆了原始数据库，因此原始数据库有备份，具有灾备要求的冗余量；而 RAC/OPS 只有一份数据库，如果数据所在的硬盘发生了问题，需要另外的方法(比如RAID)解决。
(2) 服务器的数量及利用率：RAC/OPS 至少需要双机支持，支持动态负载平衡，对於大量用户访问的环境，可以在多个服务器同时处理用户的请求。在多机系统环境，如果尚有一台服务器运行正常，不会造成整个数据库系统由于故障彻底停机。Data Guard可以设置在同一个服务器上面，理论上支持单机环境。
(3) 故障停机时间：如上面所说，OPS/RAC 环境只要还有一台服务器正常运行，就不会造成停机；Data Guard环境中，primary 数据库到 Standby 数据库的切换，至少需要几分钟的停机时间。
(4) 费用：使用许可证方面，Data Guard不需要购买数据库之外的使用许可。同时在维护费用方面，OPS/RAC 的实施也相对复杂，人力、物力相对昂贵。
通过上面几种产品的比较，再分析此次客户对于灾备的硬件投入和功能要求，我们认为Data Guard是比较合适的方案。
首先此次灾备环境中使用的都是SUN的小型机，符合Data Guard对于服务器同构的要求，其次由于灾备库在上海，而主库在北京，也同样满足Data Guard对于HA的要求。
而Data Guard在也同样能够满足最多丢失一分钟的数据，并且使用灾备库作为历史查询服务器这样的功能需求。
二．Data Guard类型的比较
Oracle9i在Data Guard的配置方面提供了几种不同的类型，根据客户对于高可用性的不同要求，可以选择不同的Data Guard类型。
下面对于Data Guard的几种类型作一个列举和比较。
Data Guard环境中包含一个产品数据库，这是正常运行用以支撑日常业务的主数据库，称为Primary Database。另外包含一个或者多个灾备数据库，称为Standby Database。
按照备用库（Standby Database）应用归档日志的不同方式，Standby Database可以分为物理备用库（Physical Standby）和逻辑备用库（Logical Standby）。
按照主数据库（Primary Database）的保护模式，整个Data Guard环境分为最大数据保护模式（MAXIMIZE PROTECTION），最大可用性模式（MAXIMIZE AVAILABILITY），最大性能模式（MAXIMIZE PERFORMANCE）。
按照主库向备用库传递重作信息的方式，可以分为ARCH方式和LGWR方式。
物理备用库可以运行在数据库三种保护模式中的任何一种模式下，逻辑备用库只可以运行在最大可用性模式或者最大性能模式下。无论物理备用库还是逻辑备用库都可以在传输日志上采用ARCH方式或者LGWR方式。
物理备用库（Physical Standby）：
提供了一份跟主数据库在物理级别上完全相同的copy，指在数据库的block级别都是完全相同的，比如数据库表中记录的rowid。物理备用库是通过不断地恢复Primary Database传入的重作日志数据信息来达到跟主数据库保持同步。
物理备用库在处于自动恢复重作日志信息的状态下，无法提供查询服务。因为此时的备用数据库并不是处于正常打开的状态，数据库的非sysdba用户无法登录备用库，自然也就无法进行普通的查询业务。
逻辑备用库（Logical Standby）：
指在逻辑上跟主数据库保持一致，但是在物理层面上跟主数据库并不相同。逻辑备用库是通过将Primary Database传入的重作日志数据信息转化为SQL语句，然后在备用库上重新执行来达到跟主数据库保持同步。
逻辑备用库在应用重作信息的同时也可以提供查询功能。但是由于逻辑备用库应用重作日志的方式限制，所以逻辑备用库在功能和性能上面都有所限制。以下是逻辑备用库的一些限制条件。
1. 以下数据类型不被支持：
NCLOB ，LONG ，LONG RAW ，BFILE ，ROWID ，UROWID
2. 以下操作不被支持：
ALTER DATABASE ，ALTER SESSION ，ALTER SNAPSHOT
ALTER SNAPSHOT LOG ，ALTER SYSTEM SWITCH LOG
CREATE CONTROL FILE ，CREATE DATABASE ，
CREATE DATABASE LINK ，CREATE PFILE FROM SPFILE ，
CREATE SCHEMA AUTHORIZATION
CREATE SNAPSHOT ，CREATE SNAPSHOT LOG ，CREATE SPFILE FROM PFILE
CREATE TABLE AS SELECT FROM A CLUSTER TABLE
DROP DATABASE LINK ，DROP SNAPSHOT ，DROP SNAPSHOT LOG
EXPLAIN ，LOCK TABLE ，RENAME ，SET CONSTRAINTS ，
SET ROLE ，SET TRANSACTION
3. 高级队列的管理和物化视图的刷新不被支持
4. 要求每张表应该有主键或者唯一性索引 ，如果必须有没有唯一性标识的表，那么可以激活Primary库的supplemental logging属性，但是这样将会在重作日志中记录该表中每一条记录的所有字段信息，会大大增加重作日志的记录量。
以下是Data Guard环境中物理备用库和逻辑备用库的配置图。
最大数据保护模式（MAXIMIZE PROTECTION）
提供最高等级的数据保护，重作信息从主库同步送到备用库。直到备用库成功接收重作信息，主库上的事务才会提交。如果由于网络等问题，导致备用库不可用，那么主库也同时会被关闭。这种模式保证了完全没有数据丢失。
最大可用性模式（MAXIMIZE AVAILABILITY）
在备用库正常的情况下，该模式提供了跟“最大数据保护模式”一样的机制，保证没有任何数据丢失。如果备用库不可用，那么将转换到“最大性能模式”，操作可以在主库上继续执行。当备用库重新可用之后，将会继续同步。但是如果在同步完成之前，主库由于故障损坏，将会丢失数据（当然，可以通过RAID，RMAN等方式尽量保护主库即使出现故障也不丢失数据）。
最大性能模式（MAXIMIZE PERFORMANCE）
这种模式下，主库上的重作信息是异步传递到备用库上，不论备用库上是否已经成功接收了重作信息，主库上的操作都会成功执行。所以这种模式提供了最好的性能，但是最低的数据保护。这是Oracle9i配置Data Guard的默认模式。
ARCH方式
当主库归档联机重作日志文件时，ARCH归档进程在归档到本机的同时，将重作数据传递到备用库，由备用库端的RFS进程（Remote File Server）接收，生成备用库端的归档日志文件，然后由备用库端的MRP进程（物理备用库类型）或者LSP进程（逻辑备用库类型）将归档日志文件恢复到备用库中。
传递方式如图：
LGWR方式
物理备用库类型下，主库的LGWR进程在将重作数据写到本地联机重作日志文件中的同时，将重作数据传递到备用库，备用库的RFS进程将收到的数据写入本地的备用重作日志文件（Standby Redo Log）中。当主库日志切换时也触发备用库的日志切换，切换发生时，备用库的归档进程将重作日志文件归档，然后由备用库端的MRP进程将归档日志文件恢复到备用库中。
传递方式如图：
逻辑备用库类型下，不可以创建备用重作日志文件（Standby Redo Log），所以处理流程跟物理备用库稍有不同。
主库的LGWR进程在将重作数据写到本地联机重作日志文件中的同时，将重作数据传递到备用库，备用库的RFS进程将收到的数据写入本地的归档日志文件中。当主库日志切换时也触发备用库的日志切换，切换发生时，备用库的归档进程完成归档日志文件的最后生成，然后由备用库端的LSP进程提取归档日志文件中的SQL语句，重新在备用库上运行一遍。
传递方式如图：
最后上述所有类型或者方式互相搭配进行一个比较。
|
Maximum Protection |
Maximum Availability |
Maximum Performance | |
|
重作传递方式 |
LGWR |
LGWR |
LGWR或者ARCH |
|
网络传递模式 |
同步 |
同步 |
当使用LGWR传递方式时为异步方式，如果使用ARCH传递方式，那么不牵涉联机重作数据的网络传输 |
|
磁盘写入选项 |
AFFIRM |
AFFIRM |
NOAFFIRM |
|
是否需要备用重作日志文件 |
需要 |
只在物理备用库类型中需要 |
如果物理备用库使用LGWR传递方式，那么需要 |
|
备份库类型 |
物理 |
物理或逻辑 |
物理或逻辑 |
三．硬件配置
四．软件配置
五．实施Data Guard前提条件和注意事项
灾备环境中的所有节点必须安装相同的操作系统，但是操作系统的版本可以不相同。
灾备环境中的所有节点必须安装完全相同版本的Oracle数据库软件，包括版本号和发布号，比如必须都是Oracle
主库必须处于归档（ARCHIVELOG）模式。
灾备环境中所有节点的硬件和操作系统架构必须相同，比如主节点是Sparc 64-bit SunOS，那么备用节点也必须是Sparc 64-bit SunOS。
主库可以是单实例，也可以是RAC。
主节点和备用节点之间的硬件配置可以不同，比如CPU数量，内存数量，存储的配置等等。
配置灾备环境的数据库用户必须具有SYSDBA权限。
cluster环境中两个节点的tnsnames.ora, listener.ora, sqlnet.ora, spfile, pfile必须保证相同
六．实施步骤
Physical Standby配置
修改控制文件，修改最大日志组为10
alter database backup controlfile to trace;
ORACLE_HOME为/export/home/oracle/app/oracle/product/
190作为primary，185作为Standby
创建Standby的Oracle软件
打包Primary上的oracle软件
cd /export/home/oracle/app/oracle/product
tar cvf db.tar
ftp到Standby服务器相应目录
创建Standby上的Oracle软件目录结构
mkdir -p /export/home/oracle/app/oracle/product
cd /export/home/oracle/app/oracle/product
tar xvf db.tar
cd /export/home/oracle/app/oracle
mkdir -p admin/ctsdb/bdump
mkdir -p admin/ctsdb/cdump
mkdir -p admin/ctsdb/udump
创建Standby上的dba组，oracle用户，修改oracle用户的环境变量，修改/etc/system文件
1。设置Primary强制Logging
ALTER DATABASE FORCE LOGGING;
2。设置Primary为归档模式，启动自动归档
3。检查Primary中所有数据文件
4。关闭Primary，关闭应用服务器，停止监听
5。cp所有数据文件到本地备份路径
6。启动Primary，保持监听和应用服务器处于停止状态
7。生成Standby控制文件
ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/control01.ctl';
8。生成初始化参数文件
CREATE PFILE='/tmp/initctsdb.ora' FROM SPFILE;
9。将5,7,8中生成的所有文件以及密码文件cp到Standby服务器
10。修改Standby的初始化参数文件
添加下面行：
*.standby_archive_dest='/export/spare/oradata/ctsdb/archive'
*.fal_server='ctsdb.primary'
*.fal_client='ctsdb.standby'
*.standby_file_management=auto
*.remote_archive_enable=TRUE
11。修改Primary和Standby的lisener.ora和tnsnames.ora文件
# LISTENER.ORA Network Configuration File: /export/home/oracle/app/oracle/product/
network/admin/listener.ora
# Generated by Oracle configuration tools.
SID_LIST_LISTENER_DG =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = ctsdb)
(ORACLE_HOME = /export/home/oracle/app/oracle/product/
(SID_NAME = ctsdb)
)
)
LISTENER_DG =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST =
)
# TNSNAMES.ORA Network Configuration File: /export/home/oracle/app/oracle/product/
network/admin/tnsnames.ora
# Generated by Oracle configuration tools.
CTSDB.STANDBY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST =
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID = ctsdb)
)
)
CTSDB.PRIMARY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST =
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID = ctsdb)
)
)
12。设置Standby的SQLNET.ORA文件
添加SQLNET.EXPIRE_TIME=2，该配置表示在Standby由于故障不可用时，Primary将持续检测2分钟，如果仍然不可用，则返回网络连接错误。
13。创建Standby的spfile
CREATE SPFILE FROM PFILE='/tmp/initctsdb.ora';
14。启动Standby
STARTUP NOMOUNT;
ALTER DATABASE
如果要使用LGWR进程传递redo数据，那么需要添加standby redolog，如果使用ARCH进程传递redo数据，那么这步可以省略
alter database add standby logfile group 4
('/global/oradata/ctsdb/stdby_redo04.log') size 1024K;
alter database add standby logfile group 5
('/global/oradata/ctsdb/stdby_redo05.log') size 1024K;
alter database add standby logfile group 6
('/global/oradata/ctsdb/stdby_redo06.log') size 1024K;
alter database add standby logfile group 7
('/global/oradata/ctsdb/stdby_redo07.log') size 1024K;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL
<CPU*2> DISCONNECT FROM SESSION;
为了防止以后primary和standby切换，可以在primary上也建立相应的standby redolog
15。设置Primary的归档地址
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=CTSDB.STANDBY LGWR' SCOPE=BOTH;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;
16。测试Primary的归档能否应用到Standby
ALTER SYSTEM ARCHIVE LOG CURRENT;
17。停止Standby
alter database recover managed standby database cancel;
shutdown immediate;
18。切换到只读模式
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE OPEN READ ONLY;
19。切换回管理恢复模式
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL 8 DISCONNECT FROM SESSION;
以上为MAX PERFORMANCE模式的DataGuard
如果要改为MAX AVAILABILITY，进行如下操作：
检查当前Primary库的保护模式
select protection_mode from v$database;
转换数据库模式为MAX AVAILABILITY：
shutdown immediate;
startup mount;
alter database set standby database to maximize availability;
alter database open;
如果要强制Primary一分种归档一次，那么设置Primary的初始化参数ARCHIVE_LAG_TARGET：
alter system set ARCHIVE_LAG_TARGET=60 scope=both;
如果想要自动在Standby上应用Primary中创建数据文件等操作，需要在Standby上设置：
alter system set STANDBY_FILE_MANAGEMENT=AUTO scope=both;
使用RMAN进行DataGuard环境的快速配置总结：
1． 预先设置好Standby上所需的参数文件和路径, 修改standby的fal_server和fal_client参数
2． 作Primay的联机RMAN备份
3． 启动Primay，随时都可以生成standby control file
4． 在Standby端，用生成的standby control file， mount database
5． 在Standby端，RMAN中作restore databse
6． 设置standby到RECOVER MANAGED状态
Pirmay和Standby之间作switchover，此时Primary和Standby均为正常状态，并且网络正常。
Primary：
SELECT SWITCHOVER_STATUS FROM V$DATABASE;
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
SHUTDOWN IMMEDIATE;
STARTUP NOMOUNT;
ALTER DATABASE
Standby：
SELECT SWITCHOVER_STATUS FROM V$DATABASE;
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
SHUTDOWN;
STARTUP;
Primay：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Standby Failover到Primary，此时由于故障Primary宕机或者网络不通
以下命令均在Standby端执行
1．如果是使用ARCH传递redo数据，那么执行以下命令：
检查是否有gap archive
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
如果有则register
ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
实行Failover：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE ACTIVATE STANDBY DATABASE;
ALTER DATABASE MOUNT;
ALTER DATABASE OPEN;
2．如果是使用LGWR传递redo数据，那么执行以下命令：
检查是否有gap archive
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
如果有则register
ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
如果是由于网络问题而导致需要切换，那么通常standby端的RFS进程并不会意识到primary已经不可访问，所以RFS进程也不会释放当前的standby redo log文件。
如果是primary端的数据库实例由于故障中断，那么一般情况下standby端的RFS进程会立刻意识到primary已经不可访问，也就会立刻释放当前的standby redo log文件。
只要RFS进程没有释放standby redo log文件，那么执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH命令就会在alertlog文件中发现如下的报错信息
Warning: log 4 of thread 1 is being archived or modified
Recovery interrupted.
Media Recovery failed with error 261
如果在报上述错误的时候，执行SWITCH，那么将会出现下面的错误：
ORA-16139: media recovery required
所以必须检查alertlog文件，直到发现如下信息才表示RFS进程已经释放了standby redo log文件，这时候才可以作FINISH：
RFS: Possible network disconnect with primary database
促使RFS进程释放standby redo log 文件有两种方法：
1． 等待RFS进程的network timeout，通常需要等待8分钟左右
2． 关闭standby数据库，再重新开启，这样会强制RFS进程释放standby redo log
我们可以通过v$managed_standby视图来监控RFS进程何时释放
实行Failover：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
alertlog中将显示如下信息，表示finish成功：
Terminal Incomplete Recovery: UNTIL CHANGE 3738452
Terminal Incomplete Recovery: End-Of-Redo log allocation
Terminal Incomplete Recovery: log 4 reserved for thread 1 seq# 8772
TERMINAL RECOVERY changing datafile format version from
Switching logfile format version from
Terminal Incomplete Recovery: clearing standby redo logs.
Terminal Incomplete Recovery: thread 1 seq# 8772 redo required
Terminal Incomplete Recovery: End-Of-Redo log /global/oradata/ctsdb/stdby_redo04.log
Identified end-of-REDO for thread 1 sequence 8772
Terminal Incomplete Recovery: end checkpoint SCN 3738453
Media Recovery Complete
Switching logfile format version from
Terminal Incomplete Recovery: successful completion
Begin: Wait for standby logfiles to be archived
Wed Sep 1 13:42:28 2004
ARC1: Evaluating archive log 4 thread 1 sequence 8772
Wed Sep 1 13:42:28 2004
ARC0: Evaluating archive log 4 thread 1 sequence 8772
Wed Sep 1 13:42:28 2004
ARC1: Beginning to archive log 4 thread 1 sequence 8772
Wed Sep 1 13:42:28 2004
ARC0: Unable to archive log 4 thread 1 sequence 8772
Wed Sep 1 13:42:28 2004
Creating archive destination LOG_ARCHIVE_DEST_1: '/global/oradata/ctsdb/archive/arch1_8772.log'
Wed Sep 1 13:42:28 2004
Log actively being archived by another process
Wed Sep 1 13:42:28 2004
ARC1: Completed archiving log 4 thread 1 sequence 8772
Wed Sep 1 13:42:43 2004
End: All standby logfiles have been archived
Resetting standby activation ID 4038461969 (0xf0b
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH
FINSH成功之后再执行SWITCH：
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
SWITCH成功之后，重新启动数据库：
SHUTDOWN IMMEDIATE;
STARTUP;
使用Data Guard Broker
创建Management Server repository：
emca
启动Management Server：
oemctl start oms
检查Management Server状态：
oemctl status oms sysman/oem_temp@bftest
启动Intelligent Agent：
agentctl start agent
如果启动agent报错，则检查相应的log文件，如果log文件中有如下错误：
Failed while initializing user subsystem
Error initializing subsystems
nmiumini_initializeUM: Unable to initialize UQAgent
则进行如下操作之后，重新启动agent：
rm $ORACLE_HOME/network/agent/*.q
alter system set resource_manager_plan='SYSTEM_PLAN' scope=both;
在所有站点上将BROKER启动。
SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE SCOPE=BOTH;
System altered.
SQL> SHOW PARAMETER DG_BROKER_START
NAME TYPE VALUE
------------------------------------
dg_broker_start boolean TRUE
连接Data Guard Manager，必须使用具有sysdba权限的用户连接到Primary库上
>dgmgrl
DGMGRL> connect sys/dba
创建配置方案
DGMGRL> CREATE CONFIGURATION 'cts' AS
PRIMARY SITE IS 'bftest'
RESOURCE IS 'ctsdb'
HOSTNAME IS 'bftest'
INSTANCE NAME IS 'ctsdb'
SERVICE NAME IS 'ctsdb.primary'
SITE IS MAINTAINED AS PHYSICAL;
创建备用站点方案
DGMGRL> CREATE SITE 'report'
RESOURCE IS 'ctsdb'
HOSTNAME IS 'report'
INSTANCE NAME IS 'ctsdb'
SERVICE NAME IS 'ctsdb.standby'
SITE IS MAINTAINED AS PHYSICAL;
激活配置方案
DGMGRL> ENABLE CONFIGURATION;
激活资源
DGMGRL> ENABLE RESOURCE 'ctsdb';
资源的日志传送模式必须和Primary库的数据保护模式相匹配，比如数据保护模式是maximize availability，那么需要配置资源的LogXptMode属性为SYNC方式。
DGMGRL>ALTER RESOURCE 'ctsdb' ON SITE '
DGMGRL>ALTER RESOURCE 'report_db' ON SITE '
DGMGRL> ALTER CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
查看资源情况
DGMGRL> show resource verbose 'ctsdb';
查看某个节点上资源中的某一属性
DGMGRL> show resource verbose 'ctsdb' 'LogXptMode' on site '
DGMGRL> SHOW RESOURCE 'ctsdb' LogXptStatus;
查看Broker的日志
DGMGRL> show log latest on site '
查看数据库告警日志
DGMGRL> show log alert latest on site '
查看资源的各种属性
DGMGRL> SHOW RESOURCE 'ctsdb' SendQEntries;
DGMGRL> SHOW RESOURCE 'report_db' SbyLogQueue;
DGMGRL> show resource verbose 'ctsdb' InconsistentLogXptProps;
修改资源属性，将自动修改数据库的相应初始化参数
DGMGRL> ALTER RESOURCE product_db on site v280 SET PROPERTY StandbyArchiveDest = '/global/oradata/ctsdb/archive';
Property "standbyarchivedest" updated.
DGMGRL> ALTER RESOURCE product_db on site v280 SET PROPERTY StandbyFileManagement = 'AUTO';
Property "standbyfilemanagement" updated.
DGMGRL> ALTER RESOURCE product_db on site v280 SET PROPERTY ArchiveLagTarget = '3600';
Property "archivelagtarget" updated.
停止Data Guard环境中的某个节点
DGMGRL> ALTER RESOURCE 'report_db' ON SITE '
启动Data Guard环境中的某个节点
DGMGRL> ALTER RESOURCE 'report_db' ON SITE '
修改 Data Guard环境中的某个节点的状态
DGMGRL> ALTER RESOURCE 'report_db' ON SITE 'v480'
先停止连接到备用库上的所有连接
DGMGRL> ALTER RESOURCE 'report_db' ON SITE 'v480'
停止Broker
SQL> ALTER SYSTEM SET DG_BROKER_START=FALSE;
作Switchover
DGMGRL> SWITCHOVER TO 'v480';
然后关闭Pirmary和Standby，重新启动
七．在Cluster环境中的主备切换步骤
在应用中cluster环境是很常见的，下面简单介绍一下在Sun Cluster 3.0的环境中，如果作Data Guard主备数据库的Switchover工作。
1．由于Cluster环境的监控，我们要手动关闭数据库的话，必须先关闭cluster，单独起一个节点的oracle。其中listener.ora.sigle的配置文件是预先写好的监听配置，主要不同是用主机的真实IP替换原先Cluster环境中的虚拟IP。
/usr/cluster/bin/scswitch -F -g oracle-rg
mount /global/oradata
cd /export/home/oracle/app/oracle/product/
cp listener.ora.sigle listener.ora
lsnrctl start
lsnrctl start listener_dg
sqlplus “/ as sysdba”
startup
2．在SQL*Plus中依次进行以下操作，完成切换Primary和Standby的工作
主数据库端：
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
SHUTDOWN IMMEDIATE;
STARTUP NOMOUNT;
ALTER DATABASE
备用数据库端：
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
SHUTDOWN IMMEDIATE;
STARTUP;
主数据库端：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
八．参考文档
Oracle Data Guard Concepts and Administration Release 2 (9.2)
Oracle9i Data Guard Broker Release 2 (9.2)
