DG Broker是Oracle为Data Guard维护提供的一个很不错的工具，从我的实际使用来看，早期的版本中似乎大家都还是存在一定的思维定式，认为手工维护已经足够了。这个工具就不那么需要了，我们完全可以脱离开这些工具来直观的使用命令行的方式来维护，这个观点也没错，不过从与时俱进的角度来看，本来能够让你更轻松的一个工具，如果不用实在是太可惜了。
DG Broker在数据库端需要启用一个后台进程dmon来维护，这个后台进程启动，需要设置dg_broker_start为true即可，如果要停止，只需要设置这个参数为false即可。如果从系统资源的角度来考虑，那几乎可以忽略不计，如果从搭建的便捷性上来看，Data Guard的搭建有了DG Broker已经几乎没有了技术含量。当然DG Broker毕竟只是一个工具而已，我们得确信能够拿得下手头的活儿，然后借助这个工具的福利来给我们的运维工作带来福利，如果不懂Data Guard的基本原理，不熟悉手工维护，那么还是先把那个坑踩平了再来玩这个工具。工具永远就是一个媒介。好与不好，明心自鉴，过度依赖工具与完全脱离工具，都是两个不可取的极端。
switchover的操作需要在主备库端进行不少的验证检查，在DG Broker里面只有一个简单的命令switchover to xx。
当然DG Broker需要开启，有几个基本条件，要求一点也不过分
首先是设置spfile
然后是需要设置local_listener
好像其他的硬性要求也没有了。
首先我们来看看基本的配置。
configuration是DG Broker的一个基础设置，在配置上可以添加主备库关系。使用dgmgrl 这个命令即可。
这个配置在$ORACLE_HOME/dbs下会有两个dr开头的文件，在数据库参数中也会看到dg_broker_config_file1和dg_broker_config_file2
这两个配置文件互为镜像，和控制文件的表现差不多。主备库的配置信息是统一通过这类文件来维护的。
这个文件的生成不需要我们特意去控制，启用了配置之后，会自动生成。
创建配置的语句如下，建议是按照db_unique_name的方式来命名会统一一些。
create configuration dg_testdb as
primary database is testdb
connect identifier is testdb;
在经过大量的实践之后，个人是推荐添加主库之后，马上enable configuration保证主库的配置正确，可用。然后再添加其他的数据库。
DGMGRL> show configuration;
Configuration - dg_newtest2
Protection Mode: MaxPerformance
Databases:
newtest2 - Primary database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
此时的配置就会是这样的形式，小步快进，我们在这个基础上添加相应的备库信息即可。
比如添加备库stestdb,使用如下的语句即可。
add database stestdb as
connect identifier is stestdb
maintained as physical;
配置完毕，只需要enable database stestdb即可。当然Data Guard的搭建过程中，最关键的一步就是enable database stestdb这一步了，因为这一步会完成如下的几个工作，
在备库创建dg broker config files,几次握手通信之后会生成两个配置文件，然后DG Broker会在后台调用我们手工配置DG的几个命令，当然从后台的日志来看，这个工作还算是蛮智能的了。
配置完成之后，一个标准的输出就是下面的形式了。
DGMGRL> show configuration;
Configuration - dg_testdb
Protection Mode: MaxPerformance
Databases:
testdb - Primary database
stestdb - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
我们来评估一个数据库的灾备环境是否达标，一个基准就是查看DG Broker的show configuration的结果，必须是SUCCESS,WARNING也不行，Error完全不可接受。
如果是查看主备库的延迟情况，可以使用show database verbose xxxx的方式来查看。延迟情况，网络情况尽收眼底。
来看看DG Broker的一个特色功能 switchover,一个命令即可搞定切换，这个确实是很方便。
当然如果需要达到这种效果，还是有一些额外的配置。
就是在listener.ora中需要配置一个service
比如主库的配置如下:
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = testdb.oracle.com)(PORT = 1521))
)
)
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = testdb)
(ORACLE_HOME = /U01/app/oracle/product/11.2.0.4)
(SID_NAME = testdb)
)
(SID_DESC =
(GLOBAL_DBNAME = testdb _dgmgrl)
(ORACLE_HOME = /U01/app/oracle/product/11.2.0.4)
(SID_NAME = testdb)
)
）
备库的service就是stestdb_dgmgrl了。
其实如果查看service情况，会发现后台会自动注册一个testdb_DGB的服务，不过我们还是按照官方的建议来做。
官方的样例如下：
LISTENER = (DESCRIPTION = (ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST= host_name) (PORT= port_num)))) SID_LIST_LISTENER=(SID_LIST=(SID_DESC=(SID_NAME= sid_name) ( GLOBAL_DBNAME= db_unique_name _DGMGRL. db_domain) (ORACLE_HOME= oracle_home)))
还有一句额外的补充，
假设数据库主库的db_unique_name为testdb,备库为stestdb
则切换的过程如下，我们可以自如的切换过去，再切换回来。
dgmgrl sys/xxx@testdb
DGMGRL> show configuration;
Configuration - dg_testdb
Protection Mode: MaxPerformance
Databases:
testdb - Primary database
stestdb - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
DGMGRL> switchover to stestdb; --切换过去
Performing switchover NOW, please wait...
Operation requires a connection to instance "testdb" on database "stestdb"
Connecting to instance "testdb"...
Connected.
New primary database "stestdb" is opening...
Operation requires startup of instance "testdb" on database "testdb"
Starting instance "testdb"...
ORACLE instance started.
Database mounted.
Database opened.
Switchover succeeded, new primary is "stestdb"
DGMGRL> switchover to testdb; --再切换回来
Performing switchover NOW, please wait...
Operation requires a connection to instance "testdb" on database "testdb"
Connecting to instance "testdb"...
Connected.
New primary database "testdb" is opening...
Operation requires startup of instance "testdb" on database "stestdb"
Starting instance "testdb"...
ORACLE instance started.
Database mounted.
Database opened.
Switchover succeeded, new primary is "testdb"
DGMGRL>
当然需要注意第一句， dgmgrl sys/xxx@testdb
我们得使用这种连接方式完成switchover，如果dgmgrl / 的方式，肯定会收到一个老套的错误。
dgmgrl /
DGMGRL> switchover to testdb;
Performing switchover NOW, please wait...
New primary database "testdb" is opening...
Operation requires startup of instance "testdb" on database "stestdb"
Starting instance "testdb"...
Unable to connect to database
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
Failed.
Warning: You are no longer connected to ORACLE.
Please complete the following steps to finish switchover:
start up instance "testdb" of database "stestdb"
如果出现这种情况，也别担心，这是需要我们手工启动一下备库即可。
Failover的操作其实是不建议使用show configuration的，因为本身主库已经不可用了，在10g中的反应会慢得多。直接failover to xxx就可以了。
如果一个DG环境很久没有再改动过配置，建议还是删除配置，重新配置一下，因为当时的配置可能验证成功，但是后期可能有些地方已经出现了小问题，DG Broker还是会使用之前的配置信息来检查。
10g版本中的DG Broker我还是颇有微词，备库在READ ONLY状态照样检查结果是SUCCESS,很容易会出现误导，我就因为这个方面大意，结果一个备库丢失了好久的归档，所幸最后及时发现，用跳归档的方式恢复回来了备库，免去了重搭备库的烦恼。
DG Broker在数据库端需要启用一个后台进程dmon来维护，这个后台进程启动，需要设置dg_broker_start为true即可，如果要停止，只需要设置这个参数为false即可。如果从系统资源的角度来考虑，那几乎可以忽略不计，如果从搭建的便捷性上来看，Data Guard的搭建有了DG Broker已经几乎没有了技术含量。当然DG Broker毕竟只是一个工具而已，我们得确信能够拿得下手头的活儿，然后借助这个工具的福利来给我们的运维工作带来福利，如果不懂Data Guard的基本原理，不熟悉手工维护，那么还是先把那个坑踩平了再来玩这个工具。工具永远就是一个媒介。好与不好，明心自鉴，过度依赖工具与完全脱离工具，都是两个不可取的极端。
switchover的操作需要在主备库端进行不少的验证检查，在DG Broker里面只有一个简单的命令switchover to xx。
当然DG Broker需要开启，有几个基本条件，要求一点也不过分
首先是设置spfile
然后是需要设置local_listener
好像其他的硬性要求也没有了。
首先我们来看看基本的配置。
configuration是DG Broker的一个基础设置，在配置上可以添加主备库关系。使用dgmgrl 这个命令即可。
这个配置在$ORACLE_HOME/dbs下会有两个dr开头的文件，在数据库参数中也会看到dg_broker_config_file1和dg_broker_config_file2
这两个配置文件互为镜像，和控制文件的表现差不多。主备库的配置信息是统一通过这类文件来维护的。
这个文件的生成不需要我们特意去控制，启用了配置之后，会自动生成。
创建配置的语句如下，建议是按照db_unique_name的方式来命名会统一一些。
create configuration dg_testdb as
primary database is testdb
connect identifier is testdb;
在经过大量的实践之后，个人是推荐添加主库之后，马上enable configuration保证主库的配置正确，可用。然后再添加其他的数据库。
DGMGRL> show configuration;
Configuration - dg_newtest2
Protection Mode: MaxPerformance
Databases:
newtest2 - Primary database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
此时的配置就会是这样的形式，小步快进，我们在这个基础上添加相应的备库信息即可。
比如添加备库stestdb,使用如下的语句即可。
add database stestdb as
connect identifier is stestdb
maintained as physical;
配置完毕，只需要enable database stestdb即可。当然Data Guard的搭建过程中，最关键的一步就是enable database stestdb这一步了，因为这一步会完成如下的几个工作，
在备库创建dg broker config files,几次握手通信之后会生成两个配置文件，然后DG Broker会在后台调用我们手工配置DG的几个命令，当然从后台的日志来看，这个工作还算是蛮智能的了。
配置完成之后，一个标准的输出就是下面的形式了。
DGMGRL> show configuration;
Configuration - dg_testdb
Protection Mode: MaxPerformance
Databases:
testdb - Primary database
stestdb - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
我们来评估一个数据库的灾备环境是否达标，一个基准就是查看DG Broker的show configuration的结果，必须是SUCCESS,WARNING也不行，Error完全不可接受。
如果是查看主备库的延迟情况，可以使用show database verbose xxxx的方式来查看。延迟情况，网络情况尽收眼底。
来看看DG Broker的一个特色功能 switchover,一个命令即可搞定切换，这个确实是很方便。
当然如果需要达到这种效果，还是有一些额外的配置。
就是在listener.ora中需要配置一个service
比如主库的配置如下:
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = testdb.oracle.com)(PORT = 1521))
)
)
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = testdb)
(ORACLE_HOME = /U01/app/oracle/product/11.2.0.4)
(SID_NAME = testdb)
)
(SID_DESC =
(GLOBAL_DBNAME = testdb _dgmgrl)
(ORACLE_HOME = /U01/app/oracle/product/11.2.0.4)
(SID_NAME = testdb)
)
）
备库的service就是stestdb_dgmgrl了。
其实如果查看service情况，会发现后台会自动注册一个testdb_DGB的服务，不过我们还是按照官方的建议来做。
官方的样例如下：
LISTENER = (DESCRIPTION = (ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST= host_name) (PORT= port_num)))) SID_LIST_LISTENER=(SID_LIST=(SID_DESC=(SID_NAME= sid_name) ( GLOBAL_DBNAME= db_unique_name _DGMGRL. db_domain) (ORACLE_HOME= oracle_home)))
还有一句额外的补充，
Alternatively, you can use a different static service name. If you do, be sure to modify the StaticConnectIdentifier instance-specific property to reflect the different service name.
这句话需要好好品味。假设数据库主库的db_unique_name为testdb,备库为stestdb
则切换的过程如下，我们可以自如的切换过去，再切换回来。
dgmgrl sys/xxx@testdb
DGMGRL> show configuration;
Configuration - dg_testdb
Protection Mode: MaxPerformance
Databases:
testdb - Primary database
stestdb - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
DGMGRL> switchover to stestdb; --切换过去
Performing switchover NOW, please wait...
Operation requires a connection to instance "testdb" on database "stestdb"
Connecting to instance "testdb"...
Connected.
New primary database "stestdb" is opening...
Operation requires startup of instance "testdb" on database "testdb"
Starting instance "testdb"...
ORACLE instance started.
Database mounted.
Database opened.
Switchover succeeded, new primary is "stestdb"
DGMGRL> switchover to testdb; --再切换回来
Performing switchover NOW, please wait...
Operation requires a connection to instance "testdb" on database "testdb"
Connecting to instance "testdb"...
Connected.
New primary database "testdb" is opening...
Operation requires startup of instance "testdb" on database "stestdb"
Starting instance "testdb"...
ORACLE instance started.
Database mounted.
Database opened.
Switchover succeeded, new primary is "testdb"
DGMGRL>
当然需要注意第一句， dgmgrl sys/xxx@testdb
我们得使用这种连接方式完成switchover，如果dgmgrl / 的方式，肯定会收到一个老套的错误。
dgmgrl /
DGMGRL> switchover to testdb;
Performing switchover NOW, please wait...
New primary database "testdb" is opening...
Operation requires startup of instance "testdb" on database "stestdb"
Starting instance "testdb"...
Unable to connect to database
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
Failed.
Warning: You are no longer connected to ORACLE.
Please complete the following steps to finish switchover:
start up instance "testdb" of database "stestdb"
如果出现这种情况，也别担心，这是需要我们手工启动一下备库即可。
Failover的操作其实是不建议使用show configuration的，因为本身主库已经不可用了，在10g中的反应会慢得多。直接failover to xxx就可以了。
如果一个DG环境很久没有再改动过配置，建议还是删除配置，重新配置一下，因为当时的配置可能验证成功，但是后期可能有些地方已经出现了小问题，DG Broker还是会使用之前的配置信息来检查。
10g版本中的DG Broker我还是颇有微词，备库在READ ONLY状态照样检查结果是SUCCESS,很容易会出现误导，我就因为这个方面大意，结果一个备库丢失了好久的归档，所幸最后及时发现，用跳归档的方式恢复回来了备库，免去了重搭备库的烦恼。
