Oracle中三大架构：
1、RAC主要是解决单点故障(FAIL OVER)和负载均衡(HA)。
数据只有一份，存储成为单点故障，仅是实例级别的冗余。
2、DG通过提供冗余数据来提供数据保护
常用于异地容灾和小企业的高可用解决方案
虽然可以在Standby机器上执行只读查询，从而分散Primary数据库的性能压力，但是绝不是性能解决方案。
3、goldengate更适合在应用层面的数据共享。
DataGuard架构介绍：
在DG环境中，至少会有两个数据库，一个数据库处于Open状态，对外提供服务，这个数据库叫做primary Database。第二个数据库处于恢复状态，叫做Standby Database。
运行时Primay Database对外提供服务，用户在Primary Database上进行操作，操作被记录在日志文件中。这些日志通过网络传送到Standby Database。这些日志会在Standby Database上重演，从而实现了数据的同步。
Oracle 的DG对这个过程进一步的优化设计，使得日志的传送、恢复工作更加自动化、智能化。
如果是可预见因素需要关闭Primay Database，例如软硬件的升级，可以把Standby Database切换为Primary Database继续对外提供服务，并且数据不会丢失。
如果是因为异常原因导致Primary Database不可用，也可以把Standby Database强制切换为Primary Database继续对外提供服务，这时数据损失程度和配置的数据保护级别有关系。
上面一大段话可以总结为以下三点：
1：primary Database上产生日志
2：primary Database将日志传给Standby Database
3：Standby Database根据接受到的日志进行重演
下面附上一张DG架构图，咱们就能更清晰的了解内部机制。
图中的data guard其实分为两种结构：
通过LGWR发送日志和通过ARCH发送日志。
通过LGWR也就意味着具有更高的实时性，数据丢失率较低。但也非常依赖网络资源，同样也受数据保护模式的影响。
通过ARCH则不必要非常好的网络资源，但数据实时性也大打折扣。
ARCH结构：
1、Primary Database不断的产生Redo Log，这些日志被LGWR进程写到联机日志
2、联机日志写满以后，发生日志切换，触发ARC0完成本地归档
归档位置采用LOG_ARCHIVE_DEST_1=‘LOCATION=/path’
3、完成本地归档以后，联机日志可以被覆盖重用
4、ARCH1进程通过Net把归档日志发送给Standby Database的RFS进程
5、Standby Database端的RFS(Remote File Server)进程把接受到的日志写入到归档日志
6、Standby Database端的MRP(media recover process)进程（Redo Apply）或者LSP进程（SQL Apply）在Standby Database上应用这些日志，进而同步数据
这种方式最大的问题是：
Primary Database只有在发生归档时才会发送日志到Standby Database，如果Primary Database异常宕机，联机日志中的Redo内容会丢失，因此这种方式没法避免数据丢失的问题。
要想避免数据丢失，就必须使用LGWR，而使用LGWR又有SYNC和ASYNC两种方式。
缺省Primary Database使用的就是ARCH进程，不需要特别的指定，例如下面这个配置的例子
LOG_ARCHIVE_DEST_2=‘SERVICE=ST’
LGWR的结构：
LGWR SYNC：
1、Primary Database产生的Redo日志要同时写到日志文件和网络。也就是说LGWR进程把日志写到本地日志文件的同时还要发给本地的LNSn进程（Network Server Process），再由LNSn进程把日志通过网络发送到远程目的地，每个远程目的地对应一个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把日志写入Standby Redo Log就会立即进行恢复；
归档时恢复，在完成对Standby Redo Log归档才触发恢复。
Primary Database默认使用ARCHN进程，如果使用LGWR进程必须明确指定。使用LGWR SYNC方式时，可以同时使用NET_TIMEOUT参数，这个参数单位是秒，代表如果多长时间内网络发送没有响应，LGWR进程就会抛出错误。
LOG_ARCHIVE_DEST_2=‘SERVICE=ST LGWR SYNC NET_TIMEOUT=30’
使用LGWR SYNC方法的可能问题在于，如果日志发送给Standby Database过程失败，LGWR进程就会出错，也就是说Primary Database进程依赖于网络状况。一般也可以使用异步的LGWR模式，也就是LGWR ASYNC。
LGWR ASYNC：
1、Primary Database一端产生Redo日志后，LGWR把日志同时提交给日志文件和本地LNS进程，但是LGWR进程只需要成功写入日志文件即可，不必等待LNSn进程的网络传送成功。
2、LNSn进程异步地把日志内容发送到Standby Database，多个LNSn进程可以并发发送
3、Primary Database的Online Redo Log写满后发生Log Switch，触发归档操作，也触发Standby Database对Stand Redo Log的归档，然后触发MRP或LSP进程恢复归档日志
因为LGWR进程不会等待LNSn进程的响应结果，所以配置LGWR ASYNC方式时不需要NET_TIMEOUT参数
LOG_ARCHIVE_DEST_2=‘SERVICE=boston LGWR ASYNC’
日志接收（Redo Receive）
Standby Database的RFS进程接收到日志后，就把日志写到Standby Redo Log或者Archived Log文件中，具体写入哪种文件，取决于Primary的日志传送方式和Standby Database的配置。
如果是写到Standby Redo Log文件中，则当Primary Database发生日志切换时，也会触发Standby Database上的Standby Redo Log的日志切换，并把这个Standby Redo Log归档。
在日志接收中，需要注意的是归档日志被放在什么位置，Standby Database选择归档目录的算法如下。
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_n和LOG_ARCHIVE_DEST_n参数都没有配置，使用缺省的STANDBY_ARCHIVE_DEST参数，这个缺省值是$ORACLE_HOME/dbs/arch
日志应用（redo apply）
日志应用（Redo Apply）
日志应用服务，就是在Standby Database上重演Primary Database的日志，从而实现两个数据库的数据同步。
根据Standby Database重演日志方式的不同，可分为物理Standby（Physical Standby）和逻辑Standby（Logical Standby）两种类型。
Physical Standby使用的是Media Recovery技术（MRP)），在数据块级别上进行恢复，这种方式没有数据类型的限制，可以保证两个数据库完全一致。Physical Standby数据库只能在Mount状态下进行恢复，也可以打开，但是只能以只读方式打开，并且打开时不能进行恢复操作。
Logical Standby使用的是Logminer技术(LSP)，通过把日志内容还原成SQL语句，然后SQL引擎执行这些语句，Logical Standby不支持所有数据类型，可以在视图dba_logstdby_unsupported中查看不支持的数据类型。如果使用了这种数据类型，则不能保证数据完全一致。Logical Standby数据库可以在恢复的同时进行读写操作。
Physical Standby的SCN号和主库保持一致，而Logical Standby仅保持数据层面的一致。一般在应用过程中BUG会较多，建议使用Physical Standby。
根据Redo Apply发生的时间又可以分成两种
一种是实时应用（Real-Time Apply），这种方式必须使用Standby Redo Log。每当日志被写入到Standby Redo Log时，就会触发恢复，使用这种方式的好处在于可以减少数据库切换的时间（Switchover或Failover），因为切换时间主要用在剩余日志内容的恢复上。
另一种是归档应用，这种方式是在Primary Database发生日志切换，触发了Standby Database的归档操作，归档完成后会触发恢复，这也是缺省的恢复方式。
如果是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：
SQL>select recovery_mode from v$archive_dest_status;
下面介绍一下DATA GUARD的三种数据保护模式：
所谓数据保护模式是指在Standby Database和Primary Database之间数据同步的程度。Data Guard允许定义三种数据保护模式，分别是最大保护（maxmium protection）、最大可用（maxmium availability）、最大性能（maxmium performance）。
这三种模式的区别在于，当Primary Database发生故障时，Standby Database的数据会和Primary Database有多少差别？
最大保护模式（maxmium Production）
这个级别保证Standby Database和Primary Database的数据是完全同步的，即使Primary Database突然宕机，在Standby Database上不会有任何数据丢失。
这种模式下，Primary Database上的每个事务的Redo日志必须在本地和Standby Database上都写入日志文件后才能提交，如果不能写入到Standby Database，Primary Database就会自动关闭以防止数据丢失。
这种方式要求Standby Database必须配置Standby Redo log，而Primary Database必须使用LGWR、SYNC、AFFIRM方式归档到Standby Database。（AFFIRM,磁盘io控制，保证主备库日志同时写完）
最大性能（Maxmium Performance）
这个模式是缺省模式，他更加侧重对Primary Database的可用性不造成任何影响。
Primary Database上的事务的Redo日志只要写到本地日志文件就可以提交，不必等待到Standby Database的传递完成。
Primary Database的Redo流可以异步的发送到Standby Database。
这种模式通过LGWR ASYNC或者ARCH实现，Standby Database也不要求使用Standby Redo Log。
最大可用性（Maxmium Availability）
这种模式会尽量避免数据丢失，Primary Database每个事务的Redo日志要写到本地和Standby Database中才能提交。
这个和最大保护模式不同的是，如果写入到Standby Database失败，Primary Database不会自动关闭。这时Primary Database会自动转换为Maxmium Performance模式，等待问题解决并且Standby Database再次和Primary Database同步之后，Primary Database会自动的转换为Maxmium Availability。
这种模式会尽量的避免数据丢失，但不能绝对保证数据完全一致。
这种模式要求Standby Database必须配置Standby Redo log，而Primary Database必须配置为LGWR、SYNC、AFFIRM方式归档。
如果要修改数据保护模式，则可以按照以下操作进行。
SQL>shutdown immediate;
SQL>startup mount;
修改模式
SQL>alter database set standby database to maxmium availability;
打开数据库
SQL>alter database open;
确认模式已经修改
SQL>select protection_mode,protection_level from v$database;
当主库日志没有成功发送到备库，也就是丢失部分日志的情况下，可以通过自动获取和手动获取日志的方式回复：
自动裂隙检测解决
当Primary Database的某些日志没有成功发送到Standby Database，这时就发生了归档裂隙（Archive Gap），缺失的这些日志就是裂隙（Gap）。
Dataguard能够自动检测、解决归档裂隙，不需要DBA的介入。
这需要配置FAL_CLIENT、FAL_SERVER两个参数（FAL是Fetch Archive Log的首字母缩写）。
从FAL名称就可以看出，这个过程是Standby Database主动发起的“取”日志的过程，Standby Database是FAL_CLIENT，但是Standby Database从哪里取这些日志呢？这个哪里就是FAL_SERVER。
AL_SERVER可以是Primary Database，也可以是别的Standby Database。
参数FAL_SERVER是用来定义要从那些数据库获得缺少的日志。这个参数值是Oracle Net Name。
Oracle 10.2开始，Standby Database不仅可以从Primary Database获得，还可以从其他Standby Database获得缺少的日志，因此这个参数可以定义一个Net Name列表：
FLA_SERVER=‘pr1,st1,st2’;
参数FAL_CLIENT也是一个Oracle Net Name。
FAL_ CLIENT通过网络发送请求， FAL_ SERVER通过网络向FAL_ CLIENT发送缺失的日志。
但是这不一定是一个连接。
因为FAL_ CLIENT向FAL_ SERVER发送请求的时候，会携带FAL_CLIENT参数值，用来告诉FAL_ SERVER应该向哪里发送缺少的日志，这个参数也是一个Oracle Net Name，这个Name是在FAL_ SERVER上定义的，用来指向FAL_ CLIENT。
除了自动的日志缺失解决，DBA也可以手工解决，这需要作如下操作：
1、确认Standby Database上缺少的日志
2、把这些日志从Primary Database拷贝到Standby Database
3、在Standby Database使用命令手工注册这些日志
alter database register logfile ‘logfilename’;
RAC和Standby配置几种组合：
组合PrimaryStandby
1Single InstanceSingle Instance
2Single InstanceRAC
3RACSingle Instance
4RACRAC
值得注意的是，如果standby为rac，则可以分别指定receive instance和recover instance也就是对应着RFS和MRP。Receive instance和recover instance的关系式n:1。也即是可以指定多个receive instance并发的接受传来的日志，而recover instance只有1个，所以该实例要具有访问所有日志文件的权限，一般配备ASM。
