DATA GUARD的最主要的功能是冗灾。当然根据配置的不同,DATA GUARD还可以具备以下特点：高可用、性能提升、数据保护以及故障恢复等。
DATA GUARD可以分为物理STANDBY和逻辑STANDBY两种。二者的最大差别在于，物理STANDBY应用的是主库的归档日志，而逻辑STANDBY 应用的是主库的归档日志中提取的SQL语句。由于二者这一点的区别，决定了物理STANDBY无论从逻辑结构和物理结构都是和主库保持一致，而逻辑 STANDBY则只需保证逻辑结构一致，且逻辑STANDBY在应用SQL语句的时候，数据库可以处于打开的状态。
如果从DATA GUARD的保护模式分，可以分为三种不同的保护模式：
保护最大化：这种模式的配置可以保证主库和备库的同步，任何情况下主库的损毁都不会导致已提交数据的丢失。如果主库和备库之间的网络出现问题，或者备库本身出现问题，都会导致主库停止数据处理。
可用最大化：这种模式和上面一种类似，也是会保证主库和备库的同步，区别在于，当网络或备库不可用时，主库仍然可以继续处理。
性能最大化：主库和备库是异步的。这种模式可能在主库出现损毁时，丢失一部分数据。但是这种模式对主库负荷最小，因此具有最好的性能
=============================================================================================================
Data guard是Oracle 推出的一种高可用性(HIGH AVAILABLE)的数据库方案,在8i之前称之为standby database，从9i开始，正式更名为Data guard，它是在主节点与备用节点间通过日志同步来保证数据的同步，可以实现快速切换与灾难性恢复。Data guard只是在软件上对数据库进行设置，并不需要额外购买任何组件能在对主数据库影响很小的情况下，实现主备数据库的同步，而主备机的数据差异只在在线日志部分，所以被不少企业作为了数据容灾方案。
ORACLE 从7.3推出standby database，7.3.x-8.0.x 需要手工拷贝所有归档日志并手工同步，从ORACLE815 开始，开始支持多节点复制，并实现了自动同步，但是这种同步是数据异步模式的，可能引起数据丢失。从ORACLE9i开始，备用服务器已经换了一种新的称呼，叫数据保护(DATA GUARD)，在这种模式中，开始支持三种不同的数据保护模式，并开始采用LGWR 对数据的传送而不是以往的ARCH，而且增加了一个新的后台进程叫DMON 监控数据的同步，支持多达9个节点的同时复制。从920开始，还开始支持逻辑备用服务器。
本文通过笔者对公司北京地区制造业客户Data Guard的使用发展情况来阐述oracle这一新技术在制造业数据库应用中的推广普及以及从单纯的max performance的physical data guard的数据库容灾保护到逻辑 Data Guard等新特性的增值使用。
说到这边我们不得不简单的描述下制造业系统数据库的使用特性，制造业生产用数据库前端应用一般以各类ERP,MES 及shop floor系统为多，目前我们维护客户中以MES，shop floor为多，这类生产类的系统一般是24x7不间断运行，应用以OLTP为主且会定期月结时或实时的run大量的report,在高可用性方面会要求 低downtime最好不能超过半小时，资料丢失一般最多容忍也就15分钟。
纵观前几年苏州地区制造业的Oracle数据库系统几乎都是单机运行的数据库，最多加上Cluster的双机热备，但是双机热备其实不能真正意思上
保障到数据库系统的安全，该HA只是保障了server故障及维护时的数据库的高可用性，对oracle database来说没有任何保障。
这就是利用os cluster或某些第三方的软件也实现了集群功能，如ClusterWizard双机集群容错软件、AFS/2000高可用备援系统等。这些系统一般通过RS232联机或内部网络联机做心跳线，检测主机状态，一旦发现主机宕机，则接管主机的IP，并且重新启动应用程序，达到减少宕机时间的目的。
后来随着oracle HA技术的发展，standby技术的完善以及oracle
database委外服务的盛行，专业顾问服务公司专业技术及理念的注入，让制造业在database容灾方面有了很大的改善，硬件成本的降低各家公司开
始在HA 的机制上局部加入physical data guard的容灾功能，此阶段的制造业生产系统的数据库均为cluster +
physical Data guard架构这样既保障了主机维护高可用性又保障了DB损毁对生产造成的影响。另standby db还可以代替主库备份以分担备份所消耗的性能。
Data Guard运行要求:
1.主机必需运行在归档模式下。
2.主备数据库的版本必须一样，操作系统必须一样，版本可不同,主备机可使用不同的目录结构。
3.主备机必须都要运行在32位或64位下。
4.主库避免nologing的方式，这样会导致备机无法与主机同步。
Physical standby database
物理备用机在物理上和主据库的结构完全一样。也就是说，物理备机除了control
文件和主机不一样以及在线日志是可选的以外，其他都和主数据库一样。物理备机是靠应用主机所产生的归档文件来实现主备的一致。归档日志从主数据库通过网络
传到备库上，并在备机上应用传过来的归档文件，以实现两台机的同步。 物理备用机有两种模式：Managed recovery
mode归档文件从主数据传到备用数据库，log apply services把这些日志应用到备用数据库中。Read only
mode这种模式可供用户只读的操作数据库，归档日志仍然会从主数据库传到备用数据库，但Log
apply services不可以把这些日志应用到备用数据库中。
Logical standby database
除了physical data guard,9i R2又推出logical data guard, 逻辑备用机在逻辑上和主库一样，也就是说，两台服务器的
表、视图等对像需要保持一致，对物理结构上则不需要保持一致。逻辑备用机是靠把主机传过来的归档日志通过logminer解析成SQL语句，并应用到备用
机上来进行更新的，与物理备用机不同的是它可以在更新的同时对数据库进行查询，这个可以进行近实时(差异一个current
redo)数据库查询的功能对制造业生产系统的run
report应用与其他应用分开以减轻主库的负担有很大帮助。就目前来看各企业数据库的性能瓶颈均在月结或实时的report查询未与生产应用分开导致阶
段性的performance较差，logical standby的这种近实时的run report的功能对性能改善有很大的帮助。
但是很大程度上，而logical的方式则是需要把所有的归档转换成SQL语句再在logical standby
database上执行它。这会占用一定的系统资源，如CPU，memory,I/O等，另外一点就是9i的logical
standby相对来说bug限制等较多，还有就是不是很稳定，所以很少有企业在生产系统中使用，但是9i R2后几个patch针对logical
DG修正了不少的bug,加上生产系统相对简单的,较少特殊运用的特性，故logical的近实时查询功还是有很好的可以用性，再加上专业的规划，制度化
的管理相对来说这种技术还是值得推广使用的。
值得高兴的是在我们的精心准备及规划下苏州地区某大型制造业终于成为第一个吃螃蟹的，在正式的生产系统中运用了logical
standby,正是这种近实时查询功能弥补了应用上的不足，解决了原系统I/O严重的问题，所有的report均至logical standby
端实时查询，在功能未受影响的同时，因为不同应用在2个DB内完成所以I/O大大降低，性能得到很大的改善。加上logical
standby设计合理，管理上的规范目前该系统上线以来运行稳定。此项目的成功对苏州地区制造业对此项新技术的广泛运用有很大推动作用。
10g Data Guard
无论是8i的standby还是9i的Data Guard, Physical Standby
Database只可以处于两种状态:mount和read-only,在处于mount状态时,可以手动或自动恢复archived
logs,但是处于read-only模式时,不能恢复archived logs. logical standby database
也必须是从已收到的archived
logs中解析出SQL语句恢复,也就是说,即使无数据丢失,在standby数据库上,用户获得的数据时落后实纪生产数据库的旧的资料.是近实时的数据
(差一个current
redo).10g的data guard, logical standby database也支持了standby redo
logs的物理结构,允许一个实时恢复的进程与MPR或者LSP进程一起工作,,直接将standby redo
logs中刚刚收到的primary数据库的redo日志内容恢复到物理或逻辑standby数据库上面,使得用户在standby数据库运行报告的信息
是primary database的实时信息.
另外新增的实时恢复功能也可使数据库的switchover或者failover过程的时间大大缩短,系统的高可用性能大大的提高.Flashback
Database standby数据库就可以恢复到一个指定的时间点,避免因为人为的错误带来的数据丢失,加上10G的Data Guard
图形管理功能进一步完善,管理起来会更容易,EM管理,可使Switchover/failover功能,单击鼠标就可以完成.
最后总结下data guard的优点
1.支持所有的DDL和DML语句
2.不管是什么数据类型、表的类型，任何DDL和DML语句都可以应用在物理备用数据库上。
3.可以减轻主数据库的备份压力
4.standby的中的数据文件可以用来快速恢复主数据库的数据文件
5.逻辑standby可以减轻主数据库的工作压力
6.物理standby也可以用只读来打开，可以分担一部分非实时的查询的工作
7.逻辑standby数据是近实时更新的，而且也可以让用户进行查询操作
8.逻辑standby可以在standby中建立索引和物化视图以方便用户的查询
人们的观念中,容灾所谓的火灾,地震之类的灾难是乎是很遥远的.但911后,人们开始对主要的系统制定紧急的计划.自动化的data guard开始被广泛的使用起来.加上data guard功能的不断改进使得这项实用的技术能个逐渐被接受且广泛的应用起来，从制造业集中的北京各大企业的data guard的应用演变来说这种经济实用的技术正越来越得到制造业的青睐。
====================================================================-
它有无数个名字，有人叫它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，如何区分，两类各有什么特点，如何搭建，这方面内容就是后面的章 节主要介绍的，在这里呢三思先简单白话一下：
* 逻辑standby
就像你请人帮你素描画像，基本器官是都会有的，这点你放心，但是各器官位置啦大小啦肤色啦就不一定跟你本人一致了。
* 物理standby
就像拿相机拍照，你长什么样出来的照片就是什么样，眼睛绝对在鼻子上头。或者说就像你去照镜子，里外都是你，哇哈哈。具体到数据库就是不仅文件的物理结构相同，甚至连块在磁盘上的存储位置都是一模一样的(默认情况下)。
为什么会这样呢？这事就得从同步的机制说起了。逻辑standby是通过接收primary数据库的redo log并转换成sql语句，然后在standby数据库上执行SQL语句(SQL Apply)实现同步，物理standby是通过接收并应用primary数据库的redo log以介质恢复的方式(Redo Apply)实现同步。
另外，不知道大家是否注意到形容词上的细节：对于相机拍照而言，有种傻瓜相机功能强大而操作简便，而对于素描，即使是最简单的画法，也需要相当多的练习才能掌握。这个细节是不是也说明逻辑standby相比物理standby需要操作者拥有更多的操作技能呢？
二、Data Guard服务(Data Guard Services)
* REDO传输服务(Redo Transport Services)
控制redo数据的传输到一个或多个归档目的地。
* Log应用服务(Log Apply Services)
应用redo数据到standby数据库，以保持与primary数据库的事务一致。redo数据即可以从standby数据库的归档文件读取，也可直接应用standby redo log文件(如果实时应用打开了的话)。
* 角色转换服务(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而言，其生存逻辑非常简单，好好活，做有意义的事，做黑多黑多有意义的事：）
由于它提供了三种数据保护的模式，我们又亲切的叫它：有三模：
* 最大保护(Maximum protection)：
这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其redo不仅被写入到本地的online redo log，还要同时提交到standby数据库的standby redo log，并确认redo数据至少在一个standby数据库可用(如果有多个的话)，然后才会在primary数据库上提交。如果出现了什么故障导致 standby数据库不可用的话，primary数据库会被shutdown。
* 最高性能(Maximum performance)：
这种模式提供在不影响primary数据库性能前提下最高级别的数据保护策略。事务可以随时提交，当前primary数据库的redo数据也需要至少写入一个standby数据库，不过这种写入可以是不同步的。
如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护而仅对primary数据库有轻微的性能影响。
* 最高可用性(Maximum availability)：
这种模式提供在不影响primary数据库可用前提下最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求所有事务在提交前必须保 障redo数据至少在一个standby数据库可用，不过与之不同的是，如果出现故障导入无法同时写入standby数据库redo log，primary数据库并不会shutdown，而是自动转为最高性能模式，等standby数据库恢复正常之后，它又会再自动转换成最高可用性模 式。
最大保护及最高可用性需要至少一个standby数据库redo数据被同步写入。三种模式都需要指定LOG_ARCHIVE_DEST_n初始 化参数。LOG_ARCHIVE_DEST_n很重要，你看着很眼熟是吧，我保证，如果你完完整整学完dataguard，你会对它更熟。
四、Data Guard优点总结
* 灾难恢复及高可用性
* 全面的数据保护
* 有效利用系统资源
* 在高可用及高性能之间更加灵活的平衡机制
* 故障自动检查及解决方案
* 集中的易用的管理模式
* 自动化的角色转换
经常开篇的灌输，相信大家已经看的出来，上面这几条都是形容词，看看就好，记住更好，跟人穷白活的时候通常能够用上:)
同一个Data Guard配置包含一个Primary数据库和最多九个Standby数据库。Primary的创建就不说了，Standby数据库初始可以通过 primary数据库的备份创建。一旦创建并配置成standby后，dg负责传输primary数据库redo data到standby数据库，standby数据库通过应用接收到的redo data保持与primary数据库的事务一致。
转贴于：Oracle认证考试_考试大一、Standby数据库类型
前章我们简单介绍了Standby数据库，并且也知道其通常分为两类：物理standby和逻辑standby，同时也简短的描述了其各自的特点，下面我们就相关方面进行一些稍深入的研究：
1. 物理standby
我们知道物理standby与primary数据库完全一模一样(默认情况下，当然也可以不一样，事无绝对嘛)，Dg通过redo应用维护物理 standby数据库。通常在不应用恢复的时候，可以以read-only模式打开，如果数据库指定了快速恢复区的话，也可以被临时性的置为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的特点列出了)，我个人认为这是一种值的推荐的在线的滚动 的平滑的升级方式。
二、Data Guard操作界面(方式)
做为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配置。 三、Data Guard的软硬件需求
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数据库的操作系统必须一致，不过操作系统版本可以略有差异，比如(linux as4&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。
另外还有很重要一点，注意各服务器的时间设置，不要因为时区/时间设置的不一置造成同步上的。
四、分清某某REDO LOGS(Online Redo Logs, Archived Redo Logs, Standby Redo Logs)
黑多黑多的redo，想必诸位早已晕头并吐过多次了吧。哎，说实话我描述的时候也很痛苦。这块涉及到中英文之间的意会。我又不能过度白话，不然 看完我这篇文章再看其它相关文档的相关概念恐怕您都不知道人家在说什么，这种误人子弟的事情咱不能干(也许干过，但主观意愿上肯定是不想的)，更何况咱也 是看各乱杂七杂八文档被误过XXXXXXXXXXXXXXXXX次(X=9)，深受其害，坚决不能再让跟俺一样受尽苦楚，历经磨难的DDMM们因为看俺的 文档被再次一百遍啊一百遍。
但是已到关键时刻，此处不把redo混清楚，后头就得被redo混了，所以这里我要用尽我全部的口水+目前为止我所有已成体系的认识再给大家浅显的白话一回。注：基础概念仅一笔带过，水太大了也不好，要响应胡书记号召，书写节约型笔记。
REDO：中文直译是重做，与UNDO对应(天哪又扯出个概念，你看不见我看不见我看不见我)。重做什么？为什么要重做呢？首先重做是 oracle对操作的处理机制，我们操作数据(增册改)并非直接反映到数据文件，而是先被记录(就是online redo log喽)，等时机合适的时候，再由相应的进程通过读取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。
转自:<a href='http://sws.yuloo.com/'>国际商务师考试网</a>
来源：https://www.cnblogs.com/bolang100/p/6834168.html