DG数据保护模式

1、三种保护模式
  1).最大性能(maximize performance):
     这是data guard默认的保护模式。primay上的事务commit前不需要从standby上收到primary故障时可能丢失数据，
     但standby对primary的性能影响最小。
     这种保护模式（默认）提供了可能的最高级别的数据保护，而不影响主数据
     库的性能。这是通过允许事务在恢复该事务所需重做数据在写到本地联机重做日志后立即提
     交而实现的。主数据库的重做数据流也写到至少一个备数据库，但是那个重做流相对于创建
     重做数据的事务是异步写的。
     当所用的网络连接有足够的带宽，这种模式提供了近似于最大可用性模式的数据保护级
     别，并且对主数据库性能的影响最小。
     最大保护和最大可用性模式需要备重做日志文件配置在配置中的至少一个备数据库上。
     所有三种保护模式需要在LOG_ARCHIVE_DEST_n 初始化参数上指定特定的日志传输属性
     以发送重做数据到至少一个备数据库。
  2).最大可用(maximize availability):
     在正常情况下，最大可用模式和最大保护模式一样；在standby不可用时，最
     大可用模式自动最大性能模式，所以standby故障不会导致primay不可用。只要至少有一个standby可用的情况下，
     即使primarydown机，也能保证不丢失数据。
     这种保护模式提供了可能的最高级别的数据保护，而不用与主数据库的可
     用性相折衷。与最大保护模式相同，在恢复事务所需的重做写到本地联机重做日志和至少一
     个事务一致性备数据库上的备重做日志之前，事务将不会提交。与最大保护模式不同的是，
     如果故障导致主数据库无法写重做流到异地备重做日志时，主数据库不会关闭。替代地，主
     数据库以最大性能模式运行直到故障消除，并且解决所有重做日志文件中的中断。当所有中
     断解决之后，主数据库自动继续以最大可用性模式运行。
     这种模式确保如果主数据库故障，但是只有当第二次故障没有阻止完整的重做数据集从
     主数据库发送到至少一个备数据库时，不发生数据丢失。
  3).最大保护(maximize protection):
     最高级别的保护模式。primay上的事务在commit前必须确认redo已经传递到至少
     一个standby上，如果所有standby不可用，则primary会挂起。该模式能保证零数据丢失。
     这种保护模式确保如果主数据库发生故障不会发生数据丢失。要提供这种级别的
     保护，恢复每个事务所需的重做数据必须在事务提交之前同时写到本地联机重做日志和至少
     一个备数据库上的备重做日志。要确保不发生数据丢失，如果故障导致主数据库无法写重做
     流到至少一个事务一致性备数据库的备重做日志时，主数据库会关闭。
     比如说用户commit，此时候会刷新redo buffer写入redolog中。在此模式时候，必须要保证redo buffer信息
     写入redo log和备机的一个redo中。不然就数据库挂。貌似这样。没测试过。有空测试下。
   说明：
    max protection的定义是事务提交的前提是redo data必须写入本地online log及至少一个standby log，如果没有满足这个条件，则该事务不能提交，数据库会自动down掉
    max available模式的定义是事务提交的前提是redo data必须写入本地online log及至少一个standby log，如果没有满足这个条件，则该事务不能提交，但是数据库不会自动down掉。数据库会降格为max performance模式，只有当所有的redo data传递到standby logfile后，这个数据库才会自动升格为max availabity模式
    max performance模式的定义是在不影响主数据库的性能的情况下最大限度的保护数据的安全。redo data在写入online log之后，事务就可以提交。所以前两种模式在主数据库和备用数据库之前的网络断掉之后，都会影响主数据库的可用性，但是max performance模式，在网络断掉之后，不会影响主数据库的可用性
    max protection模式和max availability模式的要求是在data guard环境中至少有一个standby数据库的log_archive_dest_n设置为sync lgwr affirm模式
data guard模式所处的模式可以在v$database数据库查询到
数据传递过来只会备份到一个地方，因为是从网络过来的数据，网络的那边还需要得到确认
2、查看当前保护模式
   SQL> select DATABASE_ROLE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;
   DATABASE_ROLE PROTECTION_MODE PROTECTION_LEVEL
   ---------------- -------------------- --------------------
   PRIMARY MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE
   注意：还有RESYNCHRONIZATION状态，出现这种情况的因素可以是由于standby 数据库shutdown 后,primary 数据库保护级别切换为待同步。
3、切换standby的保护模式
   SQL>ALTER DATABASE SET STANDBY DATABASE TO maximum protection;
   SQL>ALTER DATABASE SET STANDBY DATABASE TO maximum performance;缺省的保护模式
   SQL>ALTER DATABASE SET STANDBY DATABASE TO maximum availability;
   说明：切换保护模式的操作必须在primay执行，且primay必须处于mount状态，如果在open状态执行，则报ORA-01126错。
         ORA-01126: database must be mounted EXCLUSIVE and not open for this operation。
   SQL> shutdown immediate;
   SQL> startup mount;
   SQL> alter database set standby database to maximize availability;
   SQL> alter database open;
        注：此处会报ORA-03113错误。
        ORA-03113: end-of-file on communication channel
        这时需要先修改日志传送方式为lgwr同步方式，否则，数据库是无法open的。
   SQL> conn / as sysdba
   SQL> startup mount;
   SQL> alter system set log_archive_dest_2='service=test lgwr sync';
   SQL> alter database open;
   说明：
      1)、切换成maximize protection也需要类似的步骤，这里就不演示了。
      2)、在10gR2的data guard中，按照上述步骤切换保护模式的时候却不成功。主库完成切换语句后再open就报错：
          ORA-03113: end-of-file on communication channel。看alert文件，只要是ORA-16072: a minimum of
          one standby database destination is required。但实际上备库的standby logfile都已经建好了，检查
          参数设置也查不出问题。
      3)、解决方法：将主备库的flashback打开：
   SQL> shutdown immediate;
   SQL> startup mount;
   SQL> select FLASHBACK_ON from v$database;
   FLASHBACK_ON
   ------------------------------------
   NO
   SQL> alter database flashback on;
   总结：然后再切换到最大可用或者最大保护模式就ok了,切换前注意备库已经处于mount状态，并且主库原有的归档日志都已经
   全部复制到备库对应的归档目录下了，否则传送方式由arch改成lgwr后这些差异日志就无法自动传过去了。
   今天做10gR2备库的一个试验中，就是由于这个原因，导致切换成最大保护模式后，主库无法open，
   老是报错:ORA-03113: end-of-file on communication channel。查看alert日志里都是
   ORA-16072: a minimum of one standby database destination is required错误，这个错误有点让人纳闷，明明参数都是正确设置的，
   却报这么个错误。后来将主库的所有归档日志手动复制到备库后，启动正常。