Data Guard broker是建立在Data Guard基础上的一个对Data Guard配置，集中管理操作的一个平台.我们再上次DG主备切换的时候会发现特别麻烦,为此broker出来了。
今天下午我的一个朋友碰到了一个Data Guard的问题，大体是主备网络出现问题，因为环境中配置了自动切换，结果备库就自动切换为了主库，这样就成了“双主”，我帮忙看了下，对备库做了闪回，然后直接转换主库为备库角色，一个看似繁琐的修复工作就完成了。 在一个一主多备的环境中，的确需要一个强大的工具来支持，所以最后朋友说DG Broker真是个好东西，我回了句 用好了DG Broker,手工管理Data Guard就是小米加步枪啊。 就如同我昨天文章Data Guard故障自动切换的想法(r11
首先，DG（Data Guard，数据卫士）不是一个备份恢复的工具，然而，DG却拥有备份的功能，在物理DG下它可以和主库一模一样，但是它存在的目的并不仅仅是为了备份恢复数据，应该说它的存在是为了确保企业数据的高可用性，数据保护以及灾难恢复。DBA可以通过将一些操作（例如查询报表）转移到备库执行的方式来减小主库的压力，构建高可用的企业数据库应用环境。
主库（Primary Database）在运行过程中，会源源不断地产生Redo日志，这些日志需要发送到备库（Standy Database）端。这个发送动作可以由主库的LGWR或者ARCn进程完成，不同的归档目的地可以使用不同的方法，但是对于一个目的地，只能选用一种方法。选择不同的进程在数据保护能力和系统可用性方面有很大区别。如果使用LGWR进程来传递日志，但是由于某些原因，LGWR进程变得无法归档到目的地了，那么重做传输将会使用ARCn进程来完成归档操作。
RFS（Remote File Server）进程主要用来接受从主库传送过来的日志信息。对于物理备库而言，RFS进程可以直接将日志写进Standby Redo logs，也可以直接将日志信息写到归档日志中。一般可以在主备库的告警日志中看到如下的信息：
Data Guard作为Oracle提供的一个高可用及灾备解决方案,理解并可以实施它对于DBA来说是非常重要套的技能
Oracle Data Guard主要是通过为生产数据库提供一个或多个备用数据库(是产生数据库的一个副本)，以保证在主库不可用或异常时数据不丢失并通过备用数据库继续提供服务。对于Oracle DG的配置，我们可以通过Grid Control来完成，也可以通过Data Guard Broker以及SQL*Plus来完成。对于前两者方式可以在图形界面上完成，操作简单。而对于使用SQL*Plus命令行方式，我们需要进行大量的配置，尤其是这其中的一些参数。本文主要描述配置Oracle Data Guard 的重要参数。下面关于Data Guard简称为DG。
本篇梳理DG的架构和一些概念知识，重新梳理的目的是加强理解，也方便复习，基于11gR2版本写的，不包含12c新特性。如果能帮助到新接触DG的朋友，那就再好不过。
本文讲解在Oracle Database 19c中使用Data Guard Broker进行Data Guard物理备用库配置。
编辑手记：前文我们分享了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出现问题时会
DG Broker 是 Oracle 为 Data Guard 维护提供的一个很不错的工具，早期的版本中似乎大家都还是存在一定的思维定式，认为手工维护已经足够了。这个工具就不那么需要了，我们完全可以脱离开这些工具来直观的使用命令行的方式来维护，这个观点也没错，不过从与时俱进的角度来看，本来能够让你更轻松的一个工具，如果不用实在是太可惜了。
Oracle RAC 11g DG Broker配置和测试 本篇在实验环境中实际配置 环境： RHEL 6.5 + Oracle 11.2.0.4 GI、DB + Primary RAC（2 nodes）+ Standby RAC（2 nodes）
今天在一台机器上模拟了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 --强制
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';
DG Broker是Oracle为Data Guard维护提供的一个很不错的工具，从我的实际使用来看，早期的版本中似乎大家都还是存在一定的思维定式，认为手工维护已经足够了。这个工具就不那么需要了，我们完全可以脱离开这些工具来直观的使用命令行的方式来维护，这个观点也没错，不过从与时俱进的角度来看，本来能够让你更轻松的一个工具，如果不用实在是太可惜了。 DG Broker在数据库端需要启用一个后台进程dmon来维护，这个后台进程启动，需要设置dg_broker_start为true即可，如果要停止，只需
Oracle 12cR2中有一个不错的特性，那就是Active Data Guard会话保留，原本的叫法是Preserving Active Data Guard Application Connections 怎么理解呢，比如在Active Data Guard上的连接会话，在switchover的过程中会话连接会始终保持不会中断。这一点听起来就很有特点，能够提高用户体验度，而且是一种相对透明的方式。 到底怎么样呢，我们来简单测试一下，先看看默认情况下的ADG会话情况,切换的过程就直接使用DG
DG 的工作原理是通过网络将主数据库的重做数据传输到备用数据库，然后在备用数据库上应用这些重做数据，以确保数据的一致性。
通常情况下习惯使用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一些新的变化。
对于将物理备库切换到逻辑备库，需要在主库构建LogMiner字典及启用补充日志，因此应先停用备库的MRP进程，避免产生额外的Redo Apply。如果正在使用Broker管理现有的物理备库，应先在Broker中禁用目标数据库。
11g的dataguard相比于10g来说，最优越的特性应该算就是active dataguard了，这一点改进在很大意义上促使用户需要把数据库从10g升级到11g,读写分离在这个时候得到了升华，而且在后台会根据需要进行数据的同步，相比于使用10g，想读数据的时候把数据库启动到read only 阶段，但这个时候不接受日志同步数据，如果需要同步数据还需要把数据库再启动到mount阶段，感觉还是比较繁琐的。 11g的active dataurad功能很强大，同时搭建的时候使用rman 的duplicate选项
在最近的一个大型项目中，用户提到由我们云提供商进行Oracle数据库的备份、迁移集成工作，是选择用DG、还是RMAN？我们今天来分析一下。
Oracle Data Guard 为企业数据库提供了最有效和最全面的数据可用性、数据保护和灾难恢复解决方案。它集成管理、监视和自动化软件基础架构来创建和维护一个或多个同步备用数据库，从而保护数据不受故障、灾难、错误和损坏的影响。本文主要描述了在同一主机下如何配置Oracle Data Guard。
最近的工作中需要基于Oracle连接到SQLserver2014，我们可以通过配置Gateway的方式来实现这个功能。这个Gateway的实质是透过dblink来实现的。即把SQLserver模拟成一个远端的Oracle实例，这个实例由Gateway来负责进行接收，转发等等。本文简要描述其配置过程。
客户的一套生产环境采用的架构是Oracle ADG + Keepalived，近期需要进行切换演练，要求我这边保障。ADG本身切换倒没啥可说的，但引入keepalived软件，就需要提前研究下这个架构。其实看了下环境配置，整体思路也非常简单，说白了就是利用keepalived软件引入一个VIP，应用侧只需配置连接这个VIP即可。 依据当前生产环境架构模拟了一套自己的测试环境。
昨天聊了一篇关于高可用方案中Oracle的RAC和MySQL的MHA的对比。 今天来说下Oracle的DG和MySQL的方案对比，相比来说，可能这方面MySQL会单薄一些，所以文末会说下InnoDB Cluster。 在灾备的概念中，Oracle DBA喜欢叫做主备，即为Primary,Standby,而MySQL喜欢叫做主从，即为Master,Slave 首先在Oracle中，数据是基于物理复制（此处说的都是physical standby），所以对于数据库的状态和角色就很好定位，从库正常状况下是
参考官方文档12c：Using DBCA to Create a Data Guard Standby 12C
如何将一个物理DG转换为一个快照DG呢？如果备库正处于Redo Apply过程，那么需要先取消日志应用，并且关闭数据库所有节点到MOUNT阶段：
Oracle ADG全称为Oracle Active Data Guard，它是Oracle Data Guard功能集中的一个高级选项。Active Data Guard是Oracle数据库提供的一种高级高可用性和灾难恢复解决方案，它在Oracle Data Guard的基础上进一步增强了备用数据库（Standby Database）的功能和利用率。
近期在某银行生产环境做的一次PDB迁移，使用的是PDB refresh方式，记录一下流程及遇到的坑。
（1）使用SID，jdbc:oracle:thin:@host:port:SID，例如
对于dataguard说，switchover,failover是一种互补可选的容灾解决方案。但是对于这种容灾思路还是存在着一些实践中的细节需 要，从数据层面而言，只能是最大程度保证了数据的不丢失，但是数据切换过去了，权限，配置这些信息还是需要考虑的，如果切换过程很快，收尾的补充工作很 慢，那么总体来看切换的时间就被拉长了。 在提出准备的需求之前，容我花一点时间来简单吐槽一下10g中的dataguard. 10g中的状态切换 10g中的dataguard没有adg的特性，在使用中还是有很大的限制，很多时候备
今天看到有一个网友提了一个问题，描述很简短 测试DG时，主库不能宕机，如何测试failover? 其实这个需求从业务层面来说是合理的，一个数据量很大的核心数据库，如果需要做灾难演练，就
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
今天在 Oracle 原厂公众号上看到了一篇描述 Oracle 21c ADG 新特性的文章，基于 PDB 级别的 ADG 可以实现自由切换，非整个 CDB 级别的 ADG 及 Switchover 十分不错，值得推荐，故分享给大家。
oracle@Linux:~> lsnrctl stop oracle@Linux:~> sqlplus / as sysdba SQL> shutdown immediate; SQL> exit
整理一份DG的搭建流程，参考了一些教程及文档，环境是Oracle 11gR2 1+1。DG计划整理三篇：搭建、概念、维护。
dataguard broker是在dataguard使用基础上提供的一个工具，可以把原本复杂的命令控制语句集成起来，比如switchover,failover等等，可能在多个备库的情况下需要敲不少的命令，这个dg broker的优越性就显示出来了。 当然dg broker需要启用还是需要预备一些条件的，比如需要设置local_listener,需要在spfile的基础上，需要在网络配置中进行dgmgrl相关的标示。 应该是在内部实现中默认拥有这些配置。 我们先来看看一个简单的配置情况。 首先启用dg br
一个DG环境中只有两种角色：Primary和Standby。所谓角色转换就是让数据库在这两种角色中切换，切换也分两种：Switchover和Failover，关于角色切换需要注意以下几点：
容灾的半自动化的部分，自己写了下面的脚本，也算是一个基本实现，因为时间仓促，还是存在一些不足，稍后完善 整个切换的步骤分为三部分，第一部分是备份当前备库的配置文件，第二部分是使用dg broker决定是failover还是switchover 第三部分是切换之后开始替换参数文件。 所以需要的脚本为dg_pre.sh dg_post.sh dg_pre.sh是作为基本的备份，内容如下： #### validate input parameters #### validate if ip address is
Oracle Data Guard是Oracle MAA(Maximum Availability Architecture)中的成员之一，也是MAA中技术要求最简单的方案之一。随着Oracle新功能的引入如Active Standby Database后，加速了Oracle Data Guard的普及。响应去I的趋势和X86架构的流行，对Oracle Data Guard的普及更起到了锦上添花的影响。
我们帮助行业客户进行上云业务迁移，Oracle的业务数据迁移几乎成了必然遇到的问题。对Oracle的数据高可用，作为云架构师，应该说是必须懂。今天我们从入门开始，介绍一些常见的问题。
同事说dg不能同步，让我帮忙看看，我用自己写的2个视图查看了下，首先发现主库没有常见的LNSn进程，下意识的认为主库这个进程没有启动，需要切换日志唤醒LNSn进程，事实上也这样做了，（alter system set log_archive_dest_state_2='defer'; alter system switch logfile; alter system set log_archive_dest_state_2='enable'; alter system switch logfile;），切换后发现日志可以正常传输了，但是主库还是看不到LNSn这个进程，于是找找资料，深入的研究了一下这个问题。
DG的主备角色转换分为：Switchover和Failover。Switchover适用于某些场合，需要将备库转为主库，Failover则是在主库故障无法使用情况下，将备库提升为主库。
参考：http://www.cnblogs.com/jyzhao/p/4332410.html
背景：某客户Oracle 10g 的DG由于空间不足，之前将部分数据文件迁移到其他目录，如今原目录扩容成功，要将之前迁移的数据文件再次迁移回来。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
