聊聊Data Guard中的DG Broker

2016-09-16 1267

版权

版权声明：

本文内容由阿里云实名注册用户自发贡献，欧博abg版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介：     DG Broker是Oracle为Data Guard维护提供的一个很不错的工具，从我的实际使用来看，早期的版本中似乎大家都还是存在一定的思维定式，认为手工维护已经足够了。

    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)))
还有一句额外的补充，

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.