第一部分基础2之术语再了解大概 2007.11.29
同一个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 模式打开，如果数据库指定了flashback area 的话，也可以被临时性的置为read-write 模式。
● Redo 应用
物理standby 通过应用归档文件或直接从standby 系统中通过oracle 恢复机制应用redo 文件。恢复操作属于块对块的应用(不理解？那就理解成块复制，将redo 中发生了变化的块复制到standby)。如果正在应用redo，数据库不能被open。
Redo 应用是物理standby 的核心，务必要搞清楚其概念和原理，后续将有专门章节介绍。
● Read-only 模式
以read-only 模式打开后，你可以在standby 数据库执行查询，或者备份等操作(变相减轻primary数据库压力)。此时standby 数据库仍然可以继续接收redo 数据，不过并不会触发操作，直到数据库恢复redo 应用。也就是说read-only 模式时不能执行redo 应用，redo 应用时数据库肯定处于未打开状态。如果需要的话，你可以在两种状态间转换，比如先应用redo,然后read-only，然后切换数据库状态再应用redo，呵呵，人生就是循环，数据库也是一样。
● Read-write 模式
如果以read-write 模式打开，则standby 数据库将暂停从primary 数据库接收redo 数据，并且暂时失去灾难保护的功能。当然，以read-write 模式打开也并非一无是处，比如你可能需要临时调试一些数据，但是又不方便在正式库操作，那就可以临时将standby 数据库置为read-write 模式，操作完之后将数据库闪回到操作前的状态(闪回之后，Data Guard 会自动同步，不需要重建standby)。
● 物理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 会有操作上的限制。
● 逻辑standby 的特点：
除了上述物理standby 中提到的类似灾难恢复，高可用性及数据保护等之外，还有下列一些特点：
→ 有效的利用standby 的硬件资源
除灾难恢复外，逻辑standby 数据库还可用于其它业务需求。比如通过在standby 数据库创建额外的索引、物化视图等提高查询性能并满足特定业务需要。又比如创建新的schema(primary 数据库并不存在)然后在这些schema 中执行ddl 或者dml 操作等。
→ 分担primary 数据库压力
逻辑standby 数据库可以在更新表的时候仍然保持打开状态，此时这些表可同时用于只读访问。这使得逻辑standby 数据库能够同时用于数据保护和报表操作，从而将主数据库从那些报表和查询任务中解脱出来，节约宝贵的CPU 和I/O 资源。
→ 平滑升级
比如跨版本升级啦，打小补丁啦等等，应该说应用的空间很大，而带来的风险却很小(前提是如果你拥有足够的技术实力。另外虽然物理standby 也能够实现一些升级操作，但如果跨平台的话恐怕就力不从心，所以此项就不做为物理standby 的特点列出了)，我个人认为这是一种值的推荐的在线的滚动的平滑的升级方式。
二、DataGuard操作界面(方式)
做为oracle 环境中一项非常重要的特性，oracle 提供了多种方式搭建、操作、管理、维护Data Guard 配置，比如：
● OEM(Oracle Enterprise Manager)
Orcale EM 提供了一个窗口化的管理方式，基本上你只需要点点鼠标就能完全dg 的配置管理维护等操作(当然三思仍然坚持一步一步学rman 中的观点，在可能的情况下，尽可能不依赖视窗化的功能，所以这
种操作方式不做详细介绍)，其实质是调用oracle 为dg 专门提供的一个管理器：Data Guard Broker 来实施管理操作。
● Sqlplus 命令行方式
命令行方式的管理，本系列文章中主要采用的方式。不要一听到命令行就被吓倒，data guard 的管理命令并不多，你只需要在脑袋瓜里稍微挪出那么一小点地方用来记忆就可以了。
● DGMGRL(Data Guard broker 命令行方式)
就是Data Guard Broker，不过是命令行方式的操作。
● 初始化参数文件
我感觉不能把参数化参数视为一种操作方式，应该说，在这里，通过初始化参数，更多是提供更灵活的Data Guard 配置。
三、DataGuard的软硬件需求
1、硬件及操作系统需求
● 同一个Data Gurid 配置中的所有oracle 数据库必须运行于相同的平台。比如inter 架构下的32 位linux 系统可以与inter 架构下的32 位linux 系统组成一组Data Guard。另外，如果服务器都运行于32 位的话，64 位HP-UX 也可以与32 位HP-UX 组成一组Data Guard。
● 不同服务器的硬件配置可以不同，比如cpu 啦，内存啦，存储设备啦，但是必须确保standby 数据库服务器有足够的磁盘空间用来接收及应用redo 数据。
● primary 数据库和standby 数据库的操作系统必须一致，不过操作系统版本可以略有差异，比如(linuxas4&linux as5)，primary 数据库和standby 数据库的目录路径也可以不同。
2、软件需求
● Data Guard 是Oracle 企业版的一个特性，明白了吧，标准版是不支持地。
● 通过Data Guard 的SQL 应用，可以实现滚动升级服务器数据库版本(要求升级前数据库版本不低于10.1.0.3)。
● 同一个Data Guard 配置中所有数据库初始化参数：COMPATIBLE 的值必须相同。
● Primary 数据库必须运行于归档模式，并且务必确保在primary 数据库上打开FORCE LOGGING，以避免用户通过nologging 等方式避免写redo 造成对应的操作无法传输到standby 数据库。
● Primary 和standby 数据库均可应用于单实例或RAC 架构下，并且同一个data guard 配置可以混合使用逻辑standby 和物理standby。
● Primary 和standby 数据库可以在同一台服务器，但需要注意各自的数据文件存放目录，避免重写或覆盖。
● 使用具有sysdba 系统权限的用户管理primary 和standby 数据库。
● 建议数据库必须采用相同的存储架构。比如存储采用ASM/OMF 的话，那不分primarty 或是standby也都需要采用ASM/OMF。
另外还有很重要一点，注意各服务器的时间设置，不要因为时区/时间设置的不一置造成同步上的。
四、分清某某REDOLOGS(OnlineRedoLogs,ArchivedRedoLogs,StandbyRedoLogs)
黑多黑多的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 喽(arch 模式的话不写standby redo，直接保存归档)，然后standby 数据库的相关进程读取接收到的redo 数据，再将其写入standby 数据库。保存之后数据又是怎么生成的呢，两种方式，物理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。