Oracle Data Guard总结
RAC能够提供实例级的冗余，但是不能保护数据，只能使用多个实例来共享一个存储，实际上还是一个数据库。Dg就是数据的冗余，数据层面的一种保护。
现在流行的其他技术如Stream（流复制），Golden Gate（OGG），其实这些东西原理都差不多，都是通过使用当前数据库的在线日志利用来实现的。
主数据库将redo数据传到备用数据库上，备用数据库拿到redo信息就像做数据库恢复一样，主数据库源源不断的将数据传到备用数据库上，备用数据库源源不断的将归档恢复上去。通过这种机制保证主数据库和备用数据库的数据的一致性。
RMAN备份有一个问题，可以将数据库每天备份，但是恢复数据库是需要时间的，比如数据库坏了要从RMAN里面恢复是需要一个时间的，就是宕机了，基于这个原因可以使用DG来代替RMAN。或者说RMAN作为次要的，主要使用DG来备份数据。
DG是一个在线的数据库的同步，而不像RMAN要等着数据库损坏了再重新恢复。在线数据库就是当主数据库坏了可以在最短的时间将业务切换到备份数据库上面。如果切换的策略做的好可以在秒级就可以切换过去。比如在应用的一端准备好了切换的脚本，就比如可能是修改IP地址，在数据库这一端也做好了相应的脚本，只要一运行，立刻将备用数据库切换为主数据库。只要将这两个脚本写好通过多次模拟就可以了。
对于海量数据来说，特别是OLAP这种类型的数据库，OLAP这种数据库的特点是批量的装载数据，通过ETL之后清理了一堆数据，一下就要将一堆数据load到数据库里面，这种方式通常来说不适合做DG，这种使用load的方式将数据装载到数据库里面通常情况数据量是比较大，所以在load的时候不是使用insert方式，大多数时候使用SQL LOADER进来的，而使用SQL LOADER这种方式来加载的时候一般愿意使用直接的方式加载，使用直接加载的方式不会对数据产生redo，这样DG的价值就没有意义了，所以对于数据仓库这种类型的数据库使用DG作为数据的冗余是不合适的。最好在数据库里面有直接的方式，也就是不产生redo类型操作的数据，有这种类型的操作就不适合做DG。
即使也是使用insert的方式常规往里面插入数据，但是数据量太大的话，产生了大量的归档日志，这些日志向备用数据库的传递是否能够及时的到达，这又是一个问题。
DG不仅可以做本地容灾还可以做异地容灾。Stand by数据库可以有多个。DG对网络的要求要比RAC对网络的要求低的多，RAC对网络的要求非常高（要求网络非常畅通），如果是远程做RAC几乎是不可能。
SQL> desc v$database;
Name Null? Type
----------------------------------------- -------- ----------------------------
DATABASE_ROLE VARCHAR2(16)
GUARD_STATUS VARCHAR2(7)
PROTECTION_MODE VARCHAR2(20)
SQL> select DATABASE_ROLE,guard_status,protection_mode from v$database;
DATABASE_ROLE GUARD_STATUS
-------------------------------- --------------
PROTECTION_MODE
----------------------------------------
PRIMARY NONE
MAXIMUM PERFORMANCE
可以从v$databse这张视图里面看到该数据库的角色了。
通过show parameter dest_2可以看到
在DG主数据库里面，在初始化参数里面，将归档的路径指向的不是本地了，指向的是一个服务了。 指向的是stand by了。这个server的值就是tnsnames里面配置的值。
可以看到指向的是dg2，在DG主数据库里面，在初始化参数里面，将归档的路径指向的不是本地，也可以指向本地，比如说有两个路径，一个路径指向本地，一个路径指向stand by，这个是通过一个服务，这个服务就是TNS连接字符串，和远程用sqlplus连接一样，如sqlplus sys/[email protected]_phystdby,phystdby就是连接字符串，这个连接字符串就是配置到主数据库的参数文件里面。归档就是通过连接字符串这种方式将日志信息送到了standby数据库上面。standby数据库上面有一个进程来接收这个东西。
Standby数据库正常的状态是mount的，不是open的，因为open的数据库是不能做恢复的，只有在mount的时候才能恢复。
主数据库
Standby数据库（通过观察alter日志）
可以看到38，39号归档被传过去了，已经恢复了。在等40号归档传过去。
DG实际上就是要将主数据库一个归档日志传递到远程的standby数据库上面。然后在standby数据库上面进行恢复。
DG在保护的情况下有三种模式，在主数据库上面可以设置这三种保护模式。
最高数据保护模式（这种保护模式是最能保护数据的安全）
最高性能（这种模式是性能最好的，但是也是最不安全的）
最高可用是介于上面两个之间的模式。
最大保护模式
除非将备数据库和主数据库之间的网络优化到百分之百信赖才用这种模式。否则主数据库动不动重启，这个是谁也无法忍受的，几乎没有人敢设置为最大保护模式，因为谁都不知道会不会导致主数据库的重启。
主数据库往standby数据库传递的数据不是归档了，而是实时的redo数据。
最大性能模式
只有主数据库产生了归档之后，这个归档才会传递到备数据库，也就是说主数据库和备数据库是相差一个日志文件里面的数据。主数据库的日志文件一直往里面写，在日志文件没有归档之前，这个日志文件里面的内容是不会传递到备数据库上面的。
当前的主数据库的redo文件没有产生归档之前，这一部分redo是没有传递到备数据库上面的，如果主数据库整个坏了，包括日志文件也损坏了，那备数据库就少了redo那部分的日志。
高可用模式
如果不担心日志双写给主数据库带来的性能压力就可以将数据库设置为高可用模式。
DG的三种保护模式，默认是高性能模式，可以根据系统的要求来更改模式，不过对于要改为最大保护模式要三思，这可能会导致主数据库的重启，一般不会将系统修改为最大保护模式。
上面图错了，最高性能模式要和最高可用性模式调换位置。
这取决于主备数据库之间的网络性能，在本地的备数据库和主数据库的网络肯定很好，一个局域网里，使用高可用模式。
物理备数据库就是说，备份数据库是mount状态，不是open状态。主数据库向备数据库传的是归档数据。
逻辑备数据库就是说，是将redo数据生成SQL语句，redo里面放的不是SQL语句，redo里面存放的是改变向量，逻辑备库将改变向量重新还原成了SQL语句。因为SQL语句要在数据库open的时候执行，所以备库的状态可以是open。
如果备用数据库只是用来做数据的备份，只是为了安全起见，那么物理备库是最好的。将归档传过去再应用，这种的恢复比用SQL语句的恢复性能要好得多。应用归档这种介质恢复是数据块的重新复制，所以比SQL语句的效率要高。
如果要读写分离，要从备库上面做查询，报表。这个时候就可以使用逻辑的备库。