Oracle RAC 11g DG Broker配置和测试 本篇在实验环境中实际配置 环境： RHEL 6.5 + Oracle 11.2.0.4 GI、DB + Primary RAC（2 nodes）+ Standby RAC（2 nodes）
DG Broker是Oracle为Data Guard维护提供的一个很不错的工具，从我的实际使用来看，早期的版本中似乎大家都还是存在一定的思维定式，认为手工维护已经足够了。这个工具就不那么需要了，我们完全可以脱离开这些工具来直观的使用命令行的方式来维护，这个观点也没错，不过从与时俱进的角度来看，本来能够让你更轻松的一个工具，如果不用实在是太可惜了。 DG Broker在数据库端需要启用一个后台进程dmon来维护，这个后台进程启动，需要设置dg_broker_start为true即可，如果要停止，只需
首先，DG（Data Guard，数据卫士）不是一个备份恢复的工具，然而，DG却拥有备份的功能，在物理DG下它可以和主库一模一样，但是它存在的目的并不仅仅是为了备份恢复数据，应该说它的存在是为了确保企业数据的高可用性，数据保护以及灾难恢复。DBA可以通过将一些操作（例如查询报表）转移到备库执行的方式来减小主库的压力，构建高可用的企业数据库应用环境。
通常情况下习惯使用sqlplus命令对数据库primary以及dataguard进行switchover、failover.虽然oracle很早在10g时候就推出dg broker命令行进行快速切换，由dgmgrl对数据库状态检查、延迟检查、是否可以切换进行封装命令输出，所以可以很快捷简单检查整个主从配置和切换，个人觉得dg broker报错排除之类不是太友好，,另外dataguard切换2条命令，dgmgrl封装成一条命令，整体切换相对简单，使用dgmgrl需要配置静态监听、standby log、延迟等要求比较多，另外broker可以配合em操作，实现web化操作数据库切换。总的来dg broker操作简单，配置相对复杂(对于sqlplus进行切换来说)下面跟大家分享下dg broker以及12c一些新的变化。
在最近的一个大型项目中，用户提到由我们云提供商进行Oracle数据库的备份、迁移集成工作，是选择用DG、还是RMAN？我们今天来分析一下。
Data Guard broker是建立在Data Guard基础上的一个对Data Guard配置，集中管理操作的一个平台.我们再上次DG主备切换的时候会发现特别麻烦,为此broker出来了。
最近的工作中需要基于Oracle连接到SQLserver2014，我们可以通过配置Gateway的方式来实现这个功能。这个Gateway的实质是透过dblink来实现的。即把SQLserver模拟成一个远端的Oracle实例，这个实例由Gateway来负责进行接收，转发等等。本文简要描述其配置过程。
客户的一套生产环境采用的架构是Oracle ADG + Keepalived，近期需要进行切换演练，要求我这边保障。ADG本身切换倒没啥可说的，但引入keepalived软件，就需要提前研究下这个架构。其实看了下环境配置，整体思路也非常简单，说白了就是利用keepalived软件引入一个VIP，应用侧只需配置连接这个VIP即可。 依据当前生产环境架构模拟了一套自己的测试环境。
Data Guard作为Oracle提供的一个高可用及灾备解决方案,理解并可以实施它对于DBA来说是非常重要套的技能
昨天聊了一篇关于高可用方案中Oracle的RAC和MySQL的MHA的对比。 今天来说下Oracle的DG和MySQL的方案对比，相比来说，可能这方面MySQL会单薄一些，所以文末会说下InnoDB Cluster。 在灾备的概念中，Oracle DBA喜欢叫做主备，即为Primary,Standby,而MySQL喜欢叫做主从，即为Master,Slave 首先在Oracle中，数据是基于物理复制（此处说的都是physical standby），所以对于数据库的状态和角色就很好定位，从库正常状况下是
如何将一个物理DG转换为一个快照DG呢？如果备库正处于Redo Apply过程，那么需要先取消日志应用，并且关闭数据库所有节点到MOUNT阶段：
今天下午我的一个朋友碰到了一个Data Guard的问题，大体是主备网络出现问题，因为环境中配置了自动切换，结果备库就自动切换为了主库，这样就成了“双主”，我帮忙看了下，对备库做了闪回，然后直接转换主库为备库角色，一个看似繁琐的修复工作就完成了。 在一个一主多备的环境中，的确需要一个强大的工具来支持，所以最后朋友说DG Broker真是个好东西，我回了句 用好了DG Broker,手工管理Data Guard就是小米加步枪啊。 就如同我昨天文章Data Guard故障自动切换的想法(r11
（1）使用SID，jdbc:oracle:thin:@host:port:SID，例如
对于dataguard说，switchover,failover是一种互补可选的容灾解决方案。但是对于这种容灾思路还是存在着一些实践中的细节需 要，从数据层面而言，只能是最大程度保证了数据的不丢失，但是数据切换过去了，权限，配置这些信息还是需要考虑的，如果切换过程很快，收尾的补充工作很 慢，那么总体来看切换的时间就被拉长了。 在提出准备的需求之前，容我花一点时间来简单吐槽一下10g中的dataguard. 10g中的状态切换 10g中的dataguard没有adg的特性，在使用中还是有很大的限制，很多时候备
今天看到有一个网友提了一个问题，描述很简短 测试DG时，主库不能宕机，如何测试failover? 其实这个需求从业务层面来说是合理的，一个数据量很大的核心数据库，如果需要做灾难演练，就
Oracle Data Guard主要是通过为生产数据库提供一个或多个备用数据库(是产生数据库的一个副本)，以保证在主库不可用或异常时数据不丢失并通过备用数据库继续提供服务。对于Oracle DG的配置，我们可以通过Grid Control来完成，也可以通过Data Guard Broker以及SQL*Plus来完成。对于前两者方式可以在图形界面上完成，操作简单。而对于使用SQL*Plus命令行方式，我们需要进行大量的配置，尤其是这其中的一些参数。本文主要描述配置Oracle Data Guard 的重要参数。下面关于Data Guard简称为DG。
Oracle 11g DG搭建方法参考：【DB宝29】使用Docker搭建Oracle 11g的DG环境
在zabbix中有了orabbix的辅助，监控效率大大提高，但是因为orabbix是基于jdbc的方式，有些监控还是有一些限制。 比如dataguard的检查，如果采用dg broker来检查，效果就更直观也更可信。 DGMGRL> show configuration; Configuration - csdb Protection Mode: MaxPerformance Databases: test- Primary database stest- Physical stan
1.SQL> alter system set LOG_ARCHIVE_DEST_1='LOCATION=/data/u01/app/oracle/archive/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=db1';
今天在一台机器上模拟了dataguard,主备两个实例从物理上不共享任何归档文件路径。 主要有以下内容： dataguard Physical standby的创建 protection mode的切换 switch over 模拟了两台机器oel1,oel2 主库的归档放在oel1里面，备库的放在oel2里面 --创建的路径如下 ./oel1: orcl_pri_arch orcl_stdby_arch ./oel2: standby_pri_arch standby_stdby_arch --强制
主库（Primary Database）在运行过程中，会源源不断地产生Redo日志，这些日志需要发送到备库（Standy Database）端。这个发送动作可以由主库的LGWR或者ARCn进程完成，不同的归档目的地可以使用不同的方法，但是对于一个目的地，只能选用一种方法。选择不同的进程在数据保护能力和系统可用性方面有很大区别。如果使用LGWR进程来传递日志，但是由于某些原因，LGWR进程变得无法归档到目的地了，那么重做传输将会使用ARCn进程来完成归档操作。
容灾的半自动化的部分，自己写了下面的脚本，也算是一个基本实现，因为时间仓促，还是存在一些不足，稍后完善 整个切换的步骤分为三部分，第一部分是备份当前备库的配置文件，第二部分是使用dg broker决定是failover还是switchover 第三部分是切换之后开始替换参数文件。 所以需要的脚本为dg_pre.sh dg_post.sh dg_pre.sh是作为基本的备份，内容如下： #### validate input parameters #### validate if ip address is
oracle@Linux:~> lsnrctl stop oracle@Linux:~> sqlplus / as sysdba SQL> shutdown immediate; SQL> exit
一个DG环境中只有两种角色：Primary和Standby。所谓角色转换就是让数据库在这两种角色中切换，切换也分两种：Switchover和Failover，关于角色切换需要注意以下几点：
RFS（Remote File Server）进程主要用来接受从主库传送过来的日志信息。对于物理备库而言，RFS进程可以直接将日志写进Standby Redo logs，也可以直接将日志信息写到归档日志中。一般可以在主备库的告警日志中看到如下的信息：
11g的dataguard相比于10g来说，最优越的特性应该算就是active dataguard了，这一点改进在很大意义上促使用户需要把数据库从10g升级到11g,读写分离在这个时候得到了升华，而且在后台会根据需要进行数据的同步，相比于使用10g，想读数据的时候把数据库启动到read only 阶段，但这个时候不接受日志同步数据，如果需要同步数据还需要把数据库再启动到mount阶段，感觉还是比较繁琐的。 11g的active dataurad功能很强大，同时搭建的时候使用rman 的duplicate选项
编辑手记：前文我们分享了DG 中Far Sync Instance的创建和配置，今天一起来学习当Far Sync Instance出现问题时，日志传输的情况，并介绍在配置Far Sync Instance的情况下，switchover的过程。 上文中Oracle12c DataGuard Far Sync的配置和使用简介（上）提到了Far Sync Instance的配置,配置在参数中配置了max_failure=1 alternate=log_archive_dest_3 参数。当dest_2出现问题时会
11g中的ADG特性本身已经非常有特色，促使很多对于10g中不太灵便的备库升级到11g，对于DBA是一大福利，那么还有一个福利就是snapshot standby了。 在平时的数据更新操作中，DBA可以做好sql审核，如果对于复杂的，繁多的变更，如果有些变更有一定的依赖，数据变化情况比较大，评估有难度，很多问题 单纯在测试环境还发现不了，到了生产就是事儿。如果你饱受这种困扰，snapshot standby就是一个不错的选择。你可以让原本只读的备库可读可写，然后写写画画一番之后回归到上一次的一个临界点，继
参考官方文档12c：Using DBCA to Create a Data Guard Standby 12C
本文讲解在Oracle Database 19c中使用Data Guard Broker进行Data Guard物理备用库配置。
DG Broker 是 Oracle 为 Data Guard 维护提供的一个很不错的工具，早期的版本中似乎大家都还是存在一定的思维定式，认为手工维护已经足够了。这个工具就不那么需要了，我们完全可以脱离开这些工具来直观的使用命令行的方式来维护，这个观点也没错，不过从与时俱进的角度来看，本来能够让你更轻松的一个工具，如果不用实在是太可惜了。
对于Oracle Data Guard中的Switchover一般是计划内的操作，自己其实也处理了不少的故障，也算是轻门熟路。复杂的事情简单做，简单的事情重复做，重复的事情用心做，想必很多事情都是这个理吧。 发现很多事情虽然做了很多遍，但是每次都会有不同的体会，而这些积累下来的经验才让我们的经验更加宝贵。 一般来说Oracle的Switchover需要考虑的细节较多，大体有以下的流程。 1.在迁移之前明确目标服务器IP，发出维护公告 这个无需多说，本身就是跨部门，多部门的协调工作，说简单简单，说复杂复
Oracle 12cR2中有一个不错的特性，那就是Active Data Guard会话保留，原本的叫法是Preserving Active Data Guard Application Connections 怎么理解呢，比如在Active Data Guard上的连接会话，在switchover的过程中会话连接会始终保持不会中断。这一点听起来就很有特点，能够提高用户体验度，而且是一种相对透明的方式。 到底怎么样呢，我们来简单测试一下，先看看默认情况下的ADG会话情况,切换的过程就直接使用DG
最近处理了一起看似比较奇怪的dataguard归档路径问题。 问题的背景是这样的。 有一套一主两备的环境，备库1和主库在同一个机房，可以尝试在failover的时候切换备库IP为主库IP。另外还有一台
编辑手记：在Oracle DG中，从主库到备库的日志传输有sync和async两种方式，sync的方式能够实现数据实时传输，但如果遇到网络中断等原因，就可能导致数据丢失。因此，在Oracle 12c中
备库为什么一定要配置静态监听？ nomount状态下必须使用静态监听才能连接到实例
1.TAF(Transparent Application Failover)即透明应用程序故障转移技术。当初始化连接出现问题无法连接时，该功能可以保证应用程序重新连接到可用服务。在重新连接过程中，之前的活动事务将会被回滚，但在“具体条件”下TAF可以保证SELECT语句不被终止。
本篇梳理DG的架构和一些概念知识，重新梳理的目的是加强理解，也方便复习，基于11gR2版本写的，不包含12c新特性。如果能帮助到新接触DG的朋友，那就再好不过。
最近的RAC环境中遭遇ORA-00254，ORA-15173，即无法进行归档。通常情况下归档失败我们考虑更多的是归档路径的不可达，或归档所在的磁盘空间不足造成的。在使用 ASM 存放归档日志的情形下，对于已经配置好且成功归档的数据库也提示路径不可达？看看到底是怎么一回事。
参考：http://www.cnblogs.com/jyzhao/p/4332410.html
Oracle在11g中推出的新特性ADR，即Automatic Diagnostic Repository 个人理解这个工具就是能够高效的把一些日志文件轻松管理起来。比如查看数据库alert日志就不必麻烦去到对应的路径下去找一圈，直接使用show alert即可,比如查看现在数据库中出现了哪些错误，直接通过show problem命令即可。 命令的使用也很方便。直接输入adrci就开启了专门的窗口来使用。如果不知道该使用哪些命令，直接使用help即可。 $ adrci ADRCI: Release 11.2
我的实验环境： 源生产库(主库)： IP地址：192.168.1.30 Oracle 10.2.0.5 单实例
对于将物理备库切换到逻辑备库，需要在主库构建LogMiner字典及启用补充日志，因此应先停用备库的MRP进程，避免产生额外的Redo Apply。如果正在使用Broker管理现有的物理备库，应先在Broker中禁用目标数据库。
dataguard broker是在dataguard使用基础上提供的一个工具，可以把原本复杂的命令控制语句集成起来，比如switchover,failover等等，可能在多个备库的情况下需要敲不少的命令，这个dg broker的优越性就显示出来了。 当然dg broker需要启用还是需要预备一些条件的，比如需要设置local_listener,需要在spfile的基础上，需要在网络配置中进行dgmgrl相关的标示。 应该是在内部实现中默认拥有这些配置。 我们先来看看一个简单的配置情况。 首先启用dg br
对昨天提出的问题做了一个简单的分析和排查，也算是有了一个交代，上一篇文章在 dg broker校验失败的一个奇怪问题 我查看了最近的日志，发现在半个月以前有一行日志引起了我的注意。 Thu Mar 03 17:32:12 2016 ALTER SYSTEM SET log_archive_dest_state_2='DEFER' SCOPE=BOTH; 关于这个DEFER的设置，让我想起了之前的一个设置。 原来的主库发生了硬件电源故障，启用备用电源之后，勉强撑了几个小时，因为数据库之前使用的异机逻辑备份，
昨天在睡觉前接到了一条报警短信，本来已经疲倦的身轻如燕，但是看到报警，还是警觉了起来 ZABBIX-监控系统: ------------------------------------ 报警内容: DG_issue ------------------------------------ 报警级别: PROBLEM ------------------------------------ 监控项目: dg_issue：2015-12-27 00:35:17.0Log Transport Servic
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
云直播
