整理一份DG的搭建流程，参考了一些教程及文档，环境是Oracle 11gR2 1+1。DG计划整理三篇：搭建、概念、维护。
针对Oracle迁移上云项目，云提供给用户的物理机上加载有三张网卡供用户使用，一张用于跑业务，另外两张可以用于心跳线网络。另外，存储网络是单独的网口，在建设时已由服务商做好配置，不含在这三张网卡内。基于公有云技术，为了组建资源池内部管理控制专网，因此现市面上公有云提供商的IPMI端口，均不能提供出来用于对外访问。
与Oracle在华大规模裁员相比，国产数据库好消息连连，2019年可以说是国产数据库年。举几个例子，华为推出GaussDB，并成功上线招商银行/工商银行核心系统;中信信用卡系统运行在中兴GoldenDB之上；Oceanbase登顶TPC-C....
随着Oracle的普遍应用，DataGuard这个成员基本成为了数据库容灾环境的标配。当需要升级Oracle数据库的同时，也需要考虑同时升级DataGuard数据库版本，那么如何快捷安全的升级？
作者 | 张乐奕：Oracle ACE 总监，ACOUG （中国 Oracle 用户组）联合发起人。Oracle 数据库高可用解决方案与 Exadata 一体机专家。长于数据库故障诊断，性能调优。作为多家知名论坛版主，热衷社区技术分享，同时也是 Exadata 用户组的发起人，组织策划并作为技术分享者的活动已超过百场。
Oracle Data Guard 为企业数据库提供了最有效和最全面的数据可用性、数据保护和灾难恢复解决方案。它集成管理、监视和自动化软件基础架构来创建和维护一个或多个同步备用数据库，从而保护数据不受故障、灾难、错误和损坏的影响。本文主要描述了在同一主机下如何配置Oracle Data Guard。
11g的dataguard相比于10g来说，最优越的特性应该算就是active dataguard了，这一点改进在很大意义上促使用户需要把数据库从10g升级到11g,读写分离在这个时候得到了升华，而且在后台会根据需要进行数据的同步，相比于使用10g，想读数据的时候把数据库启动到read only 阶段，但这个时候不接受日志同步数据，如果需要同步数据还需要把数据库再启动到mount阶段，感觉还是比较繁琐的。 11g的active dataurad功能很强大，同时搭建的时候使用rman 的duplicate选项
最近准备给一个生产项目上oracle 11g DataGuard,主备均为oracle 11.2.0.4软件，并在备库安装软件。这篇不讲述 DataGuard 的原理，只是oracle 11g DataGuard 搭建的详细过程。这次是生产库的RAC需要做一个DG，由于不知道SYS 用户密码，需要取回密码太麻烦，故不能使用 duplicate 方式，使用rman 全备 -->还原控制文件--> mount数据库还原数据文件 --> 追加日志 --> 主备同步。搭建过程中只需要修改部分参数以及网络监听，故不需要停机可白天完成，下面开始进入主题。
回忆起来也是有些年没亲自动手搭建ADG了，今天正好有个机会重温，客户环境是19.16，恍惚记得上一次搭ADG还是在11.2.0.4的时代，时光荏苒啊。 正好看下19c的ADG和11g的ADG在部署方面有啥不同？ 主备库都是RAC架构，数据库是CDB架构，包含有4个PDB，整个搭建过程还是遇到很多小问题，但基本也都知道原因并能快速解决，也有个别折腾了很久的，蛮有意思，所以记录下本次遇到的问题供日后参考，客户信息已脱敏。
Oracle Data Guard是Oracle MAA (Maximum Availability Architecture)中的成员之一。从Oracle 7i版本开始推出STANDBY DATABASE的概念，慢慢受到大家的欢迎。随着Oracle数据库版本的更迭，搭建备库的方式多种多样。今天介绍一种创建物理备库的新方式，从12C版本开始推出：使用 DBCA 命令行。
一直以来搭建Data Guard是一件看起来还蛮有含量的工作，因为这其中涉及的工作比较琐碎，比较细，况且手工搭建起来都会碰到各种各样的问题，如果中途碰到一点儿小问题，那可能需要花点时间来排查，如果想要脚本自动化，那简直寸步难行。所以搭建Data Guard一方面会需要很多的提前准备和配置，另一方面这个工作自动化的驱动力不够，毕竟环境不会像MySQL业务一样动辄几十成百上千的规模，所以由此而来，好像搭建一个套环境的成本也值了，如果尝试自动化，半自动化，那花费的时间估计够搭建10套环境了。所以目前来看，
有一个环境是10gR2，一主两备，因为10g的备库还不是active,所以有一些查询的需求的时候，我们还是会打开相应的窗口时间。 开发的同学需要做一个大查询，数据只能全表，而且还有order by，势必会消耗大量的temp空间，这个时候充分利用备库就是好一些，有一个备库平时也没有用过，今天就用这个备库来完成查询需求。 但是过了一会，开发同事说，查询失败了。让我看看什么原因。 开发同学提供的日志为： 2015-11-20 10:48:05,---exception: ---- StatementCallbac
今天在搭建DG的时候碰到了一个蛮有意思的问题，耗费了不少脑细胞，简单记录一下。 首先主库是Queuedb,备库是s2queuedb，使用RMAN的duplicate来搭建，主备库的网络配置listener.ora,tnsnames.ora都没有问题。 但是使用RMAN命令的时候就抛出了下面的错误，从错误信息可以看出来，主库是没有启动起来。 $ rman target sys@Queuedb auxiliary sys@s2queuedb nocatalog connected to target datab
查看当前归档日志路径，空间的使用率已经到了100%，于是在rman中，删除30天之前的归档日志文件，
Oracle版本为12c R2：搭建完成DG库有trace目录中日志增长过快，其中一类mmon 的日志中主要为如下内容
Oracle 11g DG搭建方法参考：【DB宝29】使用Docker搭建Oracle 11g的DG环境
Oracle RAC 11g DG Broker配置和测试 本篇在实验环境中实际配置 环境： RHEL 6.5 + Oracle 11.2.0.4 GI、DB + Primary RAC（2 nodes）+ Standby RAC（2 nodes）
最近暴雪公司和网易的一则声明刷爆了朋友圈，大意就是由于『供电意外中断的原因而产生故障，导致数据损坏』，这样一则公告引发了一系列的猜想，我们在围观时仿佛人人都是诸葛亮，而事实上设身处地，我想在一次负责任
原文：http://www.enmotech.com/web/detail/1/703/1.html
本文介绍一下，在DG环境中，若主库做了闪回数据库的操作后，备库如何通过flashback操作，继续和主库保持同步，而不用重新搭建DG。
昵称：院长 性别：男 爱好：羽毛球，乒乓球，嗨歌，钻研技术 技能：在下方 职位：落魄技术
墨墨导读：本文来自墨天轮用户投稿，介绍使用RMAN duplicate搭建12C的Data Guard环境的全过程。
ORACLE数据库既能跑OLTP业务，也能跑OLAP业务，能力是商业数据库中数一数二的。支持IBM小机和x86 PC服务器，支持多种OS。同时有多种数据库架构方案供选择，成本收益风险也各不相同。
ADG单实例搭建系列之（Active Database Duplicate Using Image Copies）
今天下午我的一个朋友碰到了一个Data Guard的问题，大体是主备网络出现问题，因为环境中配置了自动切换，结果备库就自动切换为了主库，这样就成了“双主”，我帮忙看了下，对备库做了闪回，然后直接转换主库为备库角色，一个看似繁琐的修复工作就完成了。 在一个一主多备的环境中，的确需要一个强大的工具来支持，所以最后朋友说DG Broker真是个好东西，我回了句 用好了DG Broker,手工管理Data Guard就是小米加步枪啊。 就如同我昨天文章Data Guard故障自动切换的想法(r11
导语：沃趣科技的QBackup数据库备份容灾云平台，是一套集合了CDP备份，历史数据秒级恢复，灾备保护等功能的一体化云平台。支持主流的Oracle、MySQL等数据库，可同时对大量数据库做集中式备份和管理，并对备份进行持续校验以确保数据的可恢复性。QBackup同时可用于应用测试、预发布、性能优化、POC等诸多应用场景。 继QBackup v4.0.0版本发布之后，沃趣科技持续深化对于数据库备份容灾产品的研发，于近日正式发布了QBackup v4.1.0版本，消除了旧版本中已知的风险点，同时增加了多项新功能
为了及时共享行业案例，通告共性问题，达成知识共享和提前预防，我们整理和编辑了《云和恩墨技术通讯》（7月刊），通过对过去一段时间的知识回顾和故障归纳，以期提供有价值的信息供大家参考。 同时，我们也希望能够将热点事件、新的产品特性及其他有价值的信息聚集起来，为您提供具有前瞻性的支持信息，保持对于当前最新的数据库新闻和事件的了解，其中包括重要数据库产品发布、警报、更新、新版本、补丁等。
经过交流群中朋友的多次要求，这次给大家分享一下 RAC to Single 的 ADG 搭建教程！
在Oracle中，Oracle Cluster Health Monitor（CHM）的作用是什么？
（1）使用SID，jdbc:oracle:thin:@host:port:SID，例如
Oracle ADG全称为Oracle Active Data Guard，它是Oracle Data Guard功能集中的一个高级选项。Active Data Guard是Oracle数据库提供的一种高级高可用性和灾难恢复解决方案，它在Oracle Data Guard的基础上进一步增强了备用数据库（Standby Database）的功能和利用率。
前段时间测试了一下GoldenGate，结合我之前的一些尝试，对于小机环境的迁移，思路是逐步清晰了起来。 需求的核心是跨平台迁移数据库，最好能够升级到新的版本，对于一个核心系统的一主两备，需要保证数据
今天行程还是比较匆忙，刚回到家，打开微信就收到了几个问题，有不少是和迁移相关的，我选出几个，还有几个需要好好考虑一下。 问题1: 我们的多个业务系统都是Oracle的数据库，每个业务都搭了dg，各占两台服务器，但是学校的业务量不大，想把这些库迁到一台服务器上，我现在的知识量只能想到用虚拟机，但是又觉得虚拟机不是很可靠，所以想让您指点一下 答： 对于这种情况，其实迁移方式有三种， 1）因为业务量不大，可以把几个系统的迁移到一台物理机器上，或者主备重新平衡。比如三套业务系统，那么一主一备就是6台服务器，比如一
在Oracle 10g的中搭建Data Guard环境真是一个纠结，目前大体都是采用两种方式，一种是rman备份，一种是duplicate的方式，但是这两个地方不够让我满意，一来是rman备份数据量不小，需要先在本地生成备份，然后拷贝到备库去，这个搭建周期略长，另外一个就是推荐的方式duplicate,在10g中有些鸡肋的味道，本地备份，然后拷贝到备库，然后动用duplicate的方式，这样的方式还不如手工rman的方式同步来得顺心顺意，所以在10g中我是不怎么喜 欢duplicate方式。当然11
Data Guard的搭建可以使用GC图形化安装，优缺点很明显，优点就是图形化操作，符合国人的习惯(据secooler介绍外国程序员能用图形化做的事就一定用图形做，因为boss看得懂，和国人正相反。。。)，缺点就是如同Windows一样，宛如黑盒，换句话说，要时刻祈祷不要出问题，否则有时很难知道他为什么挂了。。。
最近碰到了一个oracle bug，但是我感觉还是有些运气的成分，虽然错误日志和bug描述吻合，版本也完全对应，现在有几个问题在我脑海中翻腾，就是这个问题是不是一个特例，是不是一些额外的原因导致的，于是我翻出了日志重新来看。 这是一个一主两备的环境，一个本地灾备，一个异地灾备，数据库版本是10.2.0.4.0，单实例 数据库日志如下： Redo Shipping Client Connected as PUBLIC -- Connected User is Valid RFS[8]: Assigned to
昨天聊了一篇关于高可用方案中Oracle的RAC和MySQL的MHA的对比。 今天来说下Oracle的DG和MySQL的方案对比，相比来说，可能这方面MySQL会单薄一些，所以文末会说下InnoDB Cluster。 在灾备的概念中，Oracle DBA喜欢叫做主备，即为Primary,Standby,而MySQL喜欢叫做主从，即为Master,Slave 首先在Oracle中，数据是基于物理复制（此处说的都是physical standby），所以对于数据库的状态和角色就很好定位，从库正常状况下是
数据库作为信息系统重要的基础设施，一直承担着压舱石的角色。互联网应用的高并发、海量数据使得数据库的负载越来越重，这在数据大集中的情况下愈发明显。而数据库作为信息系统唯一的“单点”，稳定性、可用性是首先要保证的目标。这里的单点并不是指数据库没有高可用方案，而是因为数据库只要涉及到数据的复制就一定是有状态的，有状态的应用更加难以运维，并且在遭遇异常时并不能做到真正意义上的无缝切换。
这是一个单实例数据库，oracle11.2.0.4 ，跑在Wondows上，当时主库压力太大，用户有容灾和读写分离的需求，这样在主库跑了一段时间后搭建了一个备库，这个备库一直跑到很好，最多主库由于存储压力，删除过几个归档日志，这个删除也是确认了备库应用之后操作的，对主备都已经没有影响。所以，当这家南方公司的负责人（我就称为王工）找到我时，我还是觉得意外。
客户的一套生产环境采用的架构是Oracle ADG + Keepalived，近期需要进行切换演练，要求我这边保障。ADG本身切换倒没啥可说的，但引入keepalived软件，就需要提前研究下这个架构。其实看了下环境配置，整体思路也非常简单，说白了就是利用keepalived软件引入一个VIP，应用侧只需配置连接这个VIP即可。 依据当前生产环境架构模拟了一套自己的测试环境。
墨墨导读：一个单节点RAC，要做一套Data Guard，但是备库能给数据库的内存只有主库的一半左右，可以实现吗？答案是可以的，本文详述整个过程。
今天在测试环境遇到一个很有意思的问题，我们在测试一款分布式数据库，这款分布式数据库底层是基于postgresql做的，现象大致是这样的，我们在重启数据库集群后发现某台机器的数据节点启动失败，然后去那台机器上发现进程确实没有启动。然后看了下运行日志，定位到了启动失败的原因，是内存不够用了，查了下该节点上还运行着其他数据库，由于其他数据库也占了一部分内存，造成该节点数据库由于内存不足启动失败。
在Data Guard环境中，主备库基本都是使用归档来传递数据的变化。如果主备的归档传输中断，同时主库的归档被删除或者损坏，这种情况下备库是没法开始继续接收归档，应用新的数据变更了。 看到网友paulyibin的文章中提到了SCN恢复的想法，感觉非常有意思，明白了思路，自己在本地也测试了一把，发现真是有趣。 一般来说，主库的归档丢失，常规的思路只能是重建备库了。其实我们可以换一个角度来看这个问题，数据的变化在归档中是一个连续的过程，而在日志文件，数据 文件中则是一个状态。我们可以
至于pg为什么不做这个功能我也想了很久，下面是我自己的一点猜测。pg是个追求完美主义的数据库，他从架构设计层面就会考虑如何做到完美，比如说他不用主流数据库都在使用的undo，我猜测这个原因是因为，使用undo有一个问题，undo空间不管是文件系统还是表空间都是有大小限制的，而数据库未提交的事务信息可能是无限大的，这样数据的前镜像总有可能将undo空间撑爆掉，这样就需要清理旧的undo段，如果需要查询的undo前镜像备清理了，数据库就会跑出错误，这就是oracle中经典的snapshot too old报错。所以pg摒弃了这种模式，因为他觉得必须要提供给用户一个需要的数据一定能查到的数据库，而不是本该能查到的数据被无端清理掉了，所以pg使用了多数据版本来解决这个问题，将前镜像的真实数据放在数据文件中，真正确保没有事务可能再去访问该数据时才进行清理。当然这样也带来膨胀的问题，这其实也是pg最遭人诟病的问题。
对于基于日志复制的主备数据库来说，由于配置不当或者备库空间问题造成主数据库的日志被自动清理，造成主备数据库同步中断，对于管理人员来说，也许就是一种失责甚至灾难(如果主发生故障),同样基于日志复制的同步软件来说，存在同样的问题，日志由于各种原因被删除,造成同步数据被中断，如果有定时备份日志，无非就是延迟的问题，如果无日志，可能重新初始化，尤其对于架构复杂以及多链路的复制，修复数据也是头疼事情。
对于orabbix报出的警报，自己都是心怀敬畏，因为这些表面的现象如果深入分析没准就能有所收获，当然目的还是解决问题，不是一味追求指标。 今天收到的报警邮件如下，然后在两分钟后问题自动恢复。 ### ZABBIX-监控系统: ------------------------------------ 报警内容: DG_issue ------------------------------------ 报警级别: PROBLEM ------------------------------------ 监控
随着客户上云的加快，客户越来越希望直接采用云上的数据库系统支撑业务发展，作为服务商来讲，了解云上的数据库的应用场景及常见特性成为必然。否则，将出现与客户交流困难，影响项目成效的麻烦事。今天我们讲五种常见的云数据库，这些内容也是在与客户沟通交流中的常见问题。
最近帮一些朋友处理了一些Oracle的问题，也从中发现了一些潜在的问题，索性总结出来作为借鉴。为了保证信息的敏感，里面的问题描述可能和真实情况不符，但是问题的处理方式是真实的。 问题1：Oracle备库无法启动 问题2：Oracle备库无法同步 问题3：主库添加数据文件后，备库MRP退出。 问题4：备库数据无法同步 问题1：Oracle备库无法启动 有一个数据库备库无法启动，这个问题听起来蛮有意思，这是一个套11g的数据库，其实可以先把备库置为read only，然后开启日志应用
Data Guard作为Oracle提供的一个高可用及灾备解决方案,理解并可以实施它对于DBA来说是非常重要套的技能
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
