大话 ORACLE RAC
第二部分
实战篇
第十章：
RAC && DG
用户在Primary Database上进行操作，操作被记录在联机日志和归档日志中，这些日志通过
网络传递给Standby Database。这些日志在Standby Database上重演，从而实现Primary
Database和Standby Database的数据同步。
有三个关键点：
1，在主库上产生的日志
2，产生的日志传递给备库
3，在备库上重演这些日志
DG：就是围绕着这三个关键点展开的
1，日志发送
2，日志接收
3，日志应用
日志发送：
LGWR && ARCH
对于一个目的地只能选用一种方法
ARCH:
缺省的情况就是使用ARCH进程
但是主库必须运行在归档模式下
LGWR SYNC:
LGWR进程把日志写到本地日志文件的同时还要发送给本地的LNSn进程（Network Server
Process)，再由LNSn进程把日志通过网络发送给远程目的地。每一个远程目的地对应一个
LNS进程，多个LNS进程能够并行工作。
LGWR必须要等待写入本地日志文件操作和通过LNSn进程的网络传送都成功，主库上的事务
才能够提交，这也是SYNC的含义所在。
备库中的RFS进程把接收到的日志写入到备库日志当中。
主库上的日志切换也会触发备库上的日志切换，即备库对备库的REDO LOG的归档，然后触发
备库的MRP或者LSP进程恢复归档日志。
LOG_ARCHIVE_DEST_2='SERVICE=ST LGWR SYNC NET_TIMEOUT=30'
主库的LGWR依赖于网络的状况。
LGWR ASYNC:
主库一端产生REDO日志的，LGWR把日志同时提交给日志文件和本地的LNS里程。但是LGWR
进程只需要成功写入日志文件就可以，不必等待LNS进程的网络传送成功
LNS进程异步地把日志内容发送到备库
主库的联机日志文件写满后发生日志切换，触发归档操作，也触发备库对备库的重做日志的
归档；然后触发MRP或者LSP进程恢复归档日志。
LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR ASYNC'
日志接收：
备库的归档位置：
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/arch.
日志应用：
日志应用就是在备库上重演主库的日志，从而实现两个数据库数据的同步。
根据备库重演日志方式的不同，可以分为物理STANDBY和逻辑STANDBY两种类型。
Physical Standby 使用的是Media Recovery技术，在数据块级别进行恢复。这种方式没有数据
类型的限制，可以保证两个数据库的完全一致。Primary Standby数据库只能在MOUNT状态下进行
恢复，也可以打开，但是只能以只读方式打开，并且打开时不能执行恢复操作。
而Logical Standby 使用的是Logminer技术，通过把日志内容还原成SQL语句，然后SQL引擎
执行这些语句，Logical Standby不支持所有的数据类型，可以在视图dba_logstdby_unsupported
中查看不支持的数据类型，如果使用了这种数据类型，则不能保证数据库的完全一致，Logical
Standby 数据库可以在恢复的同时进行读写的操作。
Logical Standby 数据库的工作机制和后面的Stream Replication有异曲同工之处。
根据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:
select recovery mode from v$archive_dest_status;
数据保护模式：
所谓数据保护模式，是指主库和备库之间的数据上步程度。
最大保护（maxmum protection)
最大可用(maxmum availability)
最大性能(maxmum performance)
最大保护：
这个级别保证备库和主库的数据是完全同步的，即使主库突然宕机，在备库上不会有任何数据
丢失。
在这种模式下，主库上的每个事务的REDO日志必须在本地和备库上都写入日志文件后才能提交。
如果不能写入到备库，主库就会自动关闭以防止数据丢失。
使用这种方式要求备库必须配置Standby Redo Log，而主库必须使用LGWR,SYNC,AFFIRM方式
归档到备库。
最大可用性：
这种模式昼避免数据丢失，也就是主库的每个事务的REDO日志要写到本地和备库中才能提交。
和最大保护模式不同的是，如果写入到备库失败，主库不会自动关闭，这时主库自动转换成
最大性能模式，等待问题解决并且备库再次和主库同步之后，主库会自动转换回最大可用模式。
这种模式虽然会尽量避免数据丢失，但不能绝对保证数据完全一致。这种模式要求备库必须
配置Standby Redo Log，而主库必须使用LGWR,SYNC,AFFIRM方式归档。
最大性能：
这种模式是缺省模式，它更加侧重对主库的可用性不造成任何影响。
主库上的事务的REDO日志只要写到本地日志文件就可以提交，不必等待到备库的传递完成。
主库的REDO流可以异步地发送到备库。
这种模式可以使用LGWR,ASYNC,或者ARCH实现,备库也不要求使用Standby Redo Log.
切换保护模式：
shutdown immediate;
startup mount;
alter database set standby database to maximize availability;
alter database open;
select protection_mode,protection_level from v$database;
自动裂隙检测和解决：
Archive Gap
当主库的某些日志没有成功发送到备库，这时就发生了归档裂隙，缺失的这些日志就是裂隙
（GAP）。DG能够自动监测，解决归档裂隙，不需要DBA的介入。
这需要配置FAL_CLIENT,FAL_SERVER两个参数。（FAL Fetch Archive Log)
FAL_SERVER 可以是一个NET NAME 列表。
eg: FAL_SERVER='pr1,st1,st2';
RAC 和 Standby 配置实例：
v$archive_dest_status
v$archive_dest
