1.关于standby redo log的理解
Data Guard在备库中，建议配置一种额外的日志文件，叫做standby redo log（SRL），和传统的online redo log（ORL）相比，SRL有着特殊的要求和作用。两者的关系可以从下面的几点来对比：
1.SRL和ORL两种文件是完全相同的，只是两者发挥的作用和场景不同。
2.SRL只在备库上起作用，（虽然主库也可以配置SRL），但是当数据库处于主库角色的时候，SRL是不活动的，只有经过了角色切换，变成了备库角色时，SRL日志才会变成活动的。
3.对于处于备库角色的数据库来说，ORL不是必须的，也不会起作用，（在很多时候，备库虽然显示有ORL，但是并没有真正的操作系统文件存在，只有当角色切换，变成主库角色时，才真正在操作系统上创建ORL文件）！
4.对于处于备库角色的数据库来说，他从主库接收到的日志可以记录在SRL文件中，也可以记录在归档日志文件中，具体写在哪个文件中取决于具体配置，但是不会写在ORL中。
5.SRL必须和ORL大小完全一致，否则SRL也不会被用到。其次，从数量上，应该按照每个实例或日志线程N+1的数量关系来配置，例如2个实例的RAC，如果每个实例3组日志，则SRL应该是（3+1）*2=8组。
是否使用SRL，关键区别在于RFS把接收到的日志，是写在归档日志里，还是写在SRL里。
使用SRL可以带来2大好处：
1.性能
如果不使用SRL，则备库的RFS会把接收到的日志记录到归档日志文件中，每当主库做日志切换时，才会触发备库对当前归档日志的归档操作，因此他必须等待备库的RFS进程创建并且初始化下一个归档日志文件，用来容纳以后传递的REDO内容。因此这个过程会影响主库日志的切换进度，当然对于异步传送来说不影响主库性能，但是仍然会导致备库日志落后的情况。
然而使用了SRL，因为SRL预先建好，因此日志切换时，无需额外的文件初始化工作，因此性能要更好一些。
2.支持Real-Time Apply（RTA）
前面介绍了实时同步，备库最后一个日志总是IN-MEMORY状态。
2.关于Data Guard保护模式的学习和总结
数据保护模式是指备库和主库之间数据同步程度。
Data Guard允许定义3种数据库保护模式，分别是最大保护、最大可用、最大性能模式。
这3种模式的区别在于，当主库发生故障时，备库的数据会和主库有多大的差距。
1.最大保护模式 Maximum Protection
顾名思义，这是最高的数据保护级别，这个模式的规则是即便牺牲主库的可用性，也要保证不出现数据丢失！
这个级别保证备库和主库的数据是完全同步的，即使主库突然夯机，在备库上也不会出现任何数据丢失。
这种方式要求备库必须配置SRL，而主库必须使用LGWR、SYNC、AFFIRM方式归档到备库，并且用命令定义为最大保护模式。
在这种模式下，主库上的每个事务的REDO日志必须在和本地和备库上都写入日志文件后才允许提交。如果不能写入到备库，
主库就会自动关闭以方式数据丢失。但也不是立刻shutdown abort，而是不再生成任何REDO，并且不断地尝试连接备库，
这个尝试大约最多会有10分钟，因为这一段时间内LGWR不再生成任何REDO，因此整个数据库表现为挂起。
在这种模式下，至少要有一个备库是正常的，主库才能正常打开，否则主库都无法打开。
如果主库是RAC环境，如果一个实例和备库之间网络发生了问题，那么在最大保护模式下，这个实例是crash，继而触发其他实例的crash recovery，
完成这个recovery之后，Data Guard会忽略这个实例，而主库其他实例也能继续处理业务，并发送日志进行同步。除非所有实例连接备库都出现了问题，
才会出现所有实例crash，最终导致整个数据库的crash。
2.最大可用模式 Maximum Availability
这是另外一种能实现零数据丢失的数据保护方案。这种模式需要至少有一个备库是通过SYNC和AFFIRM方式传送数据，并且要使用SRL文件才行。
在这种模式下，主库发送redo日志、并等待备库确认，备库收到redo日志，记录到SRL中，并返回确认给主库，这时，主库上的事务才能结束。
这是和最大保护模式一样的地方。因此，网络状态、备库的状态都会影响主库的事务性能。等待确认的时间用一个参数NET_TIMEOUT定义。
如果主库在该段时间（默认30秒）没有收到任何反馈信息，这个备库就会被标记成failed，LGWR会继续写日志，但是会忽略掉这个failed的备库。
如果在NET_TIMEOUT内收到了standby failed的消息，LGWR和LNS还会继续尝试重新连接，直到最终放弃这个备库为止。
一旦备库被认为是failed，那么主库就会强制进行一次日志切换，以明确的标识出发生failed的时间点，也就是达到零数据丢失的时间点，
而在这以后产生的redo日志就不再向备库发送了。
在这以后的时刻，Data Guard的保护模式就降到了Unprotected了，如果是一主多备环境，会有其他备库保持同步。一致到解决了日志Gap，
主库才会继续发送REDO，Data Guard才会恢复到Maximum Availability模式。
在RAC环境下，如果一个实例认为备库是failed，则自动触发的日志切换会导致所有的实例都停止发送REDO，即便其他实例能够连接到备库。
接下来，实例的ARCH进程还继续利用ping机制检测到备库的连通性，一旦恢复连接，则所有的实例会自动去解决gap，
接着所有的实例会进行日志切换，以启动LNS进程，继续发送REDO。
这种模式只是尽量避免数据丢失，也并不能保证数据完全一致。这种模式要求备库必须配置SRL，而主库必须使用LGWR、SYNC、AFFIRM方式归档。
3.最大性能模式 Maximum Performance
这个模式是默认的模式，它更加侧重对主库可用性不造成任何影响，即“在不影响主库性能的情况下，尽可能少的数据丢失。”
主库上的事务的REDO日志只要写到本地日志文件就可以提交，不必等待到备库传递完成。主库的REDO可以异步发送到备库。
备库的任何故障，以及两者之间的网络故障都不会影响主库的活动，即便网络出现问题，主库也只不过暂时停止REDO传送，
并等待ARCH进程通过PING机制发现连接恢复之后，继续重传。
这种模式可以使用LGWR ASYNC或者ARCH实现，备库也不要求使用SRL。
如果主库是RAC，并且工作在最大性能模式下，如果只是RAC的某个实例和备库的日志传递发生故障，那么也只有该实例的日志传递被中止。
而其他实例的日志传递仍然继续。发生中断的实例上的ARCH进程会不断地通过ping机制来检查连通性，一旦发现连接恢复，这个实例上的gap会自动发送给备库，
但是LGWR进程却并不会立即启动LNS进程去发送当前的redo数据，而是直到下一次日志切换时，LGWR才会启动LNS，开始传递REDO数据。
3.定义数据保护模式
保护模式是针对主库进行设置的，这个设置是告诉主库必须要遵守的规则。对备库没有作用。
数据保护模式在定义数据保护级别的同时，捎带着也同时定义了两个重要信息：
主库如何向备库传送redo；
当备库发生故障或网络出现故障，主库应该怎么做。
以下命令都是在主库下执行：
ALTER DATABASE SET STANDBY TO MAXIMIZE PERFORMANCE;
ALTER DATABASE SET STANDBY TO MAXIMIZE AVAILABILITY;
ALTER DATABASE SET STANDBY TO MAXIMIZE PROTECTION;
切换模式的过程，先尝试能够在open状态下切换，不能的话，就在mount下切换。
shutdown immeidate
startup
alter database set standby to maximize availability;
alter database open;
select protection_mode,protection_level from v$database;