系统环境：
操作系统： RedHat EL55_64
Oracle: Oracle 11.2.0.3.0
Data Guard 配置：
主库bjdb：
02:21:10 SYS@ TestDB12>select name,dbid,database_role,protection_mode from v$database;
NAME DBID DATABASE_ROLE PROTECTION_MODE
--------- ---------- ---------------- --------------------
TESTDB12 2811829300 PRIMARY MAXIMUM AVAILABILITY
Elapsed: 00:00:00.00
02:21:42 SYS@ TestDB12>
备库shdb：
02:21:18 SYS@ shdb>select name,dbid,database_role,protection_mode from v$database;
NAME DBID DATABASE_ROLE PROTECTION_MODE
--------- ---------- ---------------- --------------------
TESTDB12 2811829300 PHYSICAL STANDBY MAXIMUM AVAILABILITY
Elapsed: 00:00:00.01
DG Broker架构：
Data Guard broker概览
Data Guard broker是建立在Data Guard基础上的一个对Data Guard配置，集中管理操作的一个平台，因此在学习Data Guard broker之前必须对Data Guard要有充分的了解。
Data Guard为我们提供了一套高可用的解决方案，但是在实际的使用方面确实显得有一些过于复杂，特别是在需要配置的standby机器多的时候更是如此，一个个机器去登陆配置显得特别的麻烦；在需要做switchover或者是failover的时候情况也是一样，需要操作一系列的命令才能完成一次switchover/failover的操作。Data Guard broker的推出就是为了简化DG复杂的管理过程的，它最大的作用就是集中化的统一管理，下面列出来一些Data Guard broker优势所在：
| 使用broker | 不使用broker | |
|---|---|---|
| 一般 | 将primary数据库与全部standby数据库看成一个整体进行管理 | 必须对primary数据库和各个standby进行单独的操作。 |
| 创建standby | 通过使用OEM可以轻松的建立一个新的standby | 所有操作必须手工进行：拷贝数据/控制/日志文件，设置初始化参数等等 |
| 配置和管理 | 可以在一个地方对所有的数据库进行统一的配置和管理，这些配置会被自动同步到各个数据库中 | 必须手工的进行配置，然后对Primary和standby进行单独的管理 |
| 控制 | - 使用一个简单的命令进行failover和switchover的操作 - 通过配置可以自动的进行failover操作 |
- 必须使用多个SQLPLUS才能完成对数据库的管理 |
| 监控 | - 自动持续对数据库配置，数据库状态以及其他参数进行自动管理 - 提供详细的数据库状态报告 - 和OEM Events集成 |
- 没有统一的视图进行管理，只能通过Fixed View一个个进行查看 – 自定义OEM Events管理 |
broker的组成主要分成两大部分，分别是：
- 客户端组件
- 客户端组件是一个管理员与broker服务器端组件的接口，用户通过客户端来发出命令对服务器端的行为进行控制。客户端组件由OEM和DGMGRL两个组成
OEM（Oracle Enterprise Manager）：图形化的Oracle管理工具，提供了多个向导功能方便DG的管理工作。
DGMGRL（Data Guard command-line interface）： 命令行管理界面，可以通过命令很方便的操作以及监控数据库，命令列表见文档。
- 服务器端组件
- 在每个配置了broker的数据库上面都存在一个服务器进程进行broker的管理操作，这个服务器进程就是Data Guard broker monitor（DMON），而这个DMON所用到的所有配置信息都会保留在一个配置文件中。这个DMON进程和配置文件就构成了每个数据库上broker的服务器端组件。
Data guard broker monitor process（DMON）：DMON是一个用来管理broker的后台进程，这个进程负责与本地数据库以及远程数据库的DMON进程进行通讯（与远端数据库的DMON进程进行通讯的时候使用的是一个 动态注册 的service name “db_unique_name_DGB.db_domain”）。这个进程负责维护配置文件的正确性以及不同数据库之间配置文件的一致性。在第一次创建一个broker配置文件或者是将一个数据库加入一个现存的broker配置中的时候DMON会先收集现有数据库的DG配置信息并保存到配置文件中。
配置文件：配置文件有DMON进行操作，它保存了broker管理的所有的数据库的状态信息，以及数据库相关属性（即数据库的初始化参数信息）的信息。同一个broker配置管理下的每个数据库上面都有一份相同的配置文件。
Broker的配置管理
Broker通过将DG环境划分成数据库配置和数据库这两种对象来简化DG的管理工作。
数据库配置对象：数据库配置是一个包含多个数据库信息的集合，这些数据库信息包括数据库对象当前的形态、状态、及属性设置。同时这个集合可以同时混合了物理standby和逻辑standby。
数据库对象：数据库对象指的是Primary和standby数据库。一般情况下一个数据库对象只包含一个实例，但是在RAC系统中一个数据库对象会包含多个实例。
broker通过将一个DG中的Primary数据库及所有的standby数据库逻辑的组成一个逻辑组来进行集中管理，因此每个broker配置就是一个数据库的逻辑集合，它包含了组成数据库的日志传输服务、日志应用服务等逻辑的对象。DBA可以broker来控制这个逻辑集合的配置，改变它的配置，同时还能监控这个组的整体健康状态。
DMON进程负责设置和维护broker配置，有了DMON的维护之后在实际管理中我们只需要把一个broker配置当初单个的单元管理就行了，剩下的工作由DMON去做，因此当执行一个影响到多个数据库的命令的时候，DMON实际上会进行下面的操作：
在Primary数据库上处理请求。
协调其他相关数据库上的DMON进程处理相应的请求。
更新本地系统中的配置文件。
与其他数据库上的DMON进程通讯以更新各自的配置文件。
每组配置文件中可以包含多个broker配置，但是每个数据库只会维护一组配置文件，因此在RAC环境中，配置文件是由组成这个RAC的各个instance共享的。DMON进程负责各个数据库之间配置文件的同步工作。
DMON进程通过配置文件中设定的数据库的参数来控制数据库的行为，这些属性通常都和数据库的某个DG相关的初始化参数相关联，在通过OEM或DGMGRL修改这些属性的时候，这些属性记录会先保存在配置文件中，然后DMON进程同时也会对相关数据库的参数进行修改，这就要求我们在配置数据库的时候必须使用SPFILE，保证DMON修改之后的参数能保留下来。
