DataGuard，数据卫士，一种数据库级别的高可用性（HA）方案，用作数据容灾解决方案。对于联机事务处理（OLTP，数据量不太大）非常合适，对于联机分析处理（OLAP，数据量太大），只能选择关键数据创建DG，常规数据，选择其他方式备份。
Data Guard broker是建立在Data Guard基础上的一个对Data Guard配置，集中管理操作的一个平台.我们再上次DG主备切换的时候会发现特别麻烦,为此broker出来了。
DG提供了3种数据保护模式（Protection Mode）：最大保护（Maximum Protection）、最高性能（Maximum Performance）和最高可用（Maximum Availability），如下表所示：
本篇梳理DG的架构和一些概念知识，重新梳理的目的是加强理解，也方便复习，基于11gR2版本写的，不包含12c新特性。如果能帮助到新接触DG的朋友，那就再好不过。
我们帮助行业客户进行上云业务迁移，Oracle的业务数据迁移几乎成了必然遇到的问题。对Oracle的数据高可用，作为云架构师，应该说是必须懂。今天我们从入门开始，介绍一些常见的问题。
（1）使用SID，jdbc:oracle:thin:@host:port:SID，例如
DG Broker 是 Oracle 为 Data Guard 维护提供的一个很不错的工具，早期的版本中似乎大家都还是存在一定的思维定式，认为手工维护已经足够了。这个工具就不那么需要了，我们完全可以脱离开这些工具来直观的使用命令行的方式来维护，这个观点也没错，不过从与时俱进的角度来看，本来能够让你更轻松的一个工具，如果不用实在是太可惜了。
近期我们在DBASK小程序新关联了韩锋频道、互联网侦察、数据库SQL、SQL数据库开发、跨界架构师、石杉的架构笔记等数据领域的公众号，聚合更新展示，欢迎大家阅读分享。
墨墨导读：本文来自墨天轮用户投稿，介绍使用RMAN duplicate搭建12C的Data Guard环境的全过程。
作者介绍 黄堋 多年一线DBA经验，曾服务于电信、电网、医院等行业客户。擅长数据库优化、数据库升级迁移、数据库故障处理 当主备同步中断了，备库想快一点恢复，偏偏这个时候归档太多恢复不过来或者说需要的归
近期在某银行生产环境做的一次PDB迁移，使用的是PDB refresh方式，记录一下流程及遇到的坑。
Oracle自发布12.1之后，就一直声称要全面转云，在之后的三四年里，一直杳无音信，大家都在猜测，Oracle又在憋什么大招，果然，2017阳春三月，大招来了！今年三月份，在广大用户的热切盼望中，O
DG 的工作原理是通过网络将主数据库的重做数据传输到备用数据库，然后在备用数据库上应用这些重做数据，以确保数据的一致性。
主库（Primary Database）在运行过程中，会源源不断地产生Redo日志，这些日志需要发送到备库（Standy Database）端。这个发送动作可以由主库的LGWR或者ARCn进程完成，不同的归档目的地可以使用不同的方法，但是对于一个目的地，只能选用一种方法。选择不同的进程在数据保护能力和系统可用性方面有很大区别。如果使用LGWR进程来传递日志，但是由于某些原因，LGWR进程变得无法归档到目的地了，那么重做传输将会使用ARCn进程来完成归档操作。
高可用（High Availability，HA）也可以称为高可用性或高可用环境。HA是分布式系统架构设计中必须考虑的因素之一。HA通常是指通过设计来减少系统不能提供服务的时间。假设系统一直能够提供服务，那么这时就可以称系统的可用性是100%。如果系统每运行100个时间单位，会有1个时间单位无法提供服务，那么可以称系统的可用性是99%。很多公司（例如三大运营商、百度、京东等）的高可用目标都是4个9，也就是99.99%。
在上云后的Oracle数据灾备场景中，我们经常听到DBA迁移工程师讲到“在这个项目中用ADG进行数据实时备份，ADG比DG更好！”。究竟ADG作Oracle数据灾备的优势在什么地方？
文件按分配单元AUs(allocation units)平衡分布在磁盘组的所有磁盘中，ASM使用索引技术来跟踪每个AUs的位置
DG根据备库（Standby Database）重演日志方式的不同，可以分为物理DG（Physical DG）、逻辑DG（Logical DG）和快照DG（Snapshot DG），它们对应的数据库分别可以称为Physical Standby、Logical Standby和Snapshot Standby。
RFS（Remote File Server）进程主要用来接受从主库传送过来的日志信息。对于物理备库而言，RFS进程可以直接将日志写进Standby Redo logs，也可以直接将日志信息写到归档日志中。一般可以在主备库的告警日志中看到如下的信息：
今天下午我的一个朋友碰到了一个Data Guard的问题，大体是主备网络出现问题，因为环境中配置了自动切换，结果备库就自动切换为了主库，这样就成了“双主”，我帮忙看了下，对备库做了闪回，然后直接转换主库为备库角色，一个看似繁琐的修复工作就完成了。 在一个一主多备的环境中，的确需要一个强大的工具来支持，所以最后朋友说DG Broker真是个好东西，我回了句 用好了DG Broker,手工管理Data Guard就是小米加步枪啊。 就如同我昨天文章Data Guard故障自动切换的想法(r11
对于DBA来说，面对误操作带来的数据恢复难度，其实很大。主要有以下几个方面： 误操作的影响范围极大，很可能不是删点，改点数据的操作，有时候可能是让人望而兴叹的truncate,drop操作。 数据恢复时需要确认数据损坏的时间点，依此来作为数据恢复的一个基准，该舍弃多少数据，该如何权衡，非常关键。 一旦信息提供错误，是否经得起反复折腾，我想这个对于绝大多数的数据恢复而言，基本都是一锤子买卖，能恢复已经不错了，还要反复恢复。但是一旦出现这种情况，可不能马上乱了阵脚。 灾备方案好不好，一试便知 自己也
在最近的一个大型项目中，用户提到由我们云提供商进行Oracle数据库的备份、迁移集成工作，是选择用DG、还是RMAN？我们今天来分析一下。
Data Guard作为Oracle提供的一个高可用及灾备解决方案,理解并可以实施它对于DBA来说是非常重要套的技能
dataguard broker是在dataguard使用基础上提供的一个工具，可以把原本复杂的命令控制语句集成起来，比如switchover,failover等等，可能在多个备库的情况下需要敲不少的命令，这个dg broker的优越性就显示出来了。 当然dg broker需要启用还是需要预备一些条件的，比如需要设置local_listener,需要在spfile的基础上，需要在网络配置中进行dgmgrl相关的标示。 应该是在内部实现中默认拥有这些配置。 我们先来看看一个简单的配置情况。 首先启用dg br
环境： 主库A机：在线生产环境，RHEL 6.4 + Oracle 11.2.0.3 备库B机：新增备机，RHEL 6.4 需求： 对生产环境最小影响前提下配置DG备库。 目录： 一、B机安装相同版本Oracle软件 二、A机，B机配置网络连接
今天在一台机器上模拟了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 --强制
DISCONNECT FROM SESSION子句并非必需，该子句的作用是指定启动完应用后自动退出到命令操作符前。如果不指定该子句的话，那么当前SESSION就会一直停留处理Redo应用，如果想做其它操作，那么就只能新建一个连接。
参考自：Data Guard Physical Standby Setup in Oracle Database 11g Release 2
一键安装脚本可参考：ORACLE一键安装单机11G/12C/18C/19C并建库脚本
首先，DG（Data Guard，数据卫士）不是一个备份恢复的工具，然而，DG却拥有备份的功能，在物理DG下它可以和主库一模一样，但是它存在的目的并不仅仅是为了备份恢复数据，应该说它的存在是为了确保企业数据的高可用性，数据保护以及灾难恢复。DBA可以通过将一些操作（例如查询报表）转移到备库执行的方式来减小主库的压力，构建高可用的企业数据库应用环境。
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';
编辑手记：在Oracle DG中，从主库到备库的日志传输有sync和async两种方式，sync的方式能够实现数据实时传输，但如果遇到网络中断等原因，就可能导致数据丢失。因此，在Oracle 12c中
本文讲解在Oracle Database 19c中使用Data Guard Broker进行Data Guard物理备用库配置。
最近的工作中需要基于Oracle连接到SQLserver2014，我们可以通过配置Gateway的方式来实现这个功能。这个Gateway的实质是透过dblink来实现的。即把SQLserver模拟成一个远端的Oracle实例，这个实例由Gateway来负责进行接收，转发等等。本文简要描述其配置过程。
在实际的工作过程中，由于ASM磁盘管理的便利性，因此很多时候需要将文件系统的数据库迁移到ASM，本文演示了如何将文件系统数据库迁移到ASM实例。
单实例环境--standby CentOS release 6.10 (Final) hostname dg1 ip 10.*.30 Instance_name cad DB_NAME bol --此次2个一样 db_unique_name cad
今天行程还是比较匆忙，刚回到家，打开微信就收到了几个问题，有不少是和迁移相关的，我选出几个，还有几个需要好好考虑一下。 问题1: 我们的多个业务系统都是Oracle的数据库，每个业务都搭了dg，各占两台服务器，但是学校的业务量不大，想把这些库迁到一台服务器上，我现在的知识量只能想到用虚拟机，但是又觉得虚拟机不是很可靠，所以想让您指点一下 答： 对于这种情况，其实迁移方式有三种， 1）因为业务量不大，可以把几个系统的迁移到一台物理机器上，或者主备重新平衡。比如三套业务系统，那么一主一备就是6台服务器，比如一
经过交流群中朋友的多次要求，这次给大家分享一下 RAC to Single 的 ADG 搭建教程！
3、主库必须添加Standby Redo Log Files，其大小应该和Online Redo Log Files的大小一致。另外，Standby日志组的个数应满足以下条件：
Oracle 12c中DBCA有一个特性看起来蛮有意思，就是直接通过DBCA来搭建Data Guard,当然这么说也有点噱头，我们来实际看看。 Oracle提供的官方命令结构如下： dbca -createDuplicateDB -gdbName global_database_name -primaryDBConnectionString easy_connect_string_to_primary -sid database_s
ASM磁盘是ASM体系结构的重要组成部分，ASM磁盘由ASM实例来定位、管理，本文主要讲述ASM磁盘组、故障组等等。
在很多情况下，或无法使用dbca工具的时候，我们需要手动来删除数据库。对此，可以借助drop database命令来实现，下面的描述中给出手动删除数据库
Oracle Data Guard是Oracle MAA(Maximum Availability Architecture)中的成员之一，也是MAA中技术要求最简单的方案之一。随着Oracle新功能的引入如Active Standby Database后，加速了Oracle Data Guard的普及。响应去I的趋势和X86架构的流行，对Oracle Data Guard的普及更起到了锦上添花的影响。
条件：1、误强制删除linux下的数据文件（rm -rf）。2、未重启数据库或操作系统。3、数据库是归档模式
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
