聊聊Data Guard中的DG Broker

    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.

这句话需要好好品味。

假设数据库主库的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,很容易会出现误导,我就因为这个方面大意,结果一个备库丢失了好久的归档,所幸最后及时发现,用跳归档的方式恢复回来了备库,免去了重搭备库的烦恼。

时间: 2024-10-23 18:08:49

聊聊Data Guard中的DG Broker的相关文章

Data Guard中快速Switchover,Failover的一些建议

其实对于Failover和Switchover是大家处理灾难时很头疼的一个环节,也是最关键的处理过程. 假设你半夜正在睡觉,被报警电话惊醒,得知某个服务器产生了故障宕机,在这种情况下,我们大体会有下面的处理流程: 1)检查原来的节点是否可用,需要查看ILO和存储,是否存在异常 2)如果原来的节点可以重启,可以尽量马上恢复业务,然后分析根本原因,是否是硬件老化,硬件故障导致,如果发现问题影响较大,可以使用Switchover 3)如果原来的节点无法重启,这个时候需要考虑Failover,如果在同机

ZT:Data Guard中rename a datafile的步骤小计

http://grassbell.itpub.net/post/26/18902 补充一点: 改名之前在standby上先执行 ALTER SYSTEM SET standby_file_management='MANUAL' SCOPE=BOTH;. 需要注意的是:如果你想让primary 和standby 上的数据文件结构保持一致的话,在primary 上rename a datafile后,即使STANDBY_FILE_MANAGEMENT = auto,也需要在standby上手工执行相

从摆脱Data Guard手工搭建及维护的烦恼说起

讲师介绍  杨建荣 搜狐畅游高级DBA   DBAplus社群联合发起人.现就职于搜狐畅游,Oracle ACE-A.YEP成员,超7年数据库开发和运维经验,擅长电信数据业务.数据库迁移和性能调优. 持Oracle 10G OCP,OCM,MySQL OCP认证,<Oracle DBA工作笔记>作者.   本次分享将分为以下几部分: 半自动化搭建Data Guard 用不用DG Broker 几个实用场景演练 与时俱进:Oracle 12c Data Guard改进 诊断案例:备库批量查询失败

搜狐畅游高级DBA:Data Guard运维中的实战经验和技巧

本次分享由以下几个部分组成: Data Guard的灾备介绍 备库的设计方案考虑 备库敏感的几个数据文件类操作 对Switchover和Failover的建议 SQL审核之Snapshot Standby Data Guard搭建/重建的小技巧   写在前面 之前有一个朋友很有深意的问我Data Guard和RAC哪个更重要,前提是在高可用和容灾两者之间来选择,只能选其一,我是毫不犹豫选择Data Guard,毕竟这是数据安全的基本防线,我想Data Guard的命名(中文翻译为数据卫士)也是这

Oracle DG(Data Guard)支持异构平台说明

Oracle DG(Data Guard)支持异构平台说明  以下转自:http://blog.csdn.net/tianlesoftware/article/details/7241488 一.说明 OracleData Guard 最简单的配置是主备库的环境都一样,但是在有些情况下需要异构的配置,比如在迁移时为了减少停机时间或者零停机,可能就需要使用异构的DG 配置. 关于Oralce DataGuard 异构平台的搭建,MOS上有2篇文章专门来说明: Data Guard Support

Oracle Data Guard延迟的几个可能(r11笔记第69天)

     Oracle Data Guard中很可能出现延迟的情况,而数据一旦出现延迟就意味着丢数据.退一步来说丢数据总比数据乱了好,但是回过头来,能不丢数据但是丢了,这就有些说不过去了.     因为预防人为误操作等,可能有些环境中会特意设置一个延迟,基本就是下面的设置方法: 方法1: alter database recover managed standby database delay 120 disconnect from session;方法2: alter system set l

DG7——物理Data Guard 下Failover 时Redo 的处理问题

原文转自:http://blog.csdn.net/tianlesoftware/article/details/5989638 和老大讨论了一下Oracle Data Guard 下redo 的问题. 在Data Guard 环境下,归档文件是可以在备库应用的. 假如主库直接crash后,无法登陆,这时在将备库切换为主库的时候,如何处理主库的redo 就是关键. 因为这里的数据就是可能丢失的数据.   所以做了一个实验验证,验证redo 的处理.即将主库的redo 直接copy到备库,然后通过

基于同一主机配置 Oracle 11g Data Guard

       Oracle Data Guard 为企业数据库提供了最有效和最全面的数据可用性.数据保护和灾难恢复解决方案.它集成管理.监视和自动化软件基础架构来创建和维护一个或多个同步备用数据库,从而保护数据不受故障.灾难.错误和损坏的影响.本文主要描述了在同一主机下如何配置Oracle Data Guard.               有关DG的相关概念,可参考:Oracle Data Guard Concepts and Administration        有关配置DG的参数描述

Oracle Data Guard 理论知识

Oracle Data Guard 理论知识   来源:Linux社区 作者:tianlesoftware       RAC,Data Gurad,Stream是Oracle高可用性体系中的三种工具,每个工具即可以独立应用,也可以相互配合.他们各自的侧重点不同,适用场景也不同.   RAC它的强项在于解决单点故障和负载均衡,因此RAC方案常用于7*24的核心系统,但RAC方案中的数据只有一份,尽管可以通过RAID等机制可以避免存储故障,但是数据本身是没有冗余的,容易形成单点故障.   Data