环境：RHEL 6.5 + Oracle GI 11.2.0.4 + Oracle DB 11.2.0.4 Primary RAC（2 nodes） + Standby RAC（2 nodes）
一个DG环境中只有两种角色：Primary和Standby。所谓角色转换就是让数据库在这两种角色中切换，切换也分两种：Switchover和Failover，关于角色切换需要注意以下几点：
DG 的工作原理是通过网络将主数据库的重做数据传输到备用数据库，然后在备用数据库上应用这些重做数据，以确保数据的一致性。
但是，如果去查v$archive_dest_status，就会发现问题，说有可解决的GAP：
DG的主备角色转换分为：Switchover和Failover。Switchover适用于某些场合，需要将备库转为主库，Failover则是在主库故障无法使用情况下，将备库提升为主库。
Oracle DataGuard；简称DG。是由一个Primary Database（主库）和一个或者多个Standby Database（备库）组成。对Oracle来说；本身不能提高性能。通过数据冗余来保护数据。由Primary Database对外提供服务；用户操作在Primary Database上操作；其操作的数据库Redo Log或者Archive log通过网络传输到Standby Database。Standby Database在重做这些日志。从而实现Primary Database和Standby Database数据同步。
data guard的主要功能就是作为备库来同步主库的数据变化，一般使用中物理standby使用的比较多。data guard显示威力的一个场景就是swithover了，即主备切换。这种切换方式执行时间很短，能够在一些灾难场景中极大的提高系统的可用性和稳定性。 自己在本地的环境中搭建了一套data guard的环境，开始比较生疏，切换中碰到了不少的问题，最后搭建完成，把切换中的一些细节信息都总结起来，整理成了一个初步的脚本。能够很方便的实现swithover 这个脚本适用于物理standby，在本地环境中
测试环境：RHEL 5.4 + Oracle 11.2.0.3 DG 现象：起初是在使用DG Broker进行switchover切换测试时，报错ORA-16775，提示有可能有数据丢失，不允许switchover.
Data Guard作为Oracle提供的一个高可用及灾备解决方案,理解并可以实施它对于DBA来说是非常重要套的技能
其实对于Failover和Switchover是大家处理灾难时很头疼的一个环节，也是最关键的处理过程。 假设你半夜正在睡觉，被报警电话惊醒，得知某个服务器产生了故障宕机，在这种情况下，我们大体会有下面的处理流程： 1）检查原来的节点是否可用，需要查看ILO和存储，是否存在异常 2）如果原来的节点可以重启，可以尽量马上恢复业务，然后分析根本原因，是否是硬件老化，硬件故障导致，如果发现问题影响较大，可以使用Switchover 3）如果原来的节点无法重启，这个时候需要考虑Failover,如果在同机房可以直接替
假设SwitchA和SwitchB两台交换机组成堆叠系统，现SwitchA发生了故障，需要使用SwitchC替换掉SwitchA。建议参照如下步骤进行替换操作。
DG Broker是Oracle为Data Guard维护提供的一个很不错的工具，从我的实际使用来看，早期的版本中似乎大家都还是存在一定的思维定式，认为手工维护已经足够了。这个工具就不那么需要了，我们完全可以脱离开这些工具来直观的使用命令行的方式来维护，这个观点也没错，不过从与时俱进的角度来看，本来能够让你更轻松的一个工具，如果不用实在是太可惜了。 DG Broker在数据库端需要启用一个后台进程dmon来维护，这个后台进程启动，需要设置dg_broker_start为true即可，如果要停止，只需
场景1:数据库SWITCHOVER切换之前停止OGG CLASSIC EXTRACT进程,切换之后修改OGG访问新主库,OGG EXTRACT进程RBA不移动也不会报错.
在数据库环境中，一主一备是比较传统的使用方式，在灾难发生的时候，可以灵活的切换主备角色，依然可以保持服务的可访问性。但是一些核心系统来说还是会有更多的过滤，一主一备似乎还是不够稳妥，如果主备出现问题，如果有另外一个备库还是有可选的余地，这种情况不是不可能发生，正是因为核心业务的需要还是需要保证数据的安全。 很多场景下，一主两备会保持这样的场景，一主一备在同一个区域内，这样在出现问题的时候方便切换，如果区域出现故障，可以保证异地的机房可以顺利承接服务。 比如下面的这种方式是比较传统的一主一备的方式。因为是在1
背景： 环境未配置DG Broker，手工切换ADG，19c也要比11g时代的切换更简单。 使用自己的测试环境，具体可参见： 单实例Primary快速搭建Standby RAC参考手册(19.16 ADG)
杨廷琨，云和恩墨CTO，Oracle ACED，ITPUB Oracle 数据库管理版版主 ，人称"杨长老”，十数年如一日坚持进行Oracle技术研究与写作，号称"Oracle的百科全书”，迄今已经在自己的博客上发表了超过3000篇技术文章。与 Eygle 共同主编出版了多本《Oracle DBA手记》系列图书。
Oracle 12cR2中有一个不错的特性，那就是Active Data Guard会话保留，原本的叫法是Preserving Active Data Guard Application Connections 怎么理解呢，比如在Active Data Guard上的连接会话，在switchover的过程中会话连接会始终保持不会中断。这一点听起来就很有特点，能够提高用户体验度，而且是一种相对透明的方式。 到底怎么样呢，我们来简单测试一下，先看看默认情况下的ADG会话情况,切换的过程就直接使用DG
客户的一套生产环境采用的架构是Oracle ADG + Keepalived，近期需要进行切换演练，要求我这边保障。ADG本身切换倒没啥可说的，但引入keepalived软件，就需要提前研究下这个架构。其实看了下环境配置，整体思路也非常简单，说白了就是利用keepalived软件引入一个VIP，应用侧只需配置连接这个VIP即可。 依据当前生产环境架构模拟了一套自己的测试环境。
通常情况下习惯使用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一些新的变化。
参考官方文档12c：Using DBCA to Create a Data Guard Standby 12C
11g的dataguard相比于10g来说，最优越的特性应该算就是active dataguard了，这一点改进在很大意义上促使用户需要把数据库从10g升级到11g,读写分离在这个时候得到了升华，而且在后台会根据需要进行数据的同步，相比于使用10g，想读数据的时候把数据库启动到read only 阶段，但这个时候不接受日志同步数据，如果需要同步数据还需要把数据库再启动到mount阶段，感觉还是比较繁琐的。 11g的active dataurad功能很强大，同时搭建的时候使用rman 的duplicate选项
Oracle RAC 11g DG Broker配置和测试 本篇在实验环境中实际配置 环境： RHEL 6.5 + Oracle 11.2.0.4 GI、DB + Primary RAC（2 nodes）+ Standby RAC（2 nodes）
VERITAS Cluster Server(VCS) connects, or clusters, multiple, independent systems into a management framework for increased availability. Each system, or node, runs its own operating system and cooperates at the software level to form a cluster. VCS links commodity hardware with intelligent software to provide application failover and control. When a node or a monitored application fails, other nodes can take predefined action to take over and bring up services elsewhere in the cluster.
最近在做的项目是智慧屏项目，用于公司的电视屏展示，它采用的技术栈是vue+js+sass,项目很多采用的都是组件化，用组件化的优点就是可复用性高，减少代码冗余，组件化的思想在开发中很常见也很重要。下面将这次项目中自己做的不足的点以及需要注意的点列举出来。感兴趣的朋友可以看看。
最近对一个统计库做了计划内的容灾切换，即主备切换。操作的过程其实还是蛮顺利的。但是灾难切换中如果出现在问题，那就是灾难中的灾难了。 按照计划对配置信息做了同步，然后使用DG Broker做了SwitchOver操作。 这一次切换速度还是蛮快，我开了几个窗口看到日志都在不断输出，角色已经替换过来了。DG Broker切换的日志如下： DGMGRL> switchover to test29; Performing switchover NOW, please wait... New primary datab
编辑手记：前文我们分享了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出现问题时会
最近又试了下Data Guard的新玩法，可以通过闪回恢复switchover的主库，这种场景听起来比较特别，但是Oracle依旧支持。 我们的大体思路就是，在主库我们标记一下数据状态，然后做
今天看到有一个网友提了一个问题，描述很简短 测试DG时，主库不能宕机，如何测试failover? 其实这个需求从业务层面来说是合理的，一个数据量很大的核心数据库，如果需要做灾难演练，就
对于Oracle Data Guard中的Switchover一般是计划内的操作，自己其实也处理了不少的故障，也算是轻门熟路。复杂的事情简单做，简单的事情重复做，重复的事情用心做，想必很多事情都是这个理吧。 发现很多事情虽然做了很多遍，但是每次都会有不同的体会，而这些积累下来的经验才让我们的经验更加宝贵。 一般来说Oracle的Switchover需要考虑的细节较多，大体有以下的流程。 1.在迁移之前明确目标服务器IP，发出维护公告 这个无需多说，本身就是跨部门，多部门的协调工作，说简单简单，说复杂复
dataguard broker是在dataguard使用基础上提供的一个工具，可以把原本复杂的命令控制语句集成起来，比如switchover,failover等等，可能在多个备库的情况下需要敲不少的命令，这个dg broker的优越性就显示出来了。 当然dg broker需要启用还是需要预备一些条件的，比如需要设置local_listener,需要在spfile的基础上，需要在网络配置中进行dgmgrl相关的标示。 应该是在内部实现中默认拥有这些配置。 我们先来看看一个简单的配置情况。 首先启用dg br
今天在 Oracle 原厂公众号上看到了一篇描述 Oracle 21c ADG 新特性的文章，基于 PDB 级别的 ADG 可以实现自由切换，非整个 CDB 级别的 ADG 及 Switchover 十分不错，值得推荐，故分享给大家。
当用户在设备上存储了电子标签信息时，可以通过命令将电子标签信息保存到文件中。该文件既可以保存在设备的存储介质中，也可以通过FTP协议保存在FTP服务器上，还可以通过TFTP协议保存在TFTP服务器上。
1.3.2 备库切换到open状态，启用Real-time query A physical standby database instance cannot be opened if Redo Apply is active on a mounted instance of that database. Use the following SQL statements to stop Redo Apply, open a standby instance read-only, and restart Redo Apply:
今天在做一套RAC DG的switchover演练，将备库两个节点都开启时查询v$database的switchover状态报如下错误
环境：Linux + Oracle 11.2.0.1 ADG 现象：发现备库没有应用日志
徐晨亮，MySQL DBA，知数堂学员。热衷于数据库优化，自动化运维及数据库周边工具开发，对MySQL源码有一定的兴趣。 一、切换流程图： 二、核心代码： 主要实现逻辑在cluster_fail.
昨天聊了一篇关于高可用方案中Oracle的RAC和MySQL的MHA的对比。 今天来说下Oracle的DG和MySQL的方案对比，相比来说，可能这方面MySQL会单薄一些，所以文末会说下InnoDB Cluster。 在灾备的概念中，Oracle DBA喜欢叫做主备，即为Primary,Standby,而MySQL喜欢叫做主从，即为Master,Slave 首先在Oracle中，数据是基于物理复制（此处说的都是physical standby），所以对于数据库的状态和角色就很好定位，从库正常状况下是
ADG单实例搭建系列之（Active Database Duplicate Using Image Copies）
参考：http://www.cnblogs.com/jyzhao/p/4332410.html
本文比较基础，主要介绍postgresql开源高可用工具repmgr的部署和使用，初学者可以根据本文步骤一步一步做下去，废话不多说，直接进入主题，本文以两台机器为例。
我的实验环境： 源生产库(主库)： IP地址：192.168.1.30 Oracle 10.2.0.5 单实例
目前遇到了一个问题，目前的是一主两备的环境，但是主库，备库中的存储空间都不足。而且硬件环境相对要老旧一些。想扩容难，系统版本老旧想升级也难。 数据库是基于10gR2，有异地灾备。但是因为10gR2的dataguard没有灾备的感觉，其实感觉和一个主库没有什么明显的差别。而且一旦发生问题，切换以后，硬件的限制瓶颈还是解决不了，所以化被动为主动，可以提前预警，提前规划和考虑。 现在是一主两备，但是备库目前的情况不容乐观，所以需要扩容一下，升级操作系统版本，目前为6U5，重新规划
很多时候，大家工作中都会有一种被动的思维，那就是能不动就不动，从求稳的角度来看无可厚非，但是从风险的角度来说，还是有待商榷的。如果存在风险，还保持原样很可能就是一个不定时炸弹。 这不手头有一套环境，按照以前的标准是根本入不了我的法眼的，但是因为是测试环境，小问题比较多，存在容灾风险，但是这么多年一直这样，也就默然接受了。 这套环境硬件配置很低，基本上和我的笔记本配置差不多，可能还略差一些，在上面跑着3个数据库实例，其中一个是11g的，2个是10g的。两个10g的数据库实例数据量都不大，几十G而已。 看起来是
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';
今天在琢磨几件事情，也是和工作相关。 数据灾难切换的几点认识： 在unix中可能会碰到在处理网络问题时，超时时间会远远高于linux的情况，这个时候如果尝试做failover是非常消耗时间的，而且日志没有任何输出，看不到进展，相比于linux的处理，我感觉要更简洁一些。 鉴于unix中的处理方式，我还是建议直接使用命令行来做failover,使用下面两个命令即可。 alter database recover managed standby database finish force; alter data
我这里用的是dbdeployer部署的mysql 5.7单机多实例的主从架构。 宿主机地址： 192.168.2.4 复制用的账号和密码： rsandbox rsandbox 准备给replication-manager用的账号密码： rep-manager rep-manager
第二次执行时不再提示输入yes，并且可以成功执行命令，则表示SSH对等性配置成功。
在公众号后台收到一条问题，就是h3c的75交换机如何切换主控板的主备？首先解释一下什么是主控板？如下图，这是一个典型的交换机主控板，从硬件来说，很像我们电脑的主板，上面各种单元控制着整台机器的运转。当然我们今天所讲的东西不涉及硬件，h3c有专门的命令可以进行切换。
作者简介 李真旭 Oracle ACE 专家，拥有超过10年的 Oracle 运维管理使用经验，参与过众多移动、电信、联通、银行等大型数据库交付项目，具有丰富的运维管理经验，对 Oracle 数据库管
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
