RAC， Data Gurad， Stream 是Oracle 高可用性体系中的三种工具，每个工具即可以独立应用，也可以相互配合。 他们各自的侧重点不同，适用场景也不同。
RAC 它的强项在于解决单点故障和负载均衡，因此RAC 方案常用于7*24 的核心系统，但RAC 方案中的数据只有一份，尽管可以通过RAID等机制可以避免存储故障，但是数据本身是没有冗余的，容易形成单点故障。
Data Gurad 通过冗余数据来提供数据保护，Data Gurad 通过日志同步机制保证冗余数据和主数据之前的同步，这种同步可以是实时，延时，同步，异步多种形式。DataGurad常用于异地容灾和小企业的高可用性方案，虽然可以在Standby机器上执行只读查询，从而分散Primary 数据库的性能压力，但是DataGurad决不是性能解决方案。
Stream 是以Oracle Advanced Queue为基础实现的数据同步，提供了多种级别的灵活配置，并且Oracle提供了丰富的API等开发支持，Stream更适用在应用层面的数据共享。
在Data Gurad 环境中，至少有两个数据库，一个处于Open 状态对外提供服务，这个数据库叫作PrimaryDatabase。第二个处于恢复状态，叫作StandbyDatabase。 运行时primary Database对外提供服务，用户在PrimaryDatabase 上进行操作，操作被记录在联机日志和归档日志中，这些日志通过网络传递给StandbyDatabase。 这个日志会在StandbyDatabase上重演，从而实现Primary Database和Standby Database 的数据同步。
Oracle Data Gurad 对这一过程进一步的优化设计，使得日志的传递，恢复工作更加自动化，智能化，并且提供一系列参数和命令简化了DBA工作。
如果是可预见因素需要关闭Primary Database，比如软硬件升级，可以把Standby Database 切换为Primary Database 继续对外服务，这样即减少了服务停止时间，并且数据不会丢失。如果异常原因导致Primary Database不可用，也可以把StandbyDatabase强制切换为Primary Database继续对外服务，这时数据损失程度和配置的数据保护级别有关系。因此Primary和Standby只是一个角色概念，并不固定在某个数据库中。
一． Data Guard 架构
DG架构可以按照功能分成3个部分：
1） 日志发送（Redo Send）
2） 日志接收（Redo Receive）
3） 日志应用（Redo Apply）
1. 日志发送（Redo Send）
Primary Database 运行过程中，会源源不断地产生Redo 日志，这些日志需要发送到StandyDatabase。这个发送动作可以由PrimaryDatabase 的LGWR 或者ARCH进程完成， 不同的归档目的地可以使用不同的方法，但是对于一个目的地，只能选用一种方法。选择哪个进程对数据保护能力和系统可用性有很大区别。
1.1 使用ARCH进程
1）Primary Database 不断产生Redo Log，这些日志被LGWR 进程写到联机日志。
2）当一组联机日志被写满后，会发生日志切换（Log Switch），并且会触发本地归档，本地归档位置是采用 LOG_ARCHIVE_DEST_1='LOCATION=/path'这种格式定义的。
如：alter system set log_archive_dest_1 = 'LOCATION=/u01/arch'scope=both;
3）完成本地归档后，联机日志就可以被覆盖重用。
4）ARCH 进程通过Net 把归档日志发送给Standby Database的RFS（RemoteFileServer）进程。
5）Standby Database 端的RFS 进程把接收的日志写入到归档日志。
6）Standby Database 端的MRP(Managed Recovery Process)进程（RedoApply）或者LSP进程（SQLApply）在StandbyDatabase上应用这些日志，进而同步数据。
用ARCH模式传输不写Standby Redologs，直接保存成归档文件存放于Standby端。
说明：
逻辑Standby接收后将其转换成SQL语句，在Standby数据库上执行SQL语句实现同步，这种方式叫SQLApply。
物理Standby接收完Primary数据库生成的REDO数据后，以介质恢复的方式实现同步，这种方式也叫RedoApply。
注意：创建逻辑Standby数据库要先创建一个物理Standby数据库，然后再将其转换成逻辑Standby数据库。
使用ARCH进程传递最大问题在于： Primary Database只有在发生归档时才会发送日志到StandbyDatabase。 如果Primary Database 异常宕机，联机日志中的Redo内容就会丢失，因此使用ARCH进程无法避免数据丢失的问题，要想避免数据丢失，就必须使用LGWR，而使用LGWR又分SYNC（同步）和ASYNC（异步）两种方式。
在缺省方式下，Primary Database使用的是ARCH进程，参数设置如下：
alter system set log_archive_dest_2 = 'SERVICE=ST' scope=both;
1.2 使用LGWR 进程的SYNC 方式
1）Primary Database 产生的Redo 日志要同时写道日志文件和网络。也就是说LGWR进程把日志写到本地日志文件的同时还要发送给本地的LNSn进程（NetworkServerProcess），再由LNSn（LGWRNetworkServerprocess）进程把日志通过网络发送给远程的目的地，每个远程目的地对应一个LNS进程，多个LNS进程能够并行工作。
2）LGWR 必须等待写入本地日志文件操作和通过LNSn进程的网络传送都成功，Primary Database 上的事务才能提交，这也是SYNC的含义所在。
3）Standby Database的RFS进程把接收到的日志写入到Standby Redo Log日志中。
4）Primary Database的日志切换也会触发Standby Database 上的日志切换，即Standby Database 对Standby Redo Log的归档，然后触发Standby Database 的MRP或者LSP进程恢复归档日志。
因为Primary Database 的Redo 是实时传递的，于是Standby Database 端可以使用两种恢复方法：
实时恢复（Real-Time Apply）： 只要RFS把日志写入StandbyRedoLog就会立即进行恢复；
归档恢复： 在完成对Standby Redo Log 归档才触发恢复。
Primary Database默认使用ARCH进程，如果使用LGWR进程必须明确指定。使用LGWRSYNC方式时，可以同时使用NET_TIMEOUT参数，这个参数单位是秒，代表如果多长时间内网络发送没有响应，LGWR进程会抛出错误。示例如下：
alter system set log_archive_dest_2 = 'SERVICE=ST LGWR SYNC NET_TIMEOUT=30' scope=both;
1.3 使用LGWR进程的ASYNC 方式
使用LGWR SYNC方法的可能问题在于，如果日志发送给Standby Database过程失败，LGWR进程就会报错。也就是说PrimaryDatabase的LGWR进程依赖于网络状况，有时这种要求可能过于苛刻，这时就可以使用LGWRASYNC方式。 它的工作机制如下：
1） Primary Database 一旦产生Redo 日志后，LGWR 把日志同时提交给日志文件和本地LNS进程，但是LGWR进程只需成功写入日志文件就可以，不必等待LNSn进程的网络传送成功。
2） LNSn进程异步地把日志内容发送到Standby Database。多个LNSn进程可以并发发送。
3） Primary Database的Online Redo Log 写满后发生Log Switch，触发归档操作，也触发StandbyDatabase对StandbyDatabase对StandbyRedo Log 的归档；然后触发MRP或者LSP进程恢复归档日志。
因为LGWR进程不会等待LNSn进程的响应结果，所以配置LGWR ASYNC方式时不需要NET_TIMEOUT参数。示例如下：
alter system set log_archive_dest_2 = 'SERVICE=ST LGWR ASYNC ' scope=both;
2. 日志接收（Redo Receive）
Standby Database 的RFS（RemoteFileServer）进程接收到日志后，就把日志写到StandbyRedoLog或者ArchivedLog文件中，具体写入哪个文件，取决于Primary 的日志传送方式和Standby database的位置。如果写到StandbyRedoLog文件中，则当Primary Database发生日志切换时，也会触发StandbyDatabase上的StandbyRedoLog 的日志切换，并把这个Standby Redo Log归档。 如果是写到ArchivedLog，那么这个动作本省也可以看作是个归档操作。
在日志接收中，需要注意的是归档日志会被放在什么位置：
1） 如果配置了STANDBY_ARCHIVE_DEST 参数，则使用该参数指定的目录。
2） 如果某个LOG_ARCHIVE_DEST_n 参数明确定义了VALID_FOR=(STANDBY_LOGFILE,*)选项，则使用这个参数指定的目录。
3） 如果数据库的COMPATIBLE参数大于等于10.0，则选取任意一个LOG_ARCHIVE_DEST_n的值。
4） 如果STANDBY_ARCHIVE_DEST 和 LOG_ARCHIVE_DEST_n 参数都没有配置，使用缺省的STANDBY_ARCHIVE_DEST参数值，这个缺省值是$ORACLE_HOME/dbs/arc.
3. 日志应用（Redo Apply）
日志应用服务，就是在Standby Database上重演Primary Database日志，从而实现两个数据库的数据同步。 根据Standby Database重演日志方式的不同，可分为物理Standby（PhysicalStandby）和逻辑Standby（Logical Standby）。
Physical Standby 使用的是MediaRecovery技术，在数据块级别进行恢复，这种方式没有数据类型的限制，可以保证两个数据库完全一致。Physical Standby数据库只能在Mount状态下进行恢复，也可以是打开，但只能已只读方式打开，并且打开时不能执行恢复操作。
Logical Standby 使用的是Logminer技术，通过把日志内容还原成SQL语句，然后SQL引擎执行这些语句，LogminerStandby不支持所有数据类型，可以在视图DBA_LOGSTDBY_UNSUPPORTED中查看不支持的数据类型，如果使用了这种数据类型，则不能保证数据库完全一致。LogicalStandby数据库可以在恢复的同时进行读写操作。
Standby数据库的相关进程读取接收到的REDO数据（可能来自于Standby端的归档文件，也可能来自于Standby Redologs），再将其写入Standby数据库。保存之后数据又是怎么生成的呢？两种方式：物理Standby通过REDO应用，逻辑Standby通过SQL应用
根据Redo Apply发生的时间可以分成两种：
一种是实时应用（Real-Time Apply）， 这种方式必须StandbyRedoLog，每当日志被写入StandbyRedo Log时，就会触发恢复，使用这种方式的好处在与可以减少数据库切换（Switchover或者Failover）的时间，因为切换时间主要用在剩余日志的恢复上。
另一种是归档时应用，这种方式在Primary Database发生日志切换，触发StandbyDatabase归档操作，归档完成后触发恢复。这也是默认的恢复方式。
如果是Physical Standby，可以使用下面命令启用Real-Time：
Alter database recover managed standby database using current logfile;
如果是Logical Standby，可以使用下面命令启用Real-Time：
Alter database start logical standby apply immediate;
查看是否使用Real-Time apply：
Select recovery_mode from v$archive_dest_status;
SQL> set wrap off
SQL> select process,status,thread#,sequence#,client_pid from v$managed_standby;
PROCESS STATUS THREAD# SEQUENCE# CLIENT_PID
--------- ------------ ---------- ---------- -----------------------------------
ARCH CONNECTED 00 240
ARCH CONNECTED 00 196
ARCH CONNECTED 00 1944
ARCH CONNECTED 00 3956
MRP0 WAIT_FOR_LOG 130843 N/A
RFS RECEIVING 130838 2620
RFS RECEIVING 130837 2612
RFS RECEIVING 130833 2652
RFS ATTACHED 130841 2628
RFS ATTACHED 130835 2604
RFS ATTACHED
