Data Guard系列之--基本概念

Data Guard基本概念

            Data Guard专门用来保护oracle数据，可在提供高级别的数据保护和可用性的同时，使oracle数据库保持最卓越的性能。作为oracle内核自带的一项功能，Data Guard和oracle的其他高可用性技术集成在一起----典型的有oracle真正应用集群（Real Application Clusters,RAC），Oracle恢复管理器（Recovery Manager,RMAN）和Oracle闪回（Flash）技术等。

            Data guard的运行遵循一个简单原则：传输重做数据（redo）,然后应用redo。Redo中包括oracle数据库恢复数据库事务需要的所有信息。生产数据库（primary database ）将redo传输给一个或多个独立的副本（standby databases ）。Data Guard备用数据库处于连续的恢复状态，验证并应用重做数据，从而与主库保持同步。如果主库和备库直接发生中断，Data Guard还会自动重新同步备用数据库。下图概括了Data Guard传输--应用架构

1，生成重做数据时，重做传输服务将重做数据从主库传输到备用数据库

2，应用服务验证重做数据并更新备用数据库文件

3，独立于data guard，数据库写进程更新主数据库文件

4，在网络中断或备用数据库停止后，Data Guard使用已在主数据库上归档的重做数据，自动重新同步备用数据库

        Data Guard重做传输服务（Redo Transport Service）协调从主数据库到备用数据库的重做数据传输过程。同时，主数据库的LGWR进程将重做数据写入到自己的ORL中，一个独立的Data Guard进程从SGA的重做缓冲区中读取信息，交由Oracle Net服务传输到备份数据库，这个进程称为Log Network Server(LNS)。

Data Guard的灵活架构允许将重做数据从一个主数据库直接传给一个或多个（最多9个）备用数据库。主数据库或者备用数据库都可以用作Oracle RAC数据库。每个活动的主实例都生成自己的重做线程并且拥有相应的LNS进程，或者将重做数据传给备用数据库。

       由LNS传输的重作记录在备用数据库由另一个Data Guard进程Remote File Server(RFS)接收。RFS在备用数据库上接收。RFS在备用数据库上接收重做数据，然后将其写入一个名为备用重做日志（Standby Redo Log,SRL）文件的顺序文件中。在多备用配置中，主数据库的独立LNS进程管理针对每个备用数据库的重做传输。例如，如果配置为3个备用数据库，每个主数据库实例中就有3个LNS进程处于活动状态。

Data Guard支持两种使用LNS进程的重做传输方法：同步传输和异步传输

Data guard重做传输进程架构：

同步重做传输

同步传输（synchronous transport,SYNC）又称“零数据损失”方法，因为要等到LNS确认事物恢复所需的重做数据已被写入到备用站点的磁盘上，才允许LGWR认可提交操作成功。

Sync重做传输架构

（1）用户提交一个事物，事务在SGA中创建一个重作记录。LGWR从日志缓冲区中读取重做记录，写入ORL，然后等待LNS确认

（2）LNS从日志缓冲区中读取相同的重做记录，通过Oracle Net服务传给备用数据库。备用数据库上的RFS接收重做数据，然后将其写入备用重做日志文件中。

（3）当RFS从磁盘接收到一个写完消息时，会将一个确认消息回传给主数据库上的LNS进程，LNS进程接着通知LGWR传输完成。LGWR接着向用户发送提交确认消息。

    异步重做传输

   异步传输（aysnchronous transport,ASYNC）与SYNC的不同之处在于，LGWR不必等待来自LNS的确认消息，无论主数据库与备用数据库相距多远，都几乎不会影响到主数据库的性能。

    重做传输压缩

     在使用ASYNC时，还需要确定通过压缩重做数据来减少所需带宽是否有利。Oracle企业版11g具有一个新产品，成为“高级压缩选项”。这个新产品包括多想压缩功能，其中一项是data guard的重做传输压缩。ASYNC重做传输压缩会增加CPU使用率，但在带宽受限的环境中，这决定了能否实现恢复点目标。

    自动处理间隔
    每当LNS进程停止将重做数据传输到备用数据库，而主数据库却继续提交事务时，就会出现日志文件间隔。每次网络或备用数据库失效时，将可能产生这种情况，具体取决于Data Guard配置实现方式。在此状态下，主数据库的LGWR进程继续写入到当前的ORL，填满ORL后，会切换到一个新的ORL。此时归档进程会在本地归档已经填满的ORL。在繁忙的系统中，在主备数据库之间的链接还原之前，次循环会重复多遍，从而生成很大的日志文件间隔。

       在中断期间，Data Guard在主数据库上使用ARCH进程连续ping备用数据库来确定其状态。当还原与备用数据库的通信后，ARCH ping进程会查询备用控制文件（通过其RFS进程），来确定备用数据库从主数据库收到的最后一个完整日志文件。Data Guard确定需要哪些日志文件来重新同步备用数据库，然后立即开始使用其他ARCH进程传输相应文件。在接下来执行日志切换时，LNS会试图连接备用数据库，成功后开始传输当前重做数据，而ARCH进程在后台处理间隔。

上图中的虚线表示传输和应用所需的重做数据来处理日志文件间隔。一旦备用应用进程能赶上当前重做记录的进度，应用程序就自动切换，不再读取归档重做日志，改而读取当前SRL。从10g开始，主数据库的一个ARCH进程一直专门负责本地归档，从而确保在处理间隔期间，远程归档操作不影响主数据库回收其ORL。