它有无数个名字，有人叫它dg，有人叫它数据卫士，有人叫它data guard，在oracle的各项特性中它有着举足轻理的地位，它就是(掌声)......................Oracle Data Guard。而对于我而言，我一定要亲切的叫它：DG(注：主要是因为打着方便)。
不少未实际接触过dg的初学者可能会下意识以为dg是一个备份恢复的工具。我要说的是，这种形容不完全错，dg拥有备份的功能，某些情况下它甚至可以与primary数据库完全一模一样，但是它存在的目的并不仅仅是为了恢复数据，应该说它的存在是为了 确保企业数据的高可用性，数据保护以及灾难恢复 (注意这个字眼，灾难恢复) 。dg提供全面的服务包括：创建，维护，管理以及监控standby数据库 ， 确保数据安全 ， 管理员可以通过将一些操作转移到standby数据库执行的方式改善数据库性能 。后面这一长串大家可以把它们理解成形容词，千万不要被其花哨的修饰所迷惑，要抓住重点，要拥有透明现象看本质的能力，如果没有那就要努力学习去拥有，下面我来举一个例子，比如我们夸人会说它聪明勇敢善良等等，这些就属于形容词，不重要，重点在于我们究竟想形容这个人是好人还是坏人。然后再回来看看oracle对dg功能上的形容，数据保护和灾难恢复应该都可以归结为高可用性，那么我们可以清晰的定位dg的用途了，就是构建高可用的企业数据库应用环境。
一、 Data Guard配置(Data Guard Configurations)
Data Guard是一个集合，由一个primary数据库(生产数据库)及一个或多个standby数据库(最多9个)组成。组成Data Guard的数据库通过Oracle Net连接，并且有可能分布于不同地域。只要各库之间可以相互通信，它们的物理位置并没有什么限制，至于操作系统就更无所谓了(某些情况下)，只要支持oracle就行了。
你即可以通过命令行方式管理primary数据库或standby数据库，也可以通过Data Guard broker提供的专用命令行界面(DGMGRL)，或者通过OEM图形化界面管理。
1. Primary 数据库
前面提到，Data Guard包含一个primary数据库即被大部分应用访问的生产数据库，该库即可以是单实例数据库，也可以是RAC。
2. Standby 数据库
Standby数据库是primary数据库的复制(事务上一致)。在同一个Data Guard中你可以最多创建9个standby数据库。一旦创建完成，Data Guard通过应用primary数据库的redo自动维护每一个standby数据库。Standby数据库同样即可以是单实例数据库，也可以是RAC结构。关于standby数据库，通常分两类：逻辑standby和物理standby，如何区分，两类各有什么特点，如何搭建，这方面内容就是后面的章节主要介绍的，在这里呢三思先简单白话一下：
l 逻辑standby
就像你请人帮你素描画像，基本器官是都会有的，这点你放心，但是各器官位置啦大小啦肤色啦就不一定跟你本人一致了。
l 物理standby
就像拿相机拍照，你长什么样出来的照片就是什么样，眼睛绝对在鼻子上头。或者说就像你去照镜子，里外都是你，哇哈哈。具体到数据库就是不仅文件的物理结构相同，甚至连块在磁盘上的存储位置都是一模一样的(默认情况下)。
为什么会这样呢？这事就得从同步的机制说起了。逻辑standby是通过接收primary数据库的redo log并转换成sql语句，然后在standby数据库上执行SQL语句(SQL Apply)实现同步，物理standby是通过接收并应用primary数据库的redo log以介质恢复的方式(Redo Apply)实现同步。
另外，不知道大家是否注意到形容词上的细节：对于相机拍照而言，有种傻瓜相机功能强大而操作简便，而对于素描，即使是最简单的画法，也需要相当多的练习才能掌握。这个细节是不是也说明逻辑standby相比物理standby需要操作者拥有更多的操作技能呢？
二、 Data Guard服务(Data Guard Services)
l REDO传输服务(Redo Transport Services)
控制redo数据的传输到一个或多个归档目的地。
l Log应用服务(Log Apply Services)
应用redo数据到standby数据库，以保持与primary数据库的事务一致。redo数据即可以从standby数据库的归档文件读取，也可直接应用standby redo log文件(如果实时应用打开了的话)。
l 角色转换服务(Role Transitions)
Dg中只有两种角色：primary和standby。所谓角色转换就是让数据库在这两个角色中切换，切换也分两种：switchover和failover
switchover：转换primary数据库与standby数据库。switchover可以确保不会丢失数据。
failover：当primary数据库出现故障并且不能被及时恢复时，会调用failover将一个standby数据库转换为新的primary数据库。在最大保护模式或最高可用性模式下，failover可以保证不会丢失数据。
注：上述各概念简要了解即可，这里写的太简单，不要咬文嚼字，不然你会越看越糊涂，相关服务在后面章节将会有详细介绍，不仅有直白的描述，还会有示例，再加上浅显的图片，就算你一看不懂，再看肯定懂：）
三、 Data Guard保护模式(Data Guard Protection Modes)
对于Data Guard而言，其生存逻辑非常简单，好好活，做有意义的事，做黑多黑多有意义的事：）
由于它提供了三种数据保护的模式，我们又亲切的叫它：有三模：
l 最大保护(Maximum protection)：
这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其redo不仅被写入到本地的online redo log，还要同时提交到standby数据库的standby redo log，并确认redo数据至少在一个standby数据库可用(如果有多个的话)，然后才会在primary数据库上提交。如果出现了什么故障导致standby数据库不可用的话，primary数据库会被shutdown。
l 最高性能(Maximum performance)：
这种模式提供在不影响primary数据库性能前提下最高级别的数据保护策略。事务可以随时提交，当前primary数据库的redo数据也需要至少写入一个standby数据库，不过这种写入可以是不同步的。
如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护而仅对primary数据库有轻微的性能影响。
l 最高可用性(Maximum availability)：
这种模式提供在不影响primary数据库可用前提下最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求所有事务在提交前必须保障redo数据至少在一个standby数据库可用，不过与之不同的是，如果出现故障导入无法同时写入standby数据库redo log，primary数据库并不会shutdown，而是自动转为最高性能模式，等standby数据库恢复正常之后，它又会再自动转换成最高可用性模式。
最大保护及最高可用性需要至少一个standby数据库redo数据被同步写入。三种模式都需要指定LOG_ARCHIVE_DEST_n初始化参数。LOG_ARCHIVE_DEST_n很重要，你看着很眼熟是吧，我保证，如果你完完整整学完dataguard，你会对它更熟。
四、 Data Guard优点总结
l 灾难恢复及高可用性
l 全面的数据保护
l 有效利用系统资源
l 在高可用及高性能之间更加灵活的平衡机制
l 故障自动检查及解决方案
l 集中的易用的管理模式
l 自动化的角色转换
经常开篇的灌输，相信大家已经看的出来，上面这几条都是形容词，看看就好，记住更好，跟人穷白活的时候通常能够用上:)
同一个Data Guard配置包含一个 Primary 数据库和最多九个 Standby 数据库。 Primary的创建就不说了，Standby数据库初始可以通过primary数据库的备份创建。一旦创建并配置成standby后，dg负责传输primary数据库redo data到standby数据库，standby数据库通过应用接收到的redo data保持与primary数据库的事务一致。
一、 Standby数据库类型
前章我们简单介绍了Standby数据库，并且也知道其通常分为两类：物理standby和逻辑standby，同时也简短的描述了其各自的特点，下面我们就相关方面进行一些稍深入的研究：
1. 物理standby
我们知道物理standby与primary数据库完全一模一样(默认情况下，当然也可以不一样，事无绝对嘛)，Dg通过redo应用维护物理standby数据库。通常在不应用恢复的时候，可以以read-only模式打开，如果数据库指定了快速恢复区的话，也可以被临时性的置为read-write模式。
l Redo应用
物理standby通过应用归档文件或直接从standby系统中通过oracle恢复机制应用redo文件。恢复操作属于块对块的应用(不理解？那就理解成块复制，将redo中发生了变化的块复制到standby)。如果正在应用redo，数据库不能被open。
Redo应用是物理standby的核心，务必要搞清楚其概念和原理，后续将有专门章节介绍。
l Read-only模式
以read-only模式打开后，你可以在standby数据库执行查询，或者备份等操作(变相减轻primary数据库压力)。此时standby数据库仍然可以继续接收redo数据，不过并不会触发操作，直到数据库恢复redo应用。也就是说read-only模式时不能执行redo应用，redo应用时数据库肯定处于未打开状态。如果需要的话，你可以在两种状态间转换，比如先应用redo,然后read-only，然后切换数据库状态再应用redo，呵呵，人生就是循环，数据库也是一样。
l Read-write模式
如果以read-write模式打开，则standby数据库将暂停从primary数据库接收redo数据，并且暂时失去灾难保护的功能。当然，以read-write模式打开也并非一无是处，比如你可能需要临时调试一些数据，但是又不方便在正式库操作，那就可以临时将standby数据库置为read-write模式，操作完之后将数据库闪回到操作前的状态(闪回之后，Data Guard会自动同步，不需要重建standby)。
l 物理standby特点
Ø 灾难恢复及高可用性
物理standby提供了一个健全而且极高效的灾难恢复及高可用性的解决方案。更加易于管理的switchover/failover角色转换及最更短的计划内或计划外停机时间。
Ø 数据保护
应用物理standby数据库，Dg能够确保即使面对无法预料的灾害也能够不丢失数据。前面也提到物理standby是基于块对块的复制，因此对象、语句统统无关，primary数据库上有什么，物理standby也会有什么。
Ø 分担primary数据库压力
通过将一些备份任务、仅查询的需求转移到物理standby，可以有效节省primary数据库的cpu以及i/o资源。
Ø 提升性能
物理standby所使用的redo应用技术使用最底层的恢复机制，这种机制能够绕过sql级代码层，因此效率最高。
2. 逻辑standby
逻辑standby是逻辑上与primary数据库相同，结构可以不一致。逻辑standby通过sql应用与primary数据库保持一致，也正因如此，逻辑standby可以以read-write模式打开，你可以在任何时候访问逻辑standby数据库。同样有利也有弊，逻辑standby对于某些数据类型以及一些ddl,dml会有操作上的限制。
l 逻辑standby的特点：
除了上述物理standby中提到的类似灾难恢复，高可用性及数据保护等之外，还有下列一些特点：
Ø 有效的利用standby的硬件资源
除灾难恢复外，逻辑standby数据库还可用于其它业务需求。比如通过在standby数据库创建额外的索引、物化视图等提高查询性能并满足特定业务需要。又比如创建新的schema(primary数据库并不存在)然后在这些schema中执行ddl或者dml操作等。
Ø 分担primary数据库压力
逻辑standby数据库可以在更新表的时候仍然保持打开状态，此时这些表可同时用于只读访问。这使得逻辑standby数据库能够同时用于数据保护和报表操作，从而将主数据库从那些报表和查询任务中解脱出来，节约宝贵的 CPU和I/O资源。
Ø 平滑升级
比如跨版本升级啦，打小补丁啦等等，应该说应用的空间很大，而带来的风险却很小(前提是如果你拥有足够的技术实力。另外虽然物理standby也能够实现一些升级操作，但如果跨平台的话恐怕就力不从心，所以此项就不做为物理standby的特点列出了)，我个人认为这是一种值的推荐的在线的滚动的平滑的升级方式。
二、 Data Guard操作界面(方式)
做为oracle环境中一项非常重要的特性，oracle提供了多种方式搭建、操作、管理、维护Data Guard配置，比如：
l OEM(Oracle Enterprise Manager)
Orcale EM提供了一个窗口化的管理方式，基本上你只需要点点鼠标就能完全dg的配置管理维护等操作(当然三思仍然坚持一步一步学rman中的观点，在可能的情况下，尽可能不依赖视窗化的功能，所以这种操作方式不做详细介绍)，其实质是调用oracle为dg专门提供的一个管理器：Data Guard Broker来实施管理操作。
l Sqlplus命令行方式
命令行方式的管理，本系列文章中主要采用的方式。不要一听到命令行就被吓倒，data guard的管理命令并不多，你只需要在脑袋瓜里稍微挪出那么一小点地方用来记忆就可以了。
l DGMGRL(Data Guard broker命令行方式)
就是Data Guard Broker，不过是命令行方式的操作。
l 初始化参数文件
我感觉不能把参数化参数视为一种操作方式，应该说，在这里，通过初始化参数，更多是提供更灵活的Data Guard配置。
三、 Data Guard 的软硬件需求
1、 硬件及操作系统需求
l 同一个Data Gurid配置中的所有oracle数据库必须运行于相同的平台。比如inter架构下的32位linux系统可以与inter架构下的32位linux系统组成一组Data Guard。另外，如果服务器都运行于32位的话，64位HP-UX也可以与32位HP-UX组成一组Data Guard。
l 不同服务器的硬件配置可以不同，比如cpu啦，内存啦，存储设备啦，但是必须确保standby数据库服务器有足够的磁盘空间用来接收及应用redo数据。
l primary数据库和standby数据库的操作系统必须一致，不过操作系统版本可以略有差异，比如(linux as4&linux as5)，primary数据库和standby数据库的目录路径也可以不同。
2、 软件需求
l Data Guard是Oracle企业版的一个特性，明白了吧，标准版是不支持地。
l 通过Data Guard的SQL应用，可以实现滚动升级服务器数据库版本(要求升级前数据库版本不低于10.1.0.3)。
l 同一个Data Guard配置中所有数据库初始化参数：COMPATIBLE的值必须相同。
l P rimary数据库必须运行于归档模式 ，并且务必确保在primary数据库上打开FORCE LOGGING，以避免用户通过nologging等方式避免写redo造成对应的操作无法传输到standby数据库。
l P rimary和standby数据库均可应用于单实例或RAC架构下 ，并且同一个data guard配置可以混合使用逻辑standby和物理standby 。
l Primary和standby数据库可以在同一台服务器，但需要注意各自的数据文件存放目录，避免重写或覆盖。
l 使用具有sysdba系统权限的用户管理primary和standby数据库。
l 建议数据库必须采用相同的存储架构。比如存储采用ASM/OMF的话，那不分primarty或是standby也都需要采用ASM/OMF。
另外还有很重要一点，注意各服务器的时间设置，不要因为时区/时间设置的不一置造成同步上的问题 。
四、 分清某某REDO LOGS(Online Redo Logs, Archived Redo Logs, Standby Redo Logs)
黑多黑多的redo，想必诸位早已晕头并吐过多次了吧。哎，说实话我描述的时候也很痛苦。这块涉及到中英文之间的意会。我又不能过度白话，不然看完我这篇文章再看其它相关文档的相关概念恐怕您都不知道人家在说什么，这种误人子弟的事情咱不能干(也许干过，但主观意愿上肯定是不想的)，更何况咱也是看各乱杂七杂八文档被误过XXXXXXXXXXXXXXXXX次(X=9)，深受其害，坚决不能再让跟俺一样受尽苦楚，历经磨难的DDMM们因为看俺的文档被再次一百遍啊一百遍。
但是已到关键时刻，此处不把redo混清楚，后头就得被redo混了，所以这里我要用尽我全部的口水+目前为止我所有已成体系的认识再给大家浅显的白话一回。注：基础概念仅一笔带过，水太大了也不好，要响应胡书记号召，书写节约型笔记。
REDO：中文直译是重做，与UNDO对应(天哪又扯出个概念，你看不见我看不见我看不见我)。重做什么？为什么要重做呢？首先重做是oracle对操作的处理机制，我们操作数据(增册改)并非直接反映到数据文件，而是先被记录(就是online redo log喽)，等时机合适的时候，再由相应的进程操作提交到数据文件(详细可见： 数据写过程中各项触发条件及逻辑)。你是不是想说如果把所有的online redo logs都保存下来，不就相当于拥有了数据库做过的所有操作了吗？en，我可以非常负责任的告诉你，你说的对，oracle跟你想到一块去了并且也将其实现了，这就是archived redo logs，简称archive log即归档日志。我们再回来看Data Guard，由于standby数据库的数据通常都来自于primary数据库，怎么来的呢，通过RFS进程接收primary数据库的redo，保存在本地，就是Standby redo logs喽，然后standby数据库的ARCn再将其写入归档，就是standby服务器的archived redo logs。保存之后数据又是怎么生成的呢，两种方式，物理standby通过redo应用，逻辑standby通过sql应用，不管是哪种应用，应用的是什么呢？是redo log中的内容(默认情况下应用archived redo logs，如果打开了实时应用，则直接从standby redo logs中读取)，至于如何应用，那就是redo应用和sql应用机制的事情了(也许后头我们会深入聊一聊这个话题，很复杂也很有趣)。
针对上述内容我们试着总结一下，看看能否得出一些结论：
对于primary数据库和逻辑standby数据库，online redo log文件肯定是必须的，而对于物理standby是否还需要redo log呢？毕竟物理standby通常不会有写操作，所以物理standby应该不会生成有redo数据。为保证数据库的事务一致性必然需要有归档，也就是说不管primary或standby都必须运行于归档模式。
standby redo logs是standby数据库特有的文件(如果配置了的话)，就本身的特点比如文件存储特性，配置特性等等都与online redo logs非常类似，不过它存储的是接收自primary数据库的redo数据，而online redo logs中记录的是本机中的操作记录。
上面的描述大家尽可能意会，能够理解最好，理解不了也没关系，我始终认为，只要坚定不移的学习下去，总会水到渠成。下面进入实战章节，先来个简单的，创建物理standby。
一、 准备工作
不管物理standby还是逻辑standby，其初始创建都是要依赖primary数据库，因为这个准备工作中最重要的一部分，就是对primary数据库的配置。
1、 打开Forced Logging模式
将primary数据库置为FORCE LOGGING模式。通过下列语句：
SQL> alter database force logging;
提示：关于FORCE LOGGING
想必大家知道有一些DDL语句可以通过指定NOLOGGING子句的方式避免写redo log(目的是提高速度，某些时候确实有效)，指定数据库为FORCE LOGGING模式后，数据库将会记录除临时表空间或临时回滚段外所有的操作而忽略类似NOLOGGING之类的指定参数。如果在执行force logging时有nologging之类的语句在执行，则force logging会等待直到这类语句全部执行。FORCE LOGGING是做为固定参数保存在控制文件中，因此其不受重启之类操作的影响(只执行一次即可)，如果想取消，可以通过alter database no force logging语句关闭强制记录。
2、 创建密码文件(如果不存在的话)
需要注意的是，同一个Data Guard配置中所有数据库必须都拥有独立的密码文件，并且必须保证同一个Data Guard配置中所有数据库服务器的SYS用户拥有相同密码以保证redo数据的顺利传输，因为redo传输服务通过认证的网络会话来传输redo数据，而会话使用包含在密码文件中的SYS用户密码来认证。
3、 配置Standby Redo Log
对于最大保护和最高可用性模式，Standby数据库必须配置standby redo log，并且oracle推荐所有数据库都使用LGWR ASYNC模式传输，当然你现在可能还不知道LGWR ASYNC是什么问题，没关系，你很快就会知道了。
Oracle建议你在创建standby时就考虑standby redolog配置的问题。standby redologs与online redologs非常类似，应该说两者只是服务对象不同，其它参数属性甚至操作的命令格式几乎都一样，你在设计standby redologs的时候完全可以借鉴创建online redologs的思路，比如多个文件组啦，每组多个文件冗余之类的。除些之外呢，oracle提供了一些标准的建议如下：
l 确保standby redo log的文件大小与primary数据库online redo log文件大小相同。
这个很好理解的吧，就是为了接收和应用方便嘛。
l 创建适当的日志组
一般而言，standby redo日志文件组数要比primary数据库的online redo日志文件组数至少多一个。推荐standby redo日志组数量基于primary数据库的线程数(这里的线程数可以理解为rac结构中的rac节点数)。
有一个推荐的公式可以做参考：(每线程的日志组数+1)*最大线程数
例如primary数据库有两个线程，每个线程分配两组日志，则standby日志组数建议为6组，使用这个公式可以降低primary数据库实例LGWR进程锁住的可能性。
提示：逻辑standby数据库有可能需要视工作量增加更多的standby redo log文件(或增加归档进程)，因为逻辑standby需要同时写online redo log文件。
Standby redo log的操作方式与online redo log几乎一模一样，只不过在创建或删除时需要多指定一个standby关键字，例如添加：
SQL> alter database add standby logfile group 4 ('e:ora10goradatajsspdgSTANDBYRD0 1 .LOG') size 20 M;
删除也同样简单：
SQL> alter database drop standby logfile group 4;
另外，从可靠性方面考虑，建议在primary数据库也创建standby redologs，这样一旦发生切换，不会影响primary做为standby的正常运行。
验证standby redo log文件组是否成功创建
例如：
SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;
4、 设置初始化参数
对于primary数据库，需要定义几个primary角色的初始化参数控制redo传输服务，还有几个附加的standby角色的参数需要添加以控制接收redo数据库并应用(switchover/failover后primary/standby角色可能互换，所以建议对于两类角色 相关的 初始化参数都进行配置)。
|
下列参数为primary角色相关的初始化参数： |
|
|
DB_NAME |
注意保持同一个Data Guard中所有数据库DB_NAME相同。 例如：DB_NAME=jssweb |
|
DB_UNIQUE_NAME |
为每一个数据库指定一个唯一的名称，该参数一经指定不会再发生变化，除非你主动修改它。 例如：DB_UNIQUE_NAME=jssweb |
|
LOG_ARCHIVE_CONFIG |
该参数通过DG_CONFIG属性罗列同一个Data Guard中所有DB_UNIQUE_NAME(含primary db及standby db)，以逗号分隔 例如：LOG_ARCHIVE_CONFIG='DB_CONFIG=(jssweb,jsspdg)' |
|
CONTROL_FILES |
没啥说的，控制文件所在路径。 |
|
LOG_ARCHIVE_DEST_n |
归档文件的生成路径 。该参数非常重要，并且属性和子参数也特别多(这里不一一列举，后面用到时单独讲解如果你黑好奇，建议直接查询oracle官方文档。Data guard白皮书第14章专门介绍了该参数各属性及子参数的功能和设置)。 例如： LOG_ARCHIVE_DEST_1= 'LOCATION=E:ora10goradatajssweb VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=jssweb' |
|
LOG_ARCHIVE_DEST_STATE_n |
指定参数值为ENABLE，允许redo传输服务传输redo数据到指定的路径。 该参数共拥有4个属性值，功能各不相同。 |
|
REMOTE_LOGIN_PASSWORDFILE |
推荐设置参数值为EXCLUSIVE或者SHARED，注意保证相同Data Guard配置中所有db服务器sys密码相同。 |
|
LOG_ARCHIVE_FORMAT |
指定归档文件格式。 |
|
| |