All about Data Guard(三)
Guard 是Oracle企业版的一个特性，明白了吧，标准版是不支持地。
同一个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喽)，等时机合适的时候，再由相应的进程操作提交到数据文件(详细可见： 数据写过程中各项触发条件及逻辑 ) 。你是不是想说如果把所有的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(1)创建步骤
一、 准备工作
不管物理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 redo log 配置的问题。standby redo logs 与online redo logs 非常类似，应该说两者只是服务对象不同，其它参数属性甚至操作的命令格式几乎都一样，你在设计standby redo logs 的时候完全可以借鉴创建online redo logs 的