Data Guard 体系结构

      RAC的强项在于解决单点故障和负载均衡，但RAC方案中数据只有一份，数据本身没有冗余，容易形成单点故障
      而Data Guard是通过冗余数据来提供数据保护，通过日志同步机制保证冗余数据和主数据之间的同步
      这种同步可以是实时、延时，同步或者异步
     
      ㈠ 日志发送
        
         主库的日志由LGWR或ARCn负责从主库发送到其他一个或多个归档目标
         不同的归档目标可以使用不同的方法，但是同一个目的地只能选用一种方法
         归档目标由log_archive_dest指定
         可以指定本地，也可以指向远端的Service Name
         最常见的启动数据库归档模式就是设置了一个本地归档路径
        
         ① 使用ARCn进程 （延时）
           
            缺省主库便是使用ARCn进程发送日志
           
            ⑴ 主库redo被LGWR写到online redo log
            ⑵ 当一组online redo log满，会发生log switch，触发本地归档       
            ⑶ ARCn进程通过Net把已经归档的日志发送给备库的RFS进程
            ⑷ RFS进程把接收到的日志写到归档日志
            ⑸ 备库的MRP进程或LSP进程应用日志以同步数据
           
            ARCn进程传递最大的问题是，主库只有在发生归档时才会发送日志到备库
            online redo log中的redo entries可能会丢失
           
         ② LGWR sync方式  (Oracle 推荐使用)
        
            什么是sync?
           
            答：
               LGWR必须等待写入online redo log操作和通过LNSn进程的网络传送都成功
               主库的事务才能commit，这便是sync的含义所在
           
            ⑴ LGWR把redo entries写到online redo log的同时还要发送给本地的LNSn进程
               再由LNSn把日志通过Net发送给远端归档目标
               每个远程目的地对应一个LNS进程，多个LNS进程可以并行工作
              
            ⑵ 备库的RFS进程把接收到日志写入standby redo log
            ⑶ 主库的switch log也会触发备库对standby redo log的归档
               然后触发备库的MRP或LSP进程应用日志
            因为主库的redo是实时传送，于是备库可以使用两种方式恢复：
              * 实时恢复：直接从standby redo logs取
              * 归档恢复：需从archived log取
            使用LGWR的sync方式时，建议带上参数net_timeout
            log_archive_dest_2='service=stdby lgwr sync net_timeout=30'
           
            LGWR的sync方式最大的问题是，依赖于网络状况
   
         ③ LGWR async方式
           
            ⑴ LGWR只需写入noline redo log即可，不必等待LNSn的网络传送成功
            ⑵ LNSn异步把redo发送到备库，多个LNSn可以并发发送
            ⑶ 主库log switch也会触发备库对standby redo log的归档
               然后触发MRP或LSP应用日志
              
            async也只是归档恢复，无须指定net_timeout
           
           
      ㈡ 日志接收
     
         RFS进程收到的日志写入standby redo log还是archived log
         取决于主库的日志传送方式和备库的配置
         当写到standby redo log时，主库log switch也会连带对standby redo log进行归档
        
         备库配置说明：
         ① 如果配置了standby_archive_dest,则使用这个参数指定的目录
         ② 如果某个log_archive_dest_n明确定义valid_for=(standby_logfile,*),则使用这个目录
         ③ 如果数据库的compatible>=10.0,则选取一个log_archive_dest_n的值
         ④ 如果standby_archive_dest和log_archive_dest_n都没有指定，则使用
            standby_archive_dest的缺省值：$ORACLE_HOME/dbs/arch
           
      ㈢ 日志应用
     
         ① physical standby使用media recovery技术应用
            即：redo apply
           
            ⑴ 实时应用
               这种方式必须指定standby redo log
               每当日志被写入standby redo log时，便会触发恢复
               好处在于可以减少数据库角色却换的时间
               因为却换时间主要用在剩余日志内容的恢复上
              
            ⑵ 归档应用
               这种方式在主库log switch时，会触发备库的归档操作
               归档后会触发恢复，这也是缺省的恢复方式
              
         ② logical standby使用logminer技术应用
            即：sql apply
           
         physical standby启用实时应用：
         alter database recover managed standby database using current logfile；
        
         logical standby启用实时应用：
         alter database start logical standby apply immediate;
        
         查看是否使用了实时应用：
         select recovery_mode from v$archive_dest_status;
        
      ㈣ 自动裂痕检测
         当主库的某些日志没有成功发送到备库，这时就发生了archive gap
         缺失的这些日志就是gap
         DG能够自动检测并处理gap，不需DBA介入
         这需要配置fal_client,fal_server（fetch archive log）
         向谁要日志就是server，server不仅限于主库，可能是备库
         所以，在DG中，主库、备库只是角色概念，并不固定在某个库上
        
         当然，DBA可以介入
        
          ① 确认备库少了的日志
          ② 把缺失的日志从主库拷贝到备库
          ③ 在备库手工注册这些日志：
             alter database register logfile 'logfilename';
            
      ㈤ 三种数据保护的模式
     
         ① 最大保护(Maximum protection)：
               所有的事务在提交前至少一个standby数据库redo数据被同步写入
               如果出现了什么故障导致standby数据库不可用的话，primary数据库会被shutdown
              
         ② 最高性能(Maximum performance)：
               事务可以随时提交，当前primary数据库的redo数据也需要至少写入一个standby数据库

               不过这种写入可以是不同步的

               这是一种缺省模式

              
         ③ 最高可用性(Maximum availability)：
               和maximum protection一样，至少一个standby数据库redo数据被同步写入
               不过与之不同的是，如果出现故障导入无法同时写入standby数据库redo log，primary数据库并不会shutdown

               而是自动转为最高性能模式，等standby数据库恢复正常之后，它又会再自动转换成最高可用性模式

               它是一种狡猾的模式、平时以最大保护运行、一旦遇到故障、就自动却换为最大性能模式

               这是很多人的选择、如果带宽足够(当然、现在的带宽很足的说)、强烈建议转换为这个模式

   
      ㈥ 角色转换
        
         一套DG环境只有两种角色：primary和standby
         却换也只有两种：
           switchover：无损却换，不会丢失数据
                       两个阶段：
                       ① 主库却换成备库
                       ② 备库却换成主库
                      
             failover：可能丢失数据，并且却换后，原主库就不属于该DG环境的一份子