精华内容
下载资源
问答
  • 数据库容灾技术之–数据容灾技术比较 转自:http://blog.csdn.NET/quitepig/article/details/8351209 一、概述近几年来,容灾已经成为信息数据中心建设的热门课题。很多容灾技术也快速发展起来,对用户来说也有很...

    数据库容灾技术之–数据容灾技术比较

    转自:http://blog.csdn.NET/quitepig/article/details/8351209

    一、概述

    近几年来,容灾已经成为信息数据中心建设的热门课题。很多容灾技术也快速发展起来,对用户来说也有很广阔的选择余地。但由于容灾方案的技术复杂性和多样性,一般用户很难搞清其中的优劣以确定如何选择最适合自己状况的容灾解决方案。本文我们就容灾建设中的备份及复制技术做一个初步探讨,希望能对客户的数据中心容灾建设提供一些参考。

    目前有很多种容灾技术,分类也比较复杂。但总体上可以区分为离线式容灾(冷容灾)和在线容灾(热容灾)两种类型。

    二、离线式容灾

    所谓的离线式容灾主要依靠备份技术来实现。其重要步骤是将数据通过备份系统备份到磁带上面,而后将磁带运送到异地保存管理。离线式容灾具有实时性低、可备份多个副本、备份范围广、长期保存、投资较少等特点,由于是备份一般是压缩后存放到磁带的方式所以数据恢复较慢,而且备份窗口内的数据都会丢失,因此一般用于数据恢复的RTO(目标恢复时间)和RPO(目标恢复点)要求较低的容灾。也有很多客户将离线式容灾和在线容灾结合起来增加系统容灾的完整性和安全性。

    目前主流的备份软件主要有:

    l  Symantec Veritas NetBackup

    l  EMC Legato NetWorker

    l  IBM Tivoli Storage Manager

    l  Quest BakBone NetVault

    三、在线容灾

    在线容灾要求生产中心和灾备中心同时工作,生产中心和灾备中心之间有传输链路连接。数据自生产中心实时复制传送到灾备中心。在此基础上,可以在应用层进行集群管理,当生产中心遭受灾难出现故障时可由灾备中心接管并继续提供服务。因此实现在线容灾的关键是数据的复制。

    和数据备份相比,数据复制技术具有实时性高、数据丢失少或零丢失、容灾恢复快、投资较高等特点。根据数据复制的层次,数据复制技术的实现可以分为三种:存储系统层数据复制操作系统数据复制和数据库数据复制。

    1、存储系统层数据复制

    现在的存储设备经过多年的发展已经十分成熟。特别是中高端产品,一般都具有先进的数据管理功能。远程数据复制功能几乎是现有中高端产品的必备功能。要实现数据的复制需要在生产中心和灾备中心都部署1套这样的存储系统,数据复制功能由存储系统实现。如果距离比较近(几十公里之内)之间的链路可由两中心的存储交换机通过光纤直接连接,如果距离在100公里内也可通过增加DWDM等设备直接进行光纤连接,超过100公里的距离则可增加存储路由器进行协议转换途径WAN或INTERNET实现连接,因此从理论上可实现无限制连接。

    存储系统层的数据复制技术对于主机的操作系统是完全透明的,是对于将来增加新的操作平台,可不用增加任何复制软件的投资,即可完成实现复制。这样管理比较简单,最大程度保护了用户的投资,达到充分利用资源的目的。基于存储的复制一般都是采ATM或光纤通道做为远端的链路连接,不仅可以做到异步复制,更可以做到同步复制,使两端数据可做到实时同步的目的,保证了数据的一致性。缺点是由于基于存储是由存储硬件厂商提供的,在兼容性方面有局限性。用户要使用同一厂商的devices,给用户造成的选择面太小,成本容易提高,并且对线路带宽的要求通常也较高。对于预算充足,存储环境不是很复杂的企业来说,选择基于存储的技术比较适合。

    存储系统层的数据复制基于同构的存储,各个存储厂商都有自己的复制软件,如IBM PPRC、EMC SRDF、HP Continues Access、HDS TrueCopy等,以下举例说明存储系统层的数据复制原理。

    远程镜像(CA)介绍

    HP Continuous Access XP 通过向远地镜像复制数据来满足系统的高可用性和灾难恢复的需求。它通过同步模式,将数据从一台XP磁盘阵列上拷贝到远端的另一台XP磁盘阵列上,从而实现容灾解决方案。

    Continuous Access XP Extension 使Continuous Access XP能够以高性能的异步或同步方式进行远程XP磁盘阵列的拷贝。根据标书中的要求,必须同时提供同步和异步的存储复制方式,CA完全满足。

    CA是基于磁盘阵列的容灾方式。其中, CA能够实现同步/异步、同城集群/洲际集群,以及Solaris、AIX、Windows各种OS集群扩展,还可以实现新XP到新XP、老XP到新XP以及多中心容灾等功能,全面实现了可用性与可扩展性的结合。

    CA同步加上CA异步,在本地和远程XP磁盘阵列之间实现高性能实时远程数据镜像,以及快速切换及回切,使用户能轻松管理,并实现高可用性。CA同步方式的距离可以达到100公里,但是从性能的角度出发,一般都控制在50公里内。可以建设同城容灾集群,消除计划宕机时间,降低非计划的宕机时间;异步方式的距离可以达到数千公里,可以集成远程数据镜像和异构服务器的集群,增强总体方式的可用性,在同城灾难发生的时候,保证连续运作。其中,洲际集群没有距离的限制,对应用和数据完全透明,可实现全球范围的容灾方案。

    同时,针对关键用户的特殊需求,CA可以实现多中心容灾解决方案,其中,同步容灾中心的距离可以达到50公里,异步中心可以在全球的任何一个地方,至少有三个中心有镜像的数据,而且三个中心之间可以实现远程容灾。


    (1)CAXP磁盘卷组

    CAXP的磁盘卷组由不同的XP装置内或不同CLUSTER内命名为P-VOL和S-VOL的2个逻辑磁盘卷构成。在具有CAXP磁盘卷组关系后:

    P-VOL被称为主磁盘卷。P-VOL可被读/写。

    S-VOL(远程磁盘卷)被称为副磁盘卷。在XP内部的控制装置的作用下,P-VOL的内容和服务器来的写数据被拷贝到S-VOL(可采用同步或异步两种方式)。CAXP卷组建立后,S-VOL为只读磁盘卷。在一个XP里,既可有P-VOL,也可有S-VOL,这样可以实现双向数据境像。

    CAXP的磁盘卷组,即P-VOL和S-VOL间,可以是相同的RAID类型,也可以是不同的RAID类型,具体的RAID级别配合表如下所示:

     

    For P-VOL

    For S-VOL

    RAID 1

    RAID 1

    RAID 5

    RAID 5

    RAID 1

    RAID 5

    RAID 5

    RAID 1

    CAXP的RAID级别

    (2)MCU和RCU

    MCU(主磁盘控制器)和RCU(远程磁盘控制器)分别和P-VOL,S-VOL相连,MCU控制由服务器来的写向P-VOL的数据的写操作,还控制P-VOL和S-VOL之间数据拷贝的操作,并且提供CAXP磁盘卷组的状态和构成的管理。

    RCU执行由MCU发出的写命令操作。写操作的执行方法和执行服务器来的写操作过程相同。除此之外,RCU还具有管理一部分CAXP磁盘卷组的状态和构成信息的能力。

    对于任何一个磁盘卷组,都需要定义MCU/RCU。一个XP的磁盘控制装置在控制P-VOL时,可作为MCU使用,当控制S-VOL的时侯,可作为RCU使用。

    (3)CA的同步和异步复制

    基于存储的数据复制,主要有同步数据复制和异步数据复制两种。

    同步数据复制,指通过将本地生产数据以完全同步的方式复制到异地,每一本地IO交易均需等待远程复制的完成方予以释放。

    同步方式的数据复制

    同步复制方式的传输距离限制:

    l  FC光纤通道最大传输距离为10KM;

    l  ESCON通过中继方式最大可传输43KM;

    l  DWDM方式最大传输距离为100KM

    异步数据复制则是指将本地生产数据以后台同步的方式复制到异地,每一本地IO交易均正常释放,无需等待远程复制的完成。

    异步方式的数据复制

    同步复制实时性强,灾难发生时远端数据与本地数据完全同步。但这种方式因为数据在网络中的传输延迟而影响主节点的应用性能。

    异步复制则不然,但可能导致灾备点数据比主点数据有一定延迟,这些延迟的数据在灾难发生后将丢失。由此可见,同步方式和异步方式实际上是各有千秋,需要依据具体的应用,在应用性能和潜在的可能丢失数据量之间作一个取舍和均衡。

    (4)CAXP卷组的更新拷贝模式

    在组建灾难备份系统时,往往是假定正在使用的主中心的存储数据受到毁坏。这时启动远程备份中心的备份存储系统,来接替主中心的工作或从备份存储设备中把数据恢复到主中心端,在主中心重新启动应用。不论使用哪种方法,远程备份中心的备份数据与主中心端数据的一致性将会决定灾难恢复的时间。在灾难发生后,为了尽可能减少花在数据一致性分析上的时间,以XP1024存储为例,XP1024提供用于灾难备份的CAXP磁盘卷组的拷贝模式的设定选择来加快事后分析数据的一致性。

    远程数据拷贝操作

    更新拷贝模式(Fence Level)共有3种:Data、Status、Never。CAXP卷组的状态在变为“Suspend”后,更新拷贝模式将会对P-VOL的写操作产生影响,在建立灾难备份系统方案时,应预先考虑好CAXP卷组的一致性要求,对应的拷贝模式可由下表选出:

    Type of Failure

     

    S-VOL Data

    S-VOL Status

    Never

    The update copy operation failed,and the MCU was not able to change the status of the S-VOL to suspended

    Write I/O operations to the P-VOL will be:

     

    REJECT

    Accepted

    Accepted

    The update copy operation failed,and the MCU was not able to change the status of the S-VOL to suspended

    Write I/O operations to the P-VOL will be:

     

    REJECTED

    REJECTED

    Accepted

    l  更新拷贝模式:Data——在这个模式下,P-VOL和S-VOL的一致性会完全被保证。当两个卷组之间不能保证同步时,即当卷组状态变为Suspend时,MCU将会拒绝对服务器对P-VOL的写操作以保证两个磁盘卷的一致性。这种模式在灾害发生时将会最大限度的减少数据一致性分析所花的时间。(注:初期拷贝完成之前,如果灾害发生,将导致P-VOL和S-VOL的数据不一致,因此不能把S-VOL用于灾害恢复)。在Data这种拷贝模式下,一旦FC线路或S-VOL出现故障,都将使P-VOL的写操作停止,并向系统发出写错误信息中断系统的应用。

    l  更新拷贝模式:Status——当MCU检测出CAXP卷组之间失去同步后,且无法将S-VOL的状态改变为Suspend时,MCU会拒绝服务器向P-VOL的写操作,并对服务器发出写错误的信息。当FC链路失效时这种模式会起作用,如果客户认为S-VOL的偶尔失去同步是可容忍的,这种模式可被使用。当S-VOL由于某种原因失效时,并且卷组状态成功地变为Suspend时,P-VOL的读写操作可继续进行,这时P-VOL里更新过的磁道会被记录下来,当S-VOL被恢复后,更新数据不会自动的被拷贝到S-VOL,而需要重新同步这个卷组,数据的更新拷贝才会被执行。

    l  更新拷贝模式:Never——在CAXP卷组失去同步后,无论S-VOL的状态能否被改为Suspend,服务器对P-VOL的写操作不会被中止。在这种模式下,只要P-VOL自己不出现故障,服务器传来的写操作就会被执行。当FC Link或S-VOL由于某种原因失效后,P-VOL的更新磁道将会被MCU记录下来。故障排除后,用卷组激活命令可重新同步P-VOL和S-VOL,这时,只拷贝P-VOL里的更新磁道。

    Data及Status模式对保持数据一致性非常有好处的,但在线路或远端XP1024故障时会对主服务器造成造成一定的影响,甚至导致应用系统挂起。

    在这种拷贝模式下建立起来的CAXP镜像卷组,即使在光纤或S-VOL故障引起P-VOL和S-VOL镜象卷组失去同步后,只要P-VOL没有遭到损坏,MCU就不会据绝服务器对P-VOL发出的写操作。

    从服务器端来看,P-VOL对S-VOL镜象卷的数据更新象在正常进行,服务器的应用也不会被中断。当出现光纤、DWDM、远地备份中心XP1024停电等故障时,因为不影响应用的运行,所以没有必要象“DATA”那样强制中断CAXP卷组的工作。同时必须在网管上采用必要手段,监控XP1024 Pair的状态。一旦Pair状态变成非duplex,必须尽快采取措施进行修复,否则一旦发生灾难,由于远地的XP1024 CA拷贝与主site的数据不同步,灾难系统切换将会失败,导致不必要的停机。

     

    虚拟存储技术的介绍

    近年来,随着存储技术的不断发展,在存储系统层次数据复制技术上还出现基于网络的存储虚拟化设备来实现,这种方式的特点是依靠外加的网络层设备来实现两个存储设备之间的数据复制,数据复制过程不占用主机资源,两个存储之间的数据同步在网络层完成。

    根据存储虚拟化设备工作机制的不同,一般可分为带内(In-Band)和带外(Out-of-Band)两种。

    存储虚拟化设备通过交换机分别连接主机端Fabric 和存储端 Fabric,主要功能是管理对存储设备上的逻辑卷,对已有逻辑卷进行虚拟化或创建虚拟的条带卷,消除存储设备异构对主机系统的影响,提高存储设备的可用性和总体性能。另外一个功能就是卷复制和镜像,通过存储虚拟化设备实现两个虚拟卷之间的数据安全保护。

    通过存储虚拟化设备实现卷镜像复制功能的优势在于操作由存储虚拟化设备来完成、压力集中的存储虚拟化设备上,不需要主机参与,数据复制进程安全稳定。缺点是需要增加专用存储虚拟化设备,带外方式有的需要在主机端需要安装存储虚拟化设备的客户端软件,比如 UIT SVM;有的需要依赖高端智能交换机,比如 EMC VSM。目前使用这种技术的产品还不是很多,成熟性还有待提高,具有这种功能的专用设备价格也相对较高,所以采用这种方案的用户比较少。

     

    2、操作系统数据复制

    主要通过操作系统或者数据卷管理器来实现对数据的远程复制。这种复制技术要求本地系统和远端系统的主机是同构的,其实现方式是基于主机的数据复制,容灾方式工作在主机的卷管理器这一层,通过磁盘卷的镜像或复制,实现数据的容灾。这种方式也不需要在两边采用同样的存储设备,具有较大的灵活性,缺点是复制功能会多少占用一些主机的CPU资源,对主机的性能有一定的影响

    目前基于原厂的逻辑卷管理软件如IBM AIX LVM、HP-UINX MirrorDisk、Sun Solaris SVM等可以实现在本厂平台上的逻辑卷镜像,专业的数据复制软件提供了更大的灵活性,支持多个平台的逻辑卷镜像,其中代表性的软件是Symantec VERITAS Storage Foundation 软件。

    Symantec VERITASStorage Foundation简介

    (1)Symantec远程镜像数据容灾原理

    Symantec的VERITAS Storage Foundation的镜像技术构建容灾系统是比较简单的,它只有一个条件,就是将生产中心和灾备中心之间的SAN存储区域网络通过光纤连接起来,建立城域SAN存储网络。然后就可以通过Storage Foundation提供的非常成熟的跨阵列磁盘镜像技术来实现同城容灾了,容灾方案的结构如下图所示:


    从镜像原理上讲,在城域SAN存储网络上的两套磁盘系统之间的镜像,和在一个机房内的SAN上的两个磁盘系统之间的镜像并没有任何区别。

    利用裸光纤将生产中心和灾备中心的SAN网络连接起来,构成城域SAN网络以后,利用 VERITAS Storage Foundation的逻辑卷管理功能,就可以实现生产中心磁盘系统和灾备中心磁盘系统之间的镜像了。如下图所示:

    在逻辑卷镜像过程中,利用VERITAS Storage Foundation,可以创建任意一个逻辑卷(Volume)供业务主机使用,实际上是由两个完全对等的,容量相同的磁盘片构成的,两个磁盘片上的数据完全一样,业务主机对该Volume的任意修改,都将同时被写到位于生产中心和灾备中心的两个磁盘系统上。

    采用这种方式,生产中心的磁盘阵列与同城容灾中心的磁盘阵列对于两地的主机而言是完全同等的。利用城域SAN存储网络和VERITAS Storage Foundation镜像功能,可以实现数据系统的异地容灾。并且消除了复制技术(无论是同步还是异步)的切换的动作,从而保证零停机时间,零数据损失的实现。

    (2)Symantec远程镜像数据容灾的技术特点

    l  零停机时间和零数据损失

    由于Storage Foundation 采用的是跨异构阵列的镜像技术,而镜像技实现原理,就决定了在这种方式下,无论是哪一边的磁盘阵列由于物理故障停顿,都不会影响数据的可用性而造成数据的损失,这从根本上实现了在物理故障的情况下,数据的高度可用性。

    l  故障修复后的快速重新同步

    Storage Foundation 提供的镜像技术,是基于日志的镜像技术,无论由于主机发生故障,还是由于镜像中的链路或是硬盘发生故障导致的镜像被破坏的情况,都可以通过镜像日至得以快速恢复。这使得镜像恢复过程对系统的性能影响微乎其微。

    l  跨磁盘阵列快照,实现逻辑错误快速恢复和容灾中心数据利用

    Storage Foundation 提供基于卷,以及文件系统的多种快照技术,其逻辑辑快照可采用少量磁盘空间,快速,多次的对文件系统,或者是卷作快照。因而,当用户出现数据的逻辑错误时,利用快照就可以迅速恢复文件系统或卷。这在数据保护的体系,大大的弥补了传统备份恢复保护方式速度慢的缺陷,从而把数据损失量降到最低限度。

    同时,数据快照还被广泛的利用在容灾中心数据利用方面,比如可以通过快照实现数据备份、查询、测试等。

    l  数据同步过程高度可控

    Storage Foundation Remoter Mirror 提供完整的容灾命令集,在数据同步的过程中,可以随时得知同步的进度,并可随时暂停、继续数据同步。

     

    4、数据库数据复制

    数据库数据复制技术通常采用日志复制功能,依靠本地和远程主机间的日志归档与传递来实现两端的数据一致。这种复制技术对系统的依赖性小,有很好的兼容性。缺点是本地复制软件向远端复制的是日志文件,这需要远端应用程序重新执行和应用才能生产可用的备份数据。

    目前基于数据库的复制技术主要有:Oracle DataGuard、Oracle GoldenGate、DSG RealSync、Quest SharePlex 、IStream DDS等,以下举例说明该复制技术的运行原理。

    DataGuard软件介绍

    OracleData Guard 是管理、监控和自动化软件的基础架构,它创建、维护和监控一个或多个备用数据库,以保护企业数据结构不受故障、灾难、错误和崩溃的影响。

    DataGuard 使备用数据库保持为与生产数据库在事务上一致的副本。这些备用数据库可能位于距生产数据中心数千英里的远程灾难恢复站点,或者可能位于同一城市、同一校园乃至同一建筑物内。当生产数据库由于计划中断或意外中断而变得不可用时,Data Guard 可以将任意备用数据库切换到生产角色,从而使与中断相关的停机时间减到最少,并防止任何数据丢失。

    作为 Oracle 数据库企业版的一个特性推出的 Data Guard 能够与其他的 Oracle 高可用性 (HA) 解决方案(如真正应用集群 (RAC) 和恢复管理器 (RMAN))结合使用,以提供业内前所未有的高水平数据保护和数据可用性。

    (1)DataGuard重做应用和SQL应用

    备用数据库最初是从主数据库的一个备份副本创建的。一旦创建了备用数据库,Data Guard 自动将主数据库重做数据传输给备用系统,然后将重做数据应用到备用数据库中,从而使备用数据库保持为与主数据库在事务上一致的副本。

    DataGuard 提供了两种方法将这些重做数据应用到备用数据库中,并使之与主数据库在事务上保持一致。这些方法与 Data Guard 支持的两种类型的备用数据库对应:

    ●  重做应用,用于物理备用数据库

    ●  SQL应用,用于逻辑备用数据库

    (2)物理备用数据库—重做应用

    通过使用 Oracle 介质恢复应用从主数据库接收到的重做数据,物理备用数据库与主数据库保持同步。它在物理上与主数据库逐块相同,因而数据库模式(包括索引)是相同的。

    主数据库上的一个日志切换将触发备用数据库上的一个日志切换,从而使备用数据库上的归档器进程将当前的备用重做日志文件归档到备用数据库上的一个存档日志中。随后,Data Guard 重做应用使用一个专用进程(称为管理的恢复进程 (MRP))读取存档日志,并将重做数据应用到物理备用数据库中。如果启用了 Oracle Database 10g中的 Oracle Data Guard 的新功能—实时应用,则 MRP 将在 RFS 进程写满当前的备用重做日志文件时直接从其中读取重做数据。

    通过加载物理备用数据库并使用以下命令,可以在该数据库上启动 MRP(从而应用重做数据): ALTER DATABASE RECOVERMANAGED STANDBY DATABASE DISCONNECT FROM SESSION;介质恢复进程可以并行运行,以获得 Data Guard 重做应用的最佳性能。在 Oracle Database 10g 之前的版本中,这需要在上述RECOVER MANAGED STANDBY DATABASE 命令中使用 PARALLEL 子句。在 Oracle Database 10g中,MRP 可以在启动(无需 PARALLEL 子句)时自动确定并行恢复进程的最佳数量,这个数字视备用服务器上可用的 CPU 数量而定。

    物理备用数据库可以以只读方式打开,并且可以在其打开时对其运行查询,但无法在其以只读方式打开的同时运行恢复。在备用数据库以只读方式打开时,传送给它的重做数据将在备用站点上累积而不应用。不过,可以随时在物理备用数据库上恢复操作,并自动应用累积的重做数据。这允许物理备用数据库以一个序列运行,这个序列可能包括在恢复中运行一段时间,然后以只读方式打开来运行报表,接着重新运行恢复来应用尚未应用的重做数据。

    要以只读方式打开物理备用数据库,则需使用以下命令在备用数据库上取消恢复:ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;然后可以只读方式打开数据库:ALTER DATABASE OPEN。

    (3)逻辑备用数据库–SQL 应用

    尽管数据的物理组织和结构可能不同,但逻辑备用数据库包含与主数据库相同的逻辑信息。SQL 应用技术将从主数据库接收到的重做数据转换成 SQL 语句,然后在备用数据库上执行 SQL 语句,以使逻辑备用数据库与主数据库保持同步。从而,在将 SQL 应用到逻辑备用数据库上的同时,可以访问逻辑备用数据库来进行查询和报表操作。

     由于使用 SQL 语句更新逻辑备用数据库,因此它保持以读写模式打开,而从主数据库中更新的表可以同时用于诸如报表、合计、查询等其他任务如。.还可通过在维护的表上创建额外的索引和物化视图来优化这些任务。逻辑备用数据库可以承载多个数据库模式,用户可以对这些模式中不从主数据库进行更新的表上执行普通的数据处理操作。

    SQL应用使用许多并行的执行服务器和后台进程,它们将来自主数据库的更改应用到逻辑备用数据库中。下图显示了信息流和每一个进程所起的作用。

    这些不同的 SQL 应用进程可以通过在逻辑备用数据库上输入这条简单的命令来启动: ALTERDATABASE START LOGICAL STANDBY APPLY;出于每个 SQL 应用进程的考虑,读取器进程从存档日志(如果启用了实时应用,也可以是备用重做日志,)中读取重做记录。准备器进程将块更改转换成表更改或逻辑更改记录 (LCR)。在这里,LCR 并不代表任何特定的事务。构造器进程对来自各个 LCR 的已完成事务进行组合。分析器进程检查完成的事务,辨明不同事务之间的相关性。协调器进程(也称为逻辑备用进程,即 LSP)负责将事务分配给应用进程、监控事务之间的相关性以及批准将更改提交给逻辑备用数据库。应用器进程将已指定事务的 LCR 应用到数据库中,并在协调器指示提交事务时提交。Data Guard 提供视图来帮助查看每个进程的状态。

    (4)DataGuard数据保护模式

    l  最大保护模式

           最大保护模式为主数据库提供了最高水平的数据保护,从而确保了一个全面的零数据丢失灾难恢复解决方案。当在最大保护模式下运行时,重做记录由日志写入器(LGWR)进 程从主数据库同步地传输到备用数据库,并且直到确认事务数据在至少一个备用服务器上的磁盘上可用时,才在主数据库上提交事务。强烈建议,这种模式应至少配 置两个备用数据库。当最后参与的备用数据库不可用时,主数据库上的处理将停止。这就确保了当主数据库与其所有备用数据库失去联系时,不会丢失事务。

           由于重做传输的同步特性,这种最大保护模式可能潜在地影响主数据库响应时间。可以通过配置一个低延迟网络,并为它分配足够应付高峰事务负载的带宽来将这种影响减到最小。需要这种最大保护模式的企业有股票交易所、货币交易所、金融机构等。

    l   最高可用性模式

           最高可用性模式拥有仅次于最高水平的主数据库数据可用性。如同最大保护模式一样,重做数据由LGWR从主数据库同步地传输到备用数据库,直到确认事务数据在备用服务器的磁盘上可用时,事务才在主数据库上完成。不过,在这种模式下(与最大保护模式不同),如果最后参与的备用数据库变为不可用—例如由于网络连接问题,处理将在主数据库上继续进行。备用数据库与主数据库相比,可能暂时落在后面,但当它再次变为可用时,备用数据库将使用主数据库上累积的归档日志自动同步,而不会丢失数据。

           由于同步重做传输,这种保护模式可潜在地影响响应时间和吞吐量。可以通过配置一个低延迟网络,并为它分配足够应付高峰事务负载的带宽来将这种影响减到最小。

           最高可用性模式适用于想要确保获得零数据丢失保护,但不想让生产数据库受网络/备用服务器故障影响的企业。如果又一个故障随后影响了生产数据库,然后最初的网络/备用服务器故障得到解决,那么这些企业将接受数据丢失的可能性。

    l   最高性能模式

     最高性能模式是默认的保护模式。它与最高可用性模式相比,提供了稍微少一些的主数据库数据保护,但提供了更高的性能。在这种模式下,当主数据库处理事务时,重做数据由LGWR进程异步传输到备用数据库上。另外,也可以将主数据库上的归档器进程(ARCH)配置为在这种模式下传输重做数据。在任何情况下,均先完成主数据库上的写操作,主数据库的提交操作不等待备用数据库确认接收。如果任意备用目标数据库变为不可用,则处理将在主数据库上继续进行,这对性能只有很小的影响或没有影响。

    在主数据库出现故障的情况下,尚未被发送到备用数据库的重做数据会丢失。但是,如果网络有足够的吞吐量来跟上重做流量高峰,并且使用了LGWR进程来将重做流量传输到备用服务器,则丢失的事务将非常少或者为零。

    当主数据库上的可用性和性能比丢失少量数据的风险更重要时,应该使用最高性能模式。这种模式还适合于WAN上的DataGuard部署,在WAN中,网络的内在延迟可能限制同步重做传输的适用性。

     

    基于数据库日志跟踪分析的复制软件介绍

    目前市场数据库复制技术的工作原理大都与Oracle log相关,例如DNT IDR数据库复制产品就是通过对Oracle Log日志进行分析获取跟踪源系统的交易指令,然后将交易指令传到目标端进行重新执行的方式来实现数据复制的。本文以DNT IDR软件为例介绍基于数据库日志跟踪分析的复制原理。

    DNT IDR(以下简称IDR),是基于交易的逻辑级Oracle数据同步软件,利用数据库日志在线跟踪、分析技术,将生产数据库的交易信息以事务为单位,通过异步的方式,实时的传递、装载到目标数据库中,以达到源端、目标端数据保持同步的目的。是一种准实时同步软件。该软件具有以下特点:

    l  IDR不依赖硬件的同步能力,支持多种系统平台,具有部署简单、同步速度快、交易延迟时间短的特点。

    l  IDR能够支持不同Oracle版本之间的交易同步。

    l  IDR同步的目标数据库为在线打开状态,可以随时复用。

    l  IDR适用于(异构)热容灾、数据迁移、数据集中、数据分发、分担业务等应用领域。

    IDR利用数据库日志在线跟踪、分析技术,反向工程解析日志,将生产数据库的交易信息以事务为单位,通过异步的方式,实时的传递、装载到目标数据库中,以达到源端、目标端数据保持同步的目的。

    IDR技术原理与架构

    (1)IDR的同步原理

    a、历史数据同步

    使用快照方式:首次同步时,对于同步map所涉及的每一个表的同步过程如下:

    l  锁该表;

    l 记录同步时刻的scn;

    l 读取该表数据;

    l 在读取该表数据时接着将该表解锁,无需等待该表数据读取完毕。

    在表做开始同步的时刻,锁表是为了保证该表在日志中不会有交易发生,同时又因为记录了scn,也不会有多余的交易被抓取、也不会漏掉相关交易。

    开始读取数据时,利用了oracle数据库自身提供的“多版本”特性,能够保证读取数据的一致性。同时对该表进行解锁,又使该表被锁的时间不会太长从而严重影响正常交易。

    这种方式保证了源端在任何时刻下都可以进行首次数据的批量同步而不会影响同步数据的准确性。

    读文件方式:首次同步时,对于同步map所涉及的每一个表的同步过程如下:

    l 记录同步时刻的scn;

    l 读取该表数据;

    首次同步时,直接从oracle数据文件中读取该表数据,同时记录同步时刻的scn,由于这种方式要求在同步过程中,没有交易产生,因此会保证历史数据抓取的准确性。在同步完成后,将变化数据实时抓取。

    b、交易抓取

    IDR通过事先创建的试图来捕获日志变化,由于每次捕获的日志的物理位置都会记录,因此可以得出日志变化量。

    后续的抓取日志、分析交易、传输交易,完全由IDR独自完成,不使用oracle数据库任何资源。

    在每次抓取的日志量处理完成后,记录在IDR的缓存目录中,因此对于日常运行过程中,IDR停止或其它原因需要读取归档日志时,根据记录的日志物理位置来定位需要抓取的归档日志。

    IDR抓取日志跟oracle数据库是写日志是并行操作而又互不影响。

    正常情况下,IDR都是准实时的抓取变化日志量。

    对于源端是rac环境来说:rac环境中,在每一个实例所在的主机操作系统上可以读取另外主机的在线日志(包括归档日志)。通过每一个实例的日志和scn来保证交易顺序的准确性。

    c、交易分析

    严格按照源端Oracle数据库内部SCN执行顺序以及已经提交的交易来合成交易文件,该交易文件号是依次递增并且是唯一的,从0开始,交易文件号的算法跟oracle的scn算法一样,可以保证在oracle数据库正常使用期间,保证。IDR能够正常使用。

    IDR只处理已经完成提交的交易,对于回滚操作,IDR不处理该操作。

    d、交易传输

    IDR只传输交易内容,不传输交易内容的数据结构,采用专有的合成交易文件格式,只有IDR提供的工具才可以解析交易内容,这样即证了在网络传输过程中数据的安全性又可以保证网络传输过程中数据的准确性。

    满足下列三种情况,源端将删除该交易文件:

    l  接受的交易文件号跟源端传输的一样。

    l  接受的交易文件大小跟源端传输的一样。

    l  接受的交易文件校验码跟源端传输的一样。

    e、交易装载

    目标端接受交易合成文件后,首先存放在缓存目录中,然后严格按照从小到大顺序进行装载,装载的交易文件不能缺失。否则装载的进程将一直处于等待状态,因此无论目标端是rac环境还是单机环境都可以保证装载的准确性。

    这样就可以保证在目标端装载过程中,保证按照源端合成的交易文件顺序来装载。

    (2)IDR支持的同步特性

    a、支持的同步对象

    IDR支持两种级别数据库对象的同步:用户级同步、表级同步。

    用户级同步:源端数据库指定用户及其所包含的表、视图、索引、过程、函数、包、序列等数据对象全部同步到目标端数据库指定的用户下。

    IDR支持源端用户名和目标端用户名不同的同步方式。

    表级同步:表级同步分为单表同步和多表同步。

    单表同步指定源端数据库指定用户下的单个表同步到目标端数据库指定用户下的单个表。

    多表同步,即group方式,针对多个用户,每个用户只同步指定的部分表同步的情况。

    b、支持的同步模式

    同步模式主要指源端和目标端的架构模式,具体分为

    1:1模式、1:n模式、n:1模式、1:1:1模式四种。

    1对1的同步模式:



    n对1同步模式:



    1对n同步模式:


    级联同步:


    可以根据具体情况选择或组合以上同步模式到您所需要的应用架构中。

    c、数据同步方式

    IDR支持历史数据同步、只同步变化数据同步两种方式。这两种方式和有效结合或单独使用。

    历史数据指同步时刻已经存在的数据,历史数据同步方式分为两种:

    l  快照方式

    快照方式利用oracle的select的多版本特性,将历史数据抓取到目标端,同时可选择将变化数据实时同步,在历史数据装载完成后,再装载变化数据。历史数据的抓取与变化数据的抓取之间无缝结合,有业务运行也不影响数据同步的准确性。

    相对而言,快照方式同步数据时间长,对于系统资源占有大。

    l  读文件方式

    读文件方式指IDR直接读取oracle数据文件中的表数据,同时可选择变化数据实时抓取。

    相对而言,快照方式同步数据时间端,对于系统资源占有小。但是这种方式抓取历史数据时,源端系统不能有业务,否则无法保证同步数据的准确性。

    变化数据同步有两种应用方式:

    l  与历史数据同步方式结合

    IDR支持历史数据与变化数据无缝结合的同步模式,这种方式无需停止业务。

    l  单独同步变化数据。

    这种方式是在两边数据已经一致的情况下,将某一边数据库现产生的交易同步到另外一边的数据库中。

    d、数据定位方式

    目标端装载交易时,对于目标端对应数据(表的记录)的定位方式分为rowid和where两种方式。

    rowid方式:使用rowid同步方式,由于在目标端装载时直接根据rowid方式定位表纪录的物理位置,不会因为数量量的差异而影响查找纪录的速度。

    使用rowid方式时,首先必须进行全同步+增量同步结合的模式,后续的增量数据依赖全同步数据。即使源端某些表的纪录完全相同,则也不会影响数据的准确性。

    Where方式:Where方式在目标端装载数据时,对于目标端对应的数据查找依赖对应表的where条件,对于对应数据的查找速度完全依赖于数据库本身的查找速度。

    主要满足两种应用需要:

    一种跟rowid方式相同,差别在于表的数据不能出现重复纪录。

    另外一种方式是只同步变化数据部分。只依赖源端和目标端相关表的数据结构。这种方式采用IDR的只进行增量同步的方式进行。

    (3)IDR同步的性能

    a、读取在线日志

    IDR是直接通过读取Oracle日志来分析出交易内容,而不是通过数据库表来得到,这样将不依赖数据库本身的数据内容而直接得到交易信息。从而大大加快了合成交易文件的速度。

    b、内存中完成交易解析

    源端在线日志的抓取的最新位置是通过查询数据库实例sga的动态视图得到的,这样不仅速度快而且不会直接影响源端数据库的物理I/O。

    源端归档日志的抓取是直接抓取归档日志内容。也不会影响到源端数据库的物理I/O。

    抓取后的数据,只分析同步用户或表相关的交易,对于跟同步用户或表无关的交易直接丢弃。

    日志的抓取、分析、合成大部分情况下都是在内存中完成的,只有少数批量交易数据时才会使用缓存目录,这样就可以尽可能的提高抓取、分析、合成交易的速度。

    c、只合成已经提交的交易

    IDR只合成跟同步用户或表有关的、已经提交的交易,并且每一个交易的大小不会超过10MB。这样将大大提高交易文件的合成速度。

    d、实时压缩传输

    网络传输时,首先在源端将交易合成文件在内存中进行压缩,在目标端接收后在内存中完成解压缩,即:进行传输之前先压缩、目标端接受压缩交易文件解压缩后,存放到相应的缓存目录下。这样可以大大减少网络流量,从而加快交易合成文件传输的速度。

    对于不含有lob类型的字段,交易合成文件何以压缩到10-15%左右。

    e、通过rowid寻址

    数据库修改一条记录通常依赖索引或全表扫描,这样操作速度会因为数据量的差别而有明显的差异。IDR是直接通过rowid对该记录进行操作的,不会因为数据量的明显差异使合成的交易文件中的交易提交速度有明显的差异。这一点对于海量数据尤为明显。

    f、合成交易文件大小

    IDR对每一个合成的交易文件最大上限为10MB,加上网络传输时的压缩功能,会使网络传输速度大大提高。

    由于每一个合成的交易文件最大为10MB,在目标端装载时的读取、装载速度会很快、占用资源会比较少,从而大大加快了每一个交易合成文件的装载速度。

    g、首次同步的性能

    对于首次同步而言,无论是快照方式还是读数据文件的方式,IDR在源端支持多达16个并行同步、目标端支持并行装载的模式,这样可以充分利用主机资源,加快首次同步的速度,减少首次同步对于源端、目标端主机性能的影响。

    h、增量同步的性能

    对于某些情况下,目标节点装载增量合成交易文件慢的情况,IDR支持多达32个并行装载,可以将不同用户或表的数据放在不同的增量目录下,实行并行装载,不过对于表之间有关联关系的数据(比如外健),就需要将这些有关联关系的表放在同一个增量目录下,来保证装载数据正确性。

     

     



    四、数据复制技术的比较

    下面我们对数据复制的三种技术做一个简单比较:

    复制技术

     

    比较项目

    存储系统数据复制

    操作系统层数据复制

    应用程序层数据复制

    基于存储的

    数据复制

    虚拟存储技术

    基本原理

    数据的复制过程通过本地的存储系统和远端的存储系统之间的通信完成。

    复制技术是伴随着存储局域网的出现引入的,通过构建虚拟存储上实现数据复制。

    通过操作系统或者数据卷管理器来实现对数据的远程复制。

    数据库的异地复制技术,通常采用日志复制功能,依靠本地和远程主机间的日志归档与传递来实现两端的数据一致。

    平台要求

    同构存储

    与平台无关,

    需要增加专有的复制服务器或带有复制功能的SAN交换机

    同构主机、异构存储

    与平台无关

    复制性能

    较高

    资源占用

    对生产系统存储性能有影响

    对网络要求高

    对生产系统主机性能有影响

    占用部分生产系统数据库资源

    技术成熟度

    成熟

    成熟度有待提高,非主流复制技术。

    成熟

    成熟

    投入成本

    高,需要同构存储

    较高,需要专有设备

    较高,需要同构主机

    一般

    部分软件免费,如DataGuard

    复制软件

    IBM PPRC

    EMC SRDF

    HP CA(Continues Access)

    HDS TrueCopy

    Brocade Tapestry DMM

    UIT SVM

    EMC VSM

     

    原厂技术:

    IBM AIX LVM

    HP-UINX MirrorDisk

    Sun Solaris SVM

    专业的复制软件:

    Symantec SF/VVR

    Oracle DataGuard

    Oracle GoldenGate

    DNT IDR

    DSG RealSync

    Quest SharePlex


    展开全文
  • 数据库容灾技术之--数据容灾技术比较 一、概述 近几年来,容灾已经成为信息数据中心建设的热门课题。很多容灾技术也快速发展起来,对用户来说也有很广阔的选择余地。但由于容灾方案的技术复杂性和多样性,一般...

    数据库容灾技术之--数据容灾技术比较

    转自:http://blog.csdn.net/quitepig/article/details/8351209

    一、概述

    近几年来,容灾已经成为信息数据中心建设的热门课题。很多容灾技术也快速发展起来,对用户来说也有很广阔的选择余地。但由于容灾方案的技术复杂性和多样性,一般用户很难搞清其中的优劣以确定如何选择最适合自己状况的容灾解决方案。本文我们就容灾建设中的备份及复制技术做一个初步探讨,希望能对客户的数据中心容灾建设提供一些参考。

    目前有很多种容灾技术,分类也比较复杂。但总体上可以区分为离线式容灾(冷容灾)和在线容灾(热容灾)两种类型。

    二、离线式容灾

    所谓的离线式容灾主要依靠备份技术来实现。其重要步骤是将数据通过备份系统备份到磁带上面,而后将磁带运送到异地保存管理。离线式容灾具有实时性低、可备份多个副本、备份范围广、长期保存、投资较少等特点,由于是备份一般是压缩后存放到磁带的方式所以数据恢复较慢,而且备份窗口内的数据都会丢失,因此一般用于数据恢复的RTO(目标恢复时间)和RPO(目标恢复点)要求较低的容灾。也有很多客户将离线式容灾和在线容灾结合起来增加系统容灾的完整性和安全性。

    目前主流的备份软件主要有:

    l  Symantec Veritas NetBackup

    l  EMC Legato NetWorker

    l  IBM Tivoli Storage Manager

    l  Quest BakBone NetVault

    三、在线容灾

    在线容灾要求生产中心和灾备中心同时工作,生产中心和灾备中心之间有传输链路连接。数据自生产中心实时复制传送到灾备中心。在此基础上,可以在应用层进行集群管理,当生产中心遭受灾难出现故障时可由灾备中心接管并继续提供服务。因此实现在线容灾的关键是数据的复制。

    和数据备份相比,数据复制技术具有实时性高、数据丢失少或零丢失、容灾恢复快、投资较高等特点。根据数据复制的层次,数据复制技术的实现可以分为三种:存储系统层数据复制、操作系统数据复制和数据库数据复制。

    1、存储系统层数据复制

    现在的存储设备经过多年的发展已经十分成熟。特别是中高端产品,一般都具有先进的数据管理功能。远程数据复制功能几乎是现有中高端产品的必备功能。要实现数据的复制需要在生产中心和灾备中心都部署1套这样的存储系统,数据复制功能由存储系统实现。如果距离比较近(几十公里之内)之间的链路可由两中心的存储交换机通过光纤直接连接,如果距离在100公里内也可通过增加DWDM等设备直接进行光纤连接,超过100公里的距离则可增加存储路由器进行协议转换途径WAN或INTERNET实现连接,因此从理论上可实现无限制连接。

    存储系统层的数据复制技术对于主机的操作系统是完全透明的,是对于将来增加新的操作平台,可不用增加任何复制软件的投资,即可完成实现复制。这样管理比较简单,最大程度保护了用户的投资,达到充分利用资源的目的。基于存储的复制一般都是采ATM或光纤通道做为远端的链路连接,不仅可以做到异步复制,更可以做到同步复制,使两端数据可做到实时同步的目的,保证了数据的一致性。缺点是由于基于存储是由存储硬件厂商提供的,在兼容性方面有局限性。用户要使用同一厂商的devices,给用户造成的选择面太小,成本容易提高,并且对线路带宽的要求通常也较高。对于预算充足,存储环境不是很复杂的企业来说,选择基于存储的技术比较适合。

    存储系统层的数据复制基于同构的存储,各个存储厂商都有自己的复制软件,如IBM PPRC、EMC SRDF、HP Continues Access、HDS TrueCopy等,以下举例说明存储系统层的数据复制原理。

    远程镜像(CA)介绍

    HP Continuous Access XP 通过向远地镜像复制数据来满足系统的高可用性和灾难恢复的需求。它通过同步模式,将数据从一台XP磁盘阵列上拷贝到远端的另一台XP磁盘阵列上,从而实现容灾解决方案。

    Continuous Access XP Extension 使Continuous Access XP能够以高性能的异步或同步方式进行远程XP磁盘阵列的拷贝。根据标书中的要求,必须同时提供同步和异步的存储复制方式,CA完全满足。

    CA是基于磁盘阵列的容灾方式。其中, CA能够实现同步/异步、同城集群/洲际集群,以及Solaris、AIX、Windows各种OS集群扩展,还可以实现新XP到新XP、老XP到新XP以及多中心容灾等功能,全面实现了可用性与可扩展性的结合。

    CA同步加上CA异步,在本地和远程XP磁盘阵列之间实现高性能实时远程数据镜像,以及快速切换及回切,使用户能轻松管理,并实现高可用性。CA同步方式的距离可以达到100公里,但是从性能的角度出发,一般都控制在50公里内。可以建设同城容灾集群,消除计划宕机时间,降低非计划的宕机时间;异步方式的距离可以达到数千公里,可以集成远程数据镜像和异构服务器的集群,增强总体方式的可用性,在同城灾难发生的时候,保证连续运作。其中,洲际集群没有距离的限制,对应用和数据完全透明,可实现全球范围的容灾方案。

    同时,针对关键用户的特殊需求,CA可以实现多中心容灾解决方案,其中,同步容灾中心的距离可以达到50公里,异步中心可以在全球的任何一个地方,至少有三个中心有镜像的数据,而且三个中心之间可以实现远程容灾。


    (1)CAXP磁盘卷组

    CAXP的磁盘卷组由不同的XP装置内或不同CLUSTER内命名为P-VOL和S-VOL的2个逻辑磁盘卷构成。在具有CAXP磁盘卷组关系后:

    P-VOL被称为主磁盘卷。P-VOL可被读/写。

    S-VOL(远程磁盘卷)被称为副磁盘卷。在XP内部的控制装置的作用下,P-VOL的内容和服务器来的写数据被拷贝到S-VOL(可采用同步或异步两种方式)。CAXP卷组建立后,S-VOL为只读磁盘卷。在一个XP里,既可有P-VOL,也可有S-VOL,这样可以实现双向数据境像。

    CAXP的磁盘卷组,即P-VOL和S-VOL间,可以是相同的RAID类型,也可以是不同的RAID类型,具体的RAID级别配合表如下所示:

     

    For P-VOL

    For S-VOL

    RAID 1

    RAID 1

    RAID 5

    RAID 5

    RAID 1

    RAID 5

    RAID 5

    RAID 1

    CAXP的RAID级别

    (2)MCU和RCU

    MCU(主磁盘控制器)和RCU(远程磁盘控制器)分别和P-VOL,S-VOL相连,MCU控制由服务器来的写向P-VOL的数据的写操作,还控制P-VOL和S-VOL之间数据拷贝的操作,并且提供CAXP磁盘卷组的状态和构成的管理。

    RCU执行由MCU发出的写命令操作。写操作的执行方法和执行服务器来的写操作过程相同。除此之外,RCU还具有管理一部分CAXP磁盘卷组的状态和构成信息的能力。

    对于任何一个磁盘卷组,都需要定义MCU/RCU。一个XP的磁盘控制装置在控制P-VOL时,可作为MCU使用,当控制S-VOL的时侯,可作为RCU使用。

    (3)CA的同步和异步复制

    基于存储的数据复制,主要有同步数据复制和异步数据复制两种。

    同步数据复制,指通过将本地生产数据以完全同步的方式复制到异地,每一本地IO交易均需等待远程复制的完成方予以释放。

    同步方式的数据复制

    同步复制方式的传输距离限制:

    l  FC光纤通道最大传输距离为10KM;

    l  ESCON通过中继方式最大可传输43KM;

    l  DWDM方式最大传输距离为100KM

    异步数据复制则是指将本地生产数据以后台同步的方式复制到异地,每一本地IO交易均正常释放,无需等待远程复制的完成。

    异步方式的数据复制

    同步复制实时性强,灾难发生时远端数据与本地数据完全同步。但这种方式因为数据在网络中的传输延迟而影响主节点的应用性能。

    异步复制则不然,但可能导致灾备点数据比主点数据有一定延迟,这些延迟的数据在灾难发生后将丢失。由此可见,同步方式和异步方式实际上是各有千秋,需要依据具体的应用,在应用性能和潜在的可能丢失数据量之间作一个取舍和均衡。

    (4)CAXP卷组的更新拷贝模式

    在组建灾难备份系统时,往往是假定正在使用的主中心的存储数据受到毁坏。这时启动远程备份中心的备份存储系统,来接替主中心的工作或从备份存储设备中把数据恢复到主中心端,在主中心重新启动应用。不论使用哪种方法,远程备份中心的备份数据与主中心端数据的一致性将会决定灾难恢复的时间。在灾难发生后,为了尽可能减少花在数据一致性分析上的时间,以XP1024存储为例,XP1024提供用于灾难备份的CAXP磁盘卷组的拷贝模式的设定选择来加快事后分析数据的一致性。

    远程数据拷贝操作

    更新拷贝模式(Fence Level)共有3种:Data、Status、Never。CAXP卷组的状态在变为“Suspend”后,更新拷贝模式将会对P-VOL的写操作产生影响,在建立灾难备份系统方案时,应预先考虑好CAXP卷组的一致性要求,对应的拷贝模式可由下表选出:

    Type of Failure

     

    S-VOL Data

    S-VOL Status

    Never

    The update copy operation failed,and the MCU was not able to change the status of the S-VOL to suspended

    Write I/O operations to the P-VOL will be:

     

    REJECT

    Accepted

    Accepted

    The update copy operation failed,and the MCU was not able to change the status of the S-VOL to suspended

    Write I/O operations to the P-VOL will be:

     

    REJECTED

    REJECTED

    Accepted

    l  更新拷贝模式:Data——在这个模式下,P-VOL和S-VOL的一致性会完全被保证。当两个卷组之间不能保证同步时,即当卷组状态变为Suspend时,MCU将会拒绝对服务器对P-VOL的写操作以保证两个磁盘卷的一致性。这种模式在灾害发生时将会最大限度的减少数据一致性分析所花的时间。(注:初期拷贝完成之前,如果灾害发生,将导致P-VOL和S-VOL的数据不一致,因此不能把S-VOL用于灾害恢复)。在Data这种拷贝模式下,一旦FC线路或S-VOL出现故障,都将使P-VOL的写操作停止,并向系统发出写错误信息中断系统的应用。

    l  更新拷贝模式:Status——当MCU检测出CAXP卷组之间失去同步后,且无法将S-VOL的状态改变为Suspend时,MCU会拒绝服务器向P-VOL的写操作,并对服务器发出写错误的信息。当FC链路失效时这种模式会起作用,如果客户认为S-VOL的偶尔失去同步是可容忍的,这种模式可被使用。当S-VOL由于某种原因失效时,并且卷组状态成功地变为Suspend时,P-VOL的读写操作可继续进行,这时P-VOL里更新过的磁道会被记录下来,当S-VOL被恢复后,更新数据不会自动的被拷贝到S-VOL,而需要重新同步这个卷组,数据的更新拷贝才会被执行。

    l  更新拷贝模式:Never——在CAXP卷组失去同步后,无论S-VOL的状态能否被改为Suspend,服务器对P-VOL的写操作不会被中止。在这种模式下,只要P-VOL自己不出现故障,服务器传来的写操作就会被执行。当FC Link或S-VOL由于某种原因失效后,P-VOL的更新磁道将会被MCU记录下来。故障排除后,用卷组激活命令可重新同步P-VOL和S-VOL,这时,只拷贝P-VOL里的更新磁道。

    Data及Status模式对保持数据一致性非常有好处的,但在线路或远端XP1024故障时会对主服务器造成造成一定的影响,甚至导致应用系统挂起。

    在这种拷贝模式下建立起来的CAXP镜像卷组,即使在光纤或S-VOL故障引起P-VOL和S-VOL镜象卷组失去同步后,只要P-VOL没有遭到损坏,MCU就不会据绝服务器对P-VOL发出的写操作。

    从服务器端来看,P-VOL对S-VOL镜象卷的数据更新象在正常进行,服务器的应用也不会被中断。当出现光纤、DWDM、远地备份中心XP1024停电等故障时,因为不影响应用的运行,所以没有必要象“DATA”那样强制中断CAXP卷组的工作。同时必须在网管上采用必要手段,监控XP1024 Pair的状态。一旦Pair状态变成非duplex,必须尽快采取措施进行修复,否则一旦发生灾难,由于远地的XP1024 CA拷贝与主site的数据不同步,灾难系统切换将会失败,导致不必要的停机。

     

    虚拟存储技术的介绍

    近年来,随着存储技术的不断发展,在存储系统层次数据复制技术上还出现基于网络的存储虚拟化设备来实现,这种方式的特点是依靠外加的网络层设备来实现两个存储设备之间的数据复制,数据复制过程不占用主机资源,两个存储之间的数据同步在网络层完成。

    根据存储虚拟化设备工作机制的不同,一般可分为带内(In-Band)和带外(Out-of-Band)两种。

    存储虚拟化设备通过交换机分别连接主机端Fabric 和存储端 Fabric,主要功能是管理对存储设备上的逻辑卷,对已有逻辑卷进行虚拟化或创建虚拟的条带卷,消除存储设备异构对主机系统的影响,提高存储设备的可用性和总体性能。另外一个功能就是卷复制和镜像,通过存储虚拟化设备实现两个虚拟卷之间的数据安全保护。

    通过存储虚拟化设备实现卷镜像复制功能的优势在于操作由存储虚拟化设备来完成、压力集中的存储虚拟化设备上,不需要主机参与,数据复制进程安全稳定。缺点是需要增加专用存储虚拟化设备,带外方式有的需要在主机端需要安装存储虚拟化设备的客户端软件,比如 UIT SVM;有的需要依赖高端智能交换机,比如 EMC VSM。目前使用这种技术的产品还不是很多,成熟性还有待提高,具有这种功能的专用设备价格也相对较高,所以采用这种方案的用户比较少。

     

    2、操作系统数据复制

    主要通过操作系统或者数据卷管理器来实现对数据的远程复制。这种复制技术要求本地系统和远端系统的主机是同构的,其实现方式是基于主机的数据复制,容灾方式工作在主机的卷管理器这一层,通过磁盘卷的镜像或复制,实现数据的容灾。这种方式也不需要在两边采用同样的存储设备,具有较大的灵活性,缺点是复制功能会多少占用一些主机的CPU资源,对主机的性能有一定的影响

    目前基于原厂的逻辑卷管理软件如IBM AIX LVM、HP-UINX MirrorDisk、Sun Solaris SVM等可以实现在本厂平台上的逻辑卷镜像,专业的数据复制软件提供了更大的灵活性,支持多个平台的逻辑卷镜像,其中代表性的软件是Symantec VERITAS Storage Foundation 软件。

    Symantec VERITASStorage Foundation简介

    (1)Symantec远程镜像数据容灾原理

    Symantec的VERITAS Storage Foundation的镜像技术构建容灾系统是比较简单的,它只有一个条件,就是将生产中心和灾备中心之间的SAN存储区域网络通过光纤连接起来,建立城域SAN存储网络。然后就可以通过Storage Foundation提供的非常成熟的跨阵列磁盘镜像技术来实现同城容灾了,容灾方案的结构如下图所示:


    从镜像原理上讲,在城域SAN存储网络上的两套磁盘系统之间的镜像,和在一个机房内的SAN上的两个磁盘系统之间的镜像并没有任何区别。

    利用裸光纤将生产中心和灾备中心的SAN网络连接起来,构成城域SAN网络以后,利用 VERITAS Storage Foundation的逻辑卷管理功能,就可以实现生产中心磁盘系统和灾备中心磁盘系统之间的镜像了。如下图所示:

    在逻辑卷镜像过程中,利用VERITAS Storage Foundation,可以创建任意一个逻辑卷(Volume)供业务主机使用,实际上是由两个完全对等的,容量相同的磁盘片构成的,两个磁盘片上的数据完全一样,业务主机对该Volume的任意修改,都将同时被写到位于生产中心和灾备中心的两个磁盘系统上。

    采用这种方式,生产中心的磁盘阵列与同城容灾中心的磁盘阵列对于两地的主机而言是完全同等的。利用城域SAN存储网络和VERITAS Storage Foundation镜像功能,可以实现数据系统的异地容灾。并且消除了复制技术(无论是同步还是异步)的切换的动作,从而保证零停机时间,零数据损失的实现。

    (2)Symantec远程镜像数据容灾的技术特点

    l  零停机时间和零数据损失

    由于Storage Foundation 采用的是跨异构阵列的镜像技术,而镜像技实现原理,就决定了在这种方式下,无论是哪一边的磁盘阵列由于物理故障停顿,都不会影响数据的可用性而造成数据的损失,这从根本上实现了在物理故障的情况下,数据的高度可用性。

    l  故障修复后的快速重新同步

    Storage Foundation 提供的镜像技术,是基于日志的镜像技术,无论由于主机发生故障,还是由于镜像中的链路或是硬盘发生故障导致的镜像被破坏的情况,都可以通过镜像日至得以快速恢复。这使得镜像恢复过程对系统的性能影响微乎其微。

    l  跨磁盘阵列快照,实现逻辑错误快速恢复和容灾中心数据利用

    Storage Foundation 提供基于卷,以及文件系统的多种快照技术,其逻辑辑快照可采用少量磁盘空间,快速,多次的对文件系统,或者是卷作快照。因而,当用户出现数据的逻辑错误时,利用快照就可以迅速恢复文件系统或卷。这在数据保护的体系,大大的弥补了传统备份恢复保护方式速度慢的缺陷,从而把数据损失量降到最低限度。

    同时,数据快照还被广泛的利用在容灾中心数据利用方面,比如可以通过快照实现数据备份、查询、测试等。

    l  数据同步过程高度可控

    Storage Foundation Remoter Mirror 提供完整的容灾命令集,在数据同步的过程中,可以随时得知同步的进度,并可随时暂停、继续数据同步。

     

    4、数据库数据复制

    数据库数据复制技术通常采用日志复制功能,依靠本地和远程主机间的日志归档与传递来实现两端的数据一致。这种复制技术对系统的依赖性小,有很好的兼容性。缺点是本地复制软件向远端复制的是日志文件,这需要远端应用程序重新执行和应用才能生产可用的备份数据。

    目前基于数据库的复制技术主要有:Oracle DataGuard、Oracle GoldenGate、DSG RealSync、Quest SharePlex 、IStream DDS等,以下举例说明该复制技术的运行原理。

    DataGuard软件介绍

    OracleData Guard 是管理、监控和自动化软件的基础架构,它创建、维护和监控一个或多个备用数据库,以保护企业数据结构不受故障、灾难、错误和崩溃的影响。

    DataGuard 使备用数据库保持为与生产数据库在事务上一致的副本。这些备用数据库可能位于距生产数据中心数千英里的远程灾难恢复站点,或者可能位于同一城市、同一校园乃至同一建筑物内。当生产数据库由于计划中断或意外中断而变得不可用时,Data Guard 可以将任意备用数据库切换到生产角色,从而使与中断相关的停机时间减到最少,并防止任何数据丢失。

    作为 Oracle 数据库企业版的一个特性推出的 Data Guard 能够与其他的 Oracle 高可用性 (HA) 解决方案(如真正应用集群 (RAC) 和恢复管理器 (RMAN))结合使用,以提供业内前所未有的高水平数据保护和数据可用性。

    (1)DataGuard重做应用和SQL应用

    备用数据库最初是从主数据库的一个备份副本创建的。一旦创建了备用数据库,Data Guard 自动将主数据库重做数据传输给备用系统,然后将重做数据应用到备用数据库中,从而使备用数据库保持为与主数据库在事务上一致的副本。

    DataGuard 提供了两种方法将这些重做数据应用到备用数据库中,并使之与主数据库在事务上保持一致。这些方法与 Data Guard 支持的两种类型的备用数据库对应:

    ●  重做应用,用于物理备用数据库

    ●  SQL应用,用于逻辑备用数据库

    (2)物理备用数据库—重做应用

    通过使用 Oracle 介质恢复应用从主数据库接收到的重做数据,物理备用数据库与主数据库保持同步。它在物理上与主数据库逐块相同,因而数据库模式(包括索引)是相同的。

    主数据库上的一个日志切换将触发备用数据库上的一个日志切换,从而使备用数据库上的归档器进程将当前的备用重做日志文件归档到备用数据库上的一个存档日志中。随后,Data Guard 重做应用使用一个专用进程(称为管理的恢复进程 (MRP))读取存档日志,并将重做数据应用到物理备用数据库中。如果启用了 Oracle Database 10g中的 Oracle Data Guard 的新功能—实时应用,则 MRP 将在 RFS 进程写满当前的备用重做日志文件时直接从其中读取重做数据。

    通过加载物理备用数据库并使用以下命令,可以在该数据库上启动 MRP(从而应用重做数据): ALTER DATABASE RECOVERMANAGED STANDBY DATABASE DISCONNECT FROM SESSION;介质恢复进程可以并行运行,以获得 Data Guard 重做应用的最佳性能。在 Oracle Database 10g 之前的版本中,这需要在上述RECOVER MANAGED STANDBY DATABASE 命令中使用 PARALLEL 子句。在 Oracle Database 10g中,MRP 可以在启动(无需 PARALLEL 子句)时自动确定并行恢复进程的最佳数量,这个数字视备用服务器上可用的 CPU 数量而定。

    物理备用数据库可以以只读方式打开,并且可以在其打开时对其运行查询,但无法在其以只读方式打开的同时运行恢复。在备用数据库以只读方式打开时,传送给它的重做数据将在备用站点上累积而不应用。不过,可以随时在物理备用数据库上恢复操作,并自动应用累积的重做数据。这允许物理备用数据库以一个序列运行,这个序列可能包括在恢复中运行一段时间,然后以只读方式打开来运行报表,接着重新运行恢复来应用尚未应用的重做数据。

    要以只读方式打开物理备用数据库,则需使用以下命令在备用数据库上取消恢复:ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;然后可以只读方式打开数据库:ALTER DATABASE OPEN。

    (3)逻辑备用数据库--SQL 应用

    尽管数据的物理组织和结构可能不同,但逻辑备用数据库包含与主数据库相同的逻辑信息。SQL 应用技术将从主数据库接收到的重做数据转换成 SQL 语句,然后在备用数据库上执行 SQL 语句,以使逻辑备用数据库与主数据库保持同步。从而,在将 SQL 应用到逻辑备用数据库上的同时,可以访问逻辑备用数据库来进行查询和报表操作。

     由于使用 SQL 语句更新逻辑备用数据库,因此它保持以读写模式打开,而从主数据库中更新的表可以同时用于诸如报表、合计、查询等其他任务如。.还可通过在维护的表上创建额外的索引和物化视图来优化这些任务。逻辑备用数据库可以承载多个数据库模式,用户可以对这些模式中不从主数据库进行更新的表上执行普通的数据处理操作。

    SQL应用使用许多并行的执行服务器和后台进程,它们将来自主数据库的更改应用到逻辑备用数据库中。下图显示了信息流和每一个进程所起的作用。

    这些不同的 SQL 应用进程可以通过在逻辑备用数据库上输入这条简单的命令来启动: ALTERDATABASE START LOGICAL STANDBY APPLY;出于每个 SQL 应用进程的考虑,读取器进程从存档日志(如果启用了实时应用,也可以是备用重做日志,)中读取重做记录。准备器进程将块更改转换成表更改或逻辑更改记录 (LCR)。在这里,LCR 并不代表任何特定的事务。构造器进程对来自各个 LCR 的已完成事务进行组合。分析器进程检查完成的事务,辨明不同事务之间的相关性。协调器进程(也称为逻辑备用进程,即 LSP)负责将事务分配给应用进程、监控事务之间的相关性以及批准将更改提交给逻辑备用数据库。应用器进程将已指定事务的 LCR 应用到数据库中,并在协调器指示提交事务时提交。Data Guard 提供视图来帮助查看每个进程的状态。

    (4)DataGuard数据保护模式

    l  最大保护模式

           最大保护模式为主数据库提供了最高水平的数据保护,从而确保了一个全面的零数据丢失灾难恢复解决方案。当在最大保护模式下运行时,重做记录由日志写入器(LGWR)进 程从主数据库同步地传输到备用数据库,并且直到确认事务数据在至少一个备用服务器上的磁盘上可用时,才在主数据库上提交事务。强烈建议,这种模式应至少配 置两个备用数据库。当最后参与的备用数据库不可用时,主数据库上的处理将停止。这就确保了当主数据库与其所有备用数据库失去联系时,不会丢失事务。

           由于重做传输的同步特性,这种最大保护模式可能潜在地影响主数据库响应时间。可以通过配置一个低延迟网络,并为它分配足够应付高峰事务负载的带宽来将这种影响减到最小。需要这种最大保护模式的企业有股票交易所、货币交易所、金融机构等。

    l   最高可用性模式

           最高可用性模式拥有仅次于最高水平的主数据库数据可用性。如同最大保护模式一样,重做数据由LGWR从主数据库同步地传输到备用数据库,直到确认事务数据在备用服务器的磁盘上可用时,事务才在主数据库上完成。不过,在这种模式下(与最大保护模式不同),如果最后参与的备用数据库变为不可用—例如由于网络连接问题,处理将在主数据库上继续进行。备用数据库与主数据库相比,可能暂时落在后面,但当它再次变为可用时,备用数据库将使用主数据库上累积的归档日志自动同步,而不会丢失数据。

           由于同步重做传输,这种保护模式可潜在地影响响应时间和吞吐量。可以通过配置一个低延迟网络,并为它分配足够应付高峰事务负载的带宽来将这种影响减到最小。

           最高可用性模式适用于想要确保获得零数据丢失保护,但不想让生产数据库受网络/备用服务器故障影响的企业。如果又一个故障随后影响了生产数据库,然后最初的网络/备用服务器故障得到解决,那么这些企业将接受数据丢失的可能性。

    l   最高性能模式

     最高性能模式是默认的保护模式。它与最高可用性模式相比,提供了稍微少一些的主数据库数据保护,但提供了更高的性能。在这种模式下,当主数据库处理事务时,重做数据由LGWR进程异步传输到备用数据库上。另外,也可以将主数据库上的归档器进程(ARCH)配置为在这种模式下传输重做数据。在任何情况下,均先完成主数据库上的写操作,主数据库的提交操作不等待备用数据库确认接收。如果任意备用目标数据库变为不可用,则处理将在主数据库上继续进行,这对性能只有很小的影响或没有影响。

    在主数据库出现故障的情况下,尚未被发送到备用数据库的重做数据会丢失。但是,如果网络有足够的吞吐量来跟上重做流量高峰,并且使用了LGWR进程来将重做流量传输到备用服务器,则丢失的事务将非常少或者为零。

    当主数据库上的可用性和性能比丢失少量数据的风险更重要时,应该使用最高性能模式。这种模式还适合于WAN上的DataGuard部署,在WAN中,网络的内在延迟可能限制同步重做传输的适用性。

     

    基于数据库日志跟踪分析的复制软件介绍

    目前市场数据库复制技术的工作原理大都与Oracle log相关,例如DNT IDR数据库复制产品就是通过对Oracle Log日志进行分析获取跟踪源系统的交易指令,然后将交易指令传到目标端进行重新执行的方式来实现数据复制的。本文以DNT IDR软件为例介绍基于数据库日志跟踪分析的复制原理。

    DNT IDR(以下简称IDR),是基于交易的逻辑级Oracle数据同步软件,利用数据库日志在线跟踪、分析技术,将生产数据库的交易信息以事务为单位,通过异步的方式,实时的传递、装载到目标数据库中,以达到源端、目标端数据保持同步的目的。是一种准实时同步软件。该软件具有以下特点:

    l  IDR不依赖硬件的同步能力,支持多种系统平台,具有部署简单、同步速度快、交易延迟时间短的特点。

    l  IDR能够支持不同Oracle版本之间的交易同步。

    l  IDR同步的目标数据库为在线打开状态,可以随时复用。

    l  IDR适用于(异构)热容灾、数据迁移、数据集中、数据分发、分担业务等应用领域。

    IDR利用数据库日志在线跟踪、分析技术,反向工程解析日志,将生产数据库的交易信息以事务为单位,通过异步的方式,实时的传递、装载到目标数据库中,以达到源端、目标端数据保持同步的目的。

    IDR技术原理与架构

    (1)IDR的同步原理

    a、历史数据同步

    使用快照方式:首次同步时,对于同步map所涉及的每一个表的同步过程如下:

    l  锁该表;

    l 记录同步时刻的scn;

    l 读取该表数据;

    l 在读取该表数据时接着将该表解锁,无需等待该表数据读取完毕。

    在表做开始同步的时刻,锁表是为了保证该表在日志中不会有交易发生,同时又因为记录了scn,也不会有多余的交易被抓取、也不会漏掉相关交易。

    开始读取数据时,利用了oracle数据库自身提供的“多版本”特性,能够保证读取数据的一致性。同时对该表进行解锁,又使该表被锁的时间不会太长从而严重影响正常交易。

    这种方式保证了源端在任何时刻下都可以进行首次数据的批量同步而不会影响同步数据的准确性。

    读文件方式:首次同步时,对于同步map所涉及的每一个表的同步过程如下:

    l 记录同步时刻的scn;

    l 读取该表数据;

    首次同步时,直接从oracle数据文件中读取该表数据,同时记录同步时刻的scn,由于这种方式要求在同步过程中,没有交易产生,因此会保证历史数据抓取的准确性。在同步完成后,将变化数据实时抓取。

    b、交易抓取

    IDR通过事先创建的试图来捕获日志变化,由于每次捕获的日志的物理位置都会记录,因此可以得出日志变化量。

    后续的抓取日志、分析交易、传输交易,完全由IDR独自完成,不使用oracle数据库任何资源。

    在每次抓取的日志量处理完成后,记录在IDR的缓存目录中,因此对于日常运行过程中,IDR停止或其它原因需要读取归档日志时,根据记录的日志物理位置来定位需要抓取的归档日志。

    IDR抓取日志跟oracle数据库是写日志是并行操作而又互不影响。

    正常情况下,IDR都是准实时的抓取变化日志量。

    对于源端是rac环境来说:rac环境中,在每一个实例所在的主机操作系统上可以读取另外主机的在线日志(包括归档日志)。通过每一个实例的日志和scn来保证交易顺序的准确性。

    c、交易分析

    严格按照源端Oracle数据库内部SCN执行顺序以及已经提交的交易来合成交易文件,该交易文件号是依次递增并且是唯一的,从0开始,交易文件号的算法跟oracle的scn算法一样,可以保证在oracle数据库正常使用期间,保证。IDR能够正常使用。

    IDR只处理已经完成提交的交易,对于回滚操作,IDR不处理该操作。

    d、交易传输

    IDR只传输交易内容,不传输交易内容的数据结构,采用专有的合成交易文件格式,只有IDR提供的工具才可以解析交易内容,这样即证了在网络传输过程中数据的安全性又可以保证网络传输过程中数据的准确性。

    满足下列三种情况,源端将删除该交易文件:

    l  接受的交易文件号跟源端传输的一样。

    l  接受的交易文件大小跟源端传输的一样。

    l  接受的交易文件校验码跟源端传输的一样。

    e、交易装载

    目标端接受交易合成文件后,首先存放在缓存目录中,然后严格按照从小到大顺序进行装载,装载的交易文件不能缺失。否则装载的进程将一直处于等待状态,因此无论目标端是rac环境还是单机环境都可以保证装载的准确性。

    这样就可以保证在目标端装载过程中,保证按照源端合成的交易文件顺序来装载。

    (2)IDR支持的同步特性

    a、支持的同步对象

    IDR支持两种级别数据库对象的同步:用户级同步、表级同步。

    用户级同步:源端数据库指定用户及其所包含的表、视图、索引、过程、函数、包、序列等数据对象全部同步到目标端数据库指定的用户下。

    IDR支持源端用户名和目标端用户名不同的同步方式。

    表级同步:表级同步分为单表同步和多表同步。

    单表同步指定源端数据库指定用户下的单个表同步到目标端数据库指定用户下的单个表。

    多表同步,即group方式,针对多个用户,每个用户只同步指定的部分表同步的情况。

    b、支持的同步模式

    同步模式主要指源端和目标端的架构模式,具体分为

    1:1模式、1:n模式、n:1模式、1:1:1模式四种。

    1对1的同步模式:



    n对1同步模式:



    1对n同步模式:


    级联同步:


    可以根据具体情况选择或组合以上同步模式到您所需要的应用架构中。

    c、数据同步方式

    IDR支持历史数据同步、只同步变化数据同步两种方式。这两种方式和有效结合或单独使用。

    历史数据指同步时刻已经存在的数据,历史数据同步方式分为两种:

    l  快照方式

    快照方式利用oracle的select的多版本特性,将历史数据抓取到目标端,同时可选择将变化数据实时同步,在历史数据装载完成后,再装载变化数据。历史数据的抓取与变化数据的抓取之间无缝结合,有业务运行也不影响数据同步的准确性。

    相对而言,快照方式同步数据时间长,对于系统资源占有大。

    l  读文件方式

    读文件方式指IDR直接读取oracle数据文件中的表数据,同时可选择变化数据实时抓取。

    相对而言,快照方式同步数据时间端,对于系统资源占有小。但是这种方式抓取历史数据时,源端系统不能有业务,否则无法保证同步数据的准确性。

    变化数据同步有两种应用方式:

    l  与历史数据同步方式结合

    IDR支持历史数据与变化数据无缝结合的同步模式,这种方式无需停止业务。

    l  单独同步变化数据。

    这种方式是在两边数据已经一致的情况下,将某一边数据库现产生的交易同步到另外一边的数据库中。

    d、数据定位方式

    目标端装载交易时,对于目标端对应数据(表的记录)的定位方式分为rowid和where两种方式。

    rowid方式:使用rowid同步方式,由于在目标端装载时直接根据rowid方式定位表纪录的物理位置,不会因为数量量的差异而影响查找纪录的速度。

    使用rowid方式时,首先必须进行全同步+增量同步结合的模式,后续的增量数据依赖全同步数据。即使源端某些表的纪录完全相同,则也不会影响数据的准确性。

    Where方式:Where方式在目标端装载数据时,对于目标端对应的数据查找依赖对应表的where条件,对于对应数据的查找速度完全依赖于数据库本身的查找速度。

    主要满足两种应用需要:

    一种跟rowid方式相同,差别在于表的数据不能出现重复纪录。

    另外一种方式是只同步变化数据部分。只依赖源端和目标端相关表的数据结构。这种方式采用IDR的只进行增量同步的方式进行。

    (3)IDR同步的性能

    a、读取在线日志

    IDR是直接通过读取Oracle日志来分析出交易内容,而不是通过数据库表来得到,这样将不依赖数据库本身的数据内容而直接得到交易信息。从而大大加快了合成交易文件的速度。

    b、内存中完成交易解析

    源端在线日志的抓取的最新位置是通过查询数据库实例sga的动态视图得到的,这样不仅速度快而且不会直接影响源端数据库的物理I/O。

    源端归档日志的抓取是直接抓取归档日志内容。也不会影响到源端数据库的物理I/O。

    抓取后的数据,只分析同步用户或表相关的交易,对于跟同步用户或表无关的交易直接丢弃。

    日志的抓取、分析、合成大部分情况下都是在内存中完成的,只有少数批量交易数据时才会使用缓存目录,这样就可以尽可能的提高抓取、分析、合成交易的速度。

    c、只合成已经提交的交易

    IDR只合成跟同步用户或表有关的、已经提交的交易,并且每一个交易的大小不会超过10MB。这样将大大提高交易文件的合成速度。

    d、实时压缩传输

    网络传输时,首先在源端将交易合成文件在内存中进行压缩,在目标端接收后在内存中完成解压缩,即:进行传输之前先压缩、目标端接受压缩交易文件解压缩后,存放到相应的缓存目录下。这样可以大大减少网络流量,从而加快交易合成文件传输的速度。

    对于不含有lob类型的字段,交易合成文件何以压缩到10-15%左右。

    e、通过rowid寻址

    数据库修改一条记录通常依赖索引或全表扫描,这样操作速度会因为数据量的差别而有明显的差异。IDR是直接通过rowid对该记录进行操作的,不会因为数据量的明显差异使合成的交易文件中的交易提交速度有明显的差异。这一点对于海量数据尤为明显。

    f、合成交易文件大小

    IDR对每一个合成的交易文件最大上限为10MB,加上网络传输时的压缩功能,会使网络传输速度大大提高。

    由于每一个合成的交易文件最大为10MB,在目标端装载时的读取、装载速度会很快、占用资源会比较少,从而大大加快了每一个交易合成文件的装载速度。

    g、首次同步的性能

    对于首次同步而言,无论是快照方式还是读数据文件的方式,IDR在源端支持多达16个并行同步、目标端支持并行装载的模式,这样可以充分利用主机资源,加快首次同步的速度,减少首次同步对于源端、目标端主机性能的影响。

    h、增量同步的性能

    对于某些情况下,目标节点装载增量合成交易文件慢的情况,IDR支持多达32个并行装载,可以将不同用户或表的数据放在不同的增量目录下,实行并行装载,不过对于表之间有关联关系的数据(比如外健),就需要将这些有关联关系的表放在同一个增量目录下,来保证装载数据正确性。

     

     


    四、数据复制技术的比较

    下面我们对数据复制的三种技术做一个简单比较:

    复制技术

     

    比较项目

    存储系统数据复制

    操作系统层数据复制

    应用程序层数据复制

    基于存储的

    数据复制

    虚拟存储技术

    基本原理

    数据的复制过程通过本地的存储系统和远端的存储系统之间的通信完成。

    复制技术是伴随着存储局域网的出现引入的,通过构建虚拟存储上实现数据复制。

    通过操作系统或者数据卷管理器来实现对数据的远程复制。

    数据库的异地复制技术,通常采用日志复制功能,依靠本地和远程主机间的日志归档与传递来实现两端的数据一致。

    平台要求

    同构存储

    与平台无关,

    需要增加专有的复制服务器或带有复制功能的SAN交换机

    同构主机、异构存储

    与平台无关

    复制性能

    较高

    资源占用

    对生产系统存储性能有影响

    对网络要求高

    对生产系统主机性能有影响

    占用部分生产系统数据库资源

    技术成熟度

    成熟

    成熟度有待提高,非主流复制技术。

    成熟

    成熟

    投入成本

    高,需要同构存储

    较高,需要专有设备

    较高,需要同构主机

    一般

    部分软件免费,如DataGuard

    复制软件

    IBM PPRC

    EMC SRDF

    HP CA(Continues Access)

    HDS TrueCopy

    Brocade Tapestry DMM

    UIT SVM

    EMC VSM

     

    原厂技术:

    IBM AIX LVM

    HP-UINX MirrorDisk

    Sun Solaris SVM

    专业的复制软件:

    Symantec SF/VVR

    Oracle DataGuard

    Oracle GoldenGate

    DNT IDR

    DSG RealSync

    Quest SharePlex


    展开全文
  • 存储容灾技术

    2015-06-25 11:17:18
    HDS HUS110存储设备,存储容灾技术交流
  • Oracle容灾技术交流

    2018-04-05 23:27:07
    Oracle容灾技术交流,包括容灾及data guard技术概述,data guard 11g r2新特性,xxxx银行关注问题解答,容灾系统实施方法论及案例
  • 容灾技术概念

    2012-12-26 11:13:18
    容灾技术概念,详细介绍容灾的概念设计及各项指标
  • IDC异地容灾技术方案
  • 教程名称:Symantec容灾技术方案合集课程目录:【】Symantec_-网络准入控制的顺利实施【】Symantec_NetBackup_磁盘备份解决方案【】Symantec_VMware完整保护解决方案v1.1【】Symantec_容灾技术【】Symantec_容灾方案...
  • 常用的容灾技术

    2020-08-26 19:19:52
    2、主机层容灾技术 (一)应用级 (二)数据库级 (三)逻辑卷级 3、网络层容灾技术 3.1 网络层完整空间快照原理 4、阵列层容灾技术 4.1 SAN复制容灾 (一)同步复制容灾 同步复制原理 (二)异步复制原理...

    容灾的介绍看这里

    https://blog.csdn.net/weixin_43997530/article/details/108224626

    目录

    1、容灾的主要技术

    2、主机层容灾技术

    (一)应用级

    (二)数据库级

    (三)逻辑卷级

    3、网络层容灾技术

    3.1 网络层完整空间快照原理

    4、阵列层容灾技术

    4.1 SAN复制容灾

    (一)同步复制容灾

    同步复制原理

    (二)异步复制原理

    异步复制原理 

    4.2 NAS异步复制容灾

    NAS异步复制容灾原理 

    5、异步远程复制多时间点技术——秒级RPO

    远程复制:应用一致性

    远程复制:一致性组

    6、几种容灾技术对比

    7、容灾演练方案的流程


    1、容灾的主要技术

                 

    基于主机层容灾技术:

    • 在生产中心和灾备中心的服务器上安装专用的数据复制软件,如卷复制软件,以实现远程复制功能。两中心间必须有网络连接作为数据通道。可以在服务器层增加应用远程切换功能软件,从而构成完整的应用级容灾方案。
    • 这种数据复制方式相对投入较少,主要是软件的采购成本;兼容性较好,可以兼容不同品牌的服务器和存储设备,较适合硬件组成复杂的用户。但这种方式要在服务器上通过软件来实现同步操作,占用主机资源和网络资源非常大。

    基于网络层容灾技术:

    • 基于 SAN 网络层的数据复制技术则是在前端应用服务器与后端存储系统之间的存储区域网络(SAN),加入存储网关,前端连接服务器主机,后端连接存储设备。
    • 存储网关将在不同存储设备上的两个卷之间建立镜像关系,将写入主卷的数据同时写到备份卷中。 当主存储设备发生故障时,业务将会切换到备用存储设备上,并启用备份卷,保证数据业务不中断。

    基于阵列层容灾技术:

    • 存储层容灾主要采用了阵列间的数据复制技术,将数据从本地阵列复制到灾备阵列,在灾备存储阵列产生一份可用的数据副本。当主阵列故障时,可以将业务快速切换到备用阵列,从而最大可能的保障业务的连续性。 

    2、主机层容灾技术

    (一)应用级

    应用级的容灾技术,由应用软件来实现数据的远程复制和同步,当主中心失效时,容灾备份中心的应用软件系统恢复运行,接管主中心的业务。

                                                 

    工作原理:通过在应用软件内部,连接两个异地数据库,每次的业务处理数据分别存入主中心和备份中心的数据库中。

    优缺点:

    • 支持广域网;不需要单独的硬件、软件支持;数据逻辑复制,可避免扩散人为错误;对磁盘子系统透明
    • 需定期进行一致性检查;备份中心的备份数据无法快速恢复回主中心;需对应用程序作较大修改。

    (二)数据库级

    数据库级的容灾技术,是针对于特定的数据库设计的容灾方案。典型数据库通常都具备数据库级容灾功能。例如:Oracle Data Guard、DB2 HADR等。数据库级容灾主要是通过传输数据库日志,并在灾备站点进行重放(Replay)来实现的。数据库级容灾技术自身可做到平滑切换。

                                             

    工作原理: 配置主数据库服务器和备用数据库服务器 主数据库一旦有事务操作,会同时将日志文件传送到备用数据库,然后备用数据库对接收的日志文件进行重放,从而保持与主数据库的一致性。当主数据库发生故障时,备用数据库服务器可以接管主数据库服务器的事务处理。

    优缺点:

    • 支持广域网;不需要单独的硬件支持;对磁盘子系统透明;实施逻辑复制降低扩散人为错误风险;无须修改应用程序;主中心/容灾中心,数据可以被同时访问。
    • 备份中心的备份数据无法快速恢复回主中心;无法实现非数据库数据的远程复制;同步方式下对生产系统影响大,异步方式下会丢失较多数据,至少丢失一个日志文件;回切流程复杂;生产改造复杂。

    (三)逻辑卷级

    基于逻辑磁盘卷的远程数据复制是指根据需要将一个或者多个卷进行远程同步(或者异步)复制。该方案的实现通常通过软件来实现。

                                                        

    工作原理:远程复制控制管理软件将主用节点系统的卷上每次 IO 的操作数据实时(或者实时或者延时)复制到远程节点的相应卷上,从而实现远程两个卷之间的数据同步(或准同步)。

    优缺点:

    • 确保数据完整性,一致性;结构比较简单;对磁盘子系统透明;
    • 主机写操作性能受距离影响较大;容灾中心端无主机时,无法做数据级容灾;无法防御逻辑灾难。

    3、网络层容灾技术

    基于 SAN 网络的数据复制技术是在前端应用服务器与后端存储系统之间的存储区域网络(SAN),加入一层智能型交换机,前端连接服务器主机,后端连接存储设备。

                                                

    工作原理:

    1. 生产中心主机写入数据到本端虚拟化网关;
    2. 生产端虚拟化网关将数据写入到本端日志卷;
    3. 日志卷写入数据成功以后,生产中心的虚拟化网关返回“确认” 给本端主机;
    4. 生产端虚拟化网关将数据写入本端的生产卷的同时,向灾备端虚拟化网关发出数据写入请求;
    5. 灾备端虚拟化网关接收到写入请求后,返回“确认” 给生产端虚拟化网关;
    6. 灾备端的虚拟化网关将数据写入到灾备端的复制卷;
    7. 数据成功写入到灾备中心的复制卷后,灾备中心的虚拟化网关返回“完成”信号给生产中心的虚拟化网关。

    优缺点:

    • 支持异构存储设备;实现虚拟化整合,实现统一管理,提高存储利用率
    • 要改造 SAN 网络

    3.1 网络层完整空间快照原理

                                     

    原理:

    完整空间快照技术的实现原理:在快照时间点到来时,系统会为源数据卷分配一个大小完全相同的物理空间作为快照卷,并启动后台数据同步,在同步数据完成后,该时间点快照创建成功。 完整空间快照是源卷快照时间点的数据的物理拷贝。

    步骤:

    1. 创建一个跟源卷大小一致的卷作为快照卷,并开始后台数据同步。
    2. 在数据同步过程中如果源卷有新数据写入,写入的数据位置为还没有同步拷贝的内容,则将原数据写入到快照卷中 ,新数据写入源卷,保持源卷数据为最新状态; 如写入的数据位置为同步拷贝完成的部分,则只将新数据写入源卷;快照卷数据内容不变。
    3. 在数据全部同步完成后,快照卷与9:00的源卷数据完全相同,此时快照结束。

    说明:

    • 网络层完整空间快照中快照卷可以跨异构阵列,而且可以放在性能等相对低端的阵列上,这样就可以实现阵列间的容灾,同时充分利旧,降低TCO。
    • 当源卷阵列故障时,可以迅速从快照卷阵列拉起服务

    4、阵列层容灾技术

    阵列级容灾主要是采用阵列间复制技术实现的。由于阵列的复制不经过主机,对主机的性能影响小。 直接使用交换机作为阵列间的数据复制的媒介

                                                           

    4.1 SAN复制容灾

    (一)同步复制容灾

    • 部署方式见图,目标RPO=0,RTO分钟级。
    • 基于SAN的容灾复制才支持同步复制,建议100km以内。
    • RD主要提供容灾管理功能,包括拓扑,容灾测试,演练和灾难恢复。
    • 进行应用管理和灾备应用恢复时,服务器上需要安装Agent RD管理网络需要跟主机,存储互通。
    • 支持FC/iSCSI链路,建议同步复制使用FC链路。

                      

    同步复制原理

    同步步骤:

    • 生产存储收到主机写请求。HyperReplication将该请求记录日志。日志中只记录地址信息,不记录数据内容。
    • 将该请求写入主LUN和从LUN。通常情况下LUN是回写状态,数据会写入Cache。
    • HyperReplication等待主LUN和从LUN的写处理结果都返回。如果都写成功,清除日志;否则保留日志,进入异常断开状态,后续启动同步时重新复制该日志地址对应的数据块。
    • 返回主机写请求处理结果,以写主LUN的处理结果为准。

    分裂:

    在分裂状态下,生产主机的写请求只会写到主LUN,并通过差异日志来记录主、从LUN数据之间的差异。当用户希望重新保持主、从LUN数据一致时,可以进行一次手动启动同步操作,同步过程就是将差异日志中标为“有差异”的数据块从主LUN增量拷贝到从LUN的过程,其I/O处理原理与初始同步的原理类似

                                     

    (二)异步复制原理

    • 部署方式见图,目标RPO>3s,RTO分钟级。
    • 与同步复制的差异点,有时间间隔的复制策略,理论无距离限制。
    • RD主要提供容灾管理功能,包括复制策略,拓扑,容灾测试,演练和灾难恢复。
    • 进行应用管理和灾备应用恢复时,服务器上需要安装Agent RD管理网络需要跟主机,存储互通。
    • 秒级复制在存储上触发,15分钟以上的可在RD上触发。

                   

    异步复制原理 

    时间片:在Cache中管理一段时间内写入数据的逻辑空间(数据大小没有限定)

    在低RPO的应用场景下,异步远程复制周期很短,OceanStor存储系统Cache中能缓存多个时间片中的全部数据;如果主机业务带宽或容灾带宽出现异常或故障,造成复制周期变长或中断,此时Cache中的数据会按照刷盘策略自动刷盘并进行一致性保护,复制时再从盘上进行读取。

    1. 每当间隔一个同步周期(由用户设定,范围为3s~1440min),系统会自动启动一个将主站点数据增量同步到从站点的同步过程(如果同步类型为手动,则需要用户来触发同步)。每个复制周期启动时在主LUN(LUN A)和从LUN(LUN B)的缓存中产生新的时间片(TPN+1和TPX+1);
    2. 主站点接收生产主机写请求;
    3. 主站点将写请求的数据写入Cache时间片TPN+1中,立即响应主机写完成;
    4. 同步数据时,读取前一个周期主LUN(LUN A)Cache时间片TPN的数据,传输到从站点,写入从LUN(LUN B)Cache时间片TPX+1中;若主站点Cache写缓存达到高水位时会自动将数据从Cache写入硬盘中,此时时间片TPN的数据会在盘上生成快照,同步时已写入硬盘的数据从快照中读取并复制到从LUN(LUN B);
    5. 同步数据完成后,按照刷盘策略将主LUN(LUN A)和从LUN(LUN B)Cache中时间片TPN和TPX+1的数据下盘(生成的快照自动删除),等待下一个同步的到来。

    切换:

    • 同步远程复制在正常状态下可以进行主从切换;
    • 分裂状态下,需要设置从LUN可写才能进行主从切换。
    • 异步远程复制处于分裂状态;
    • 分裂状态下,需要设置从LUN可写;

                               

    4.2 NAS异步复制容灾

    • NAS文件系统复制目前只有V3R2C10版本提供,采用ROW实现。
    • RD的NAS容灾管理不在Linux或者Windows上部署Agent,只管理V3存储的复制策略和容灾恢复。
    • 文件系统当前主要支持NFS/CIFS。容灾管理目前只管理FS复制部分,文件系统和权限控制部分,系统创建时需要配置。
    • 文件系统复制与SAN类似,支持FC/iSCSI链路。

                        

    NAS异步复制容灾原理 

    • 每个周期开始时,文件系统异步远程复制创建主FS(主文件系统)的快照,根据上一周期复制完成到本周期开始这段时间内的增量信息,读取快照的数据复制到从FS,增量复制完成后,从FS的内容与主FS的快照内容相同,从FS形成数据一致性点。
    • 可实现文件系统到文件系统的远程复制,不支持目录到目录、文件到文件的复制方式;
    • 同一文件系统只能包含于一个复制任务中,但一个复制任务中可以包含多个文件系统;
    • 文件系统只支持1对1复制,同一文件系统不能即作为复制源又作为复制目的地,不支持级联复制,不支持3DC;
    • 增量复制的最小单位为文件系统块大小(4K-64K);异步复制同步周期最短5分钟;
    • 支持断点续传

                                

    5、异步远程复制多时间点技术——秒级RPO

    最小3秒一个一致性点:

    每个复制周期启动时在主LUN和从LUN的缓存中产生新的时间片*(T2, P2)。

    主机新写入的数据缓存在主LUN Cache的时间片T2中。

    响应主机写完成。 将时间片T1的数据直接复制到从LUN,写入从LUN的时间片P2中。

    主从LUN各自将收到的数据下盘。

    • 拷贝直接从Cache读取数据,时延小。
    • 快照不需实时COW更新数据,同步对性能的影响小,周期可缩短到3秒的复制周期。

                                                             

    远程复制:应用一致性

    应用一致性: 在主机上安装一致性代理Agent,实现阵列快照和数据库的联动。

    当快照任务执行时:

    • 首先将数据库置于备份模式,执行检查点,将内存中的脏数据全部写入存储系统。
    • 然后通知阵列执行快照。
    • 最后再将数据库脱离备份模式。

    优点:

    • 灾备端拉起数据直接使用,无须做Roll forward 和Rollback。

                                                                      

    远程复制:一致性组

    • 用于保持多个LUN之间镜像数据的时间一致性。
    • 所有成员一起同步、分裂、断开和主从切换。

                                                   

     

    • 在大中型数据库应用中,数据、日志、修改信息等存储在阵列的不同LUN中,通常称这种有关联的LUN为非独立LUN,缺少其中一个LUN的数据,都将导致其他LUN中的数据失效。
    • 我们希望可以同时对这些LUN同时进行数据的同步或分裂等操作,以保证多个从LUN之间数据的关联性不变,从而保证容灾备份数据的完整性和可用性。这个技术就是远程复制一致性组技术。
    • 华为阵列的远程复制一致性组内的远程复制的复制对的个数最大值为8,不支持跨阵列一致性组。

    注意:有关联关系的LUN的远程复制应放到一个一致性组中,没有关联关系的LUN不要放到一个一致性组中。另外,同步远程复制和异步远程复制不能放到同一个一致性组中。所有远程复制的从LUN必须位于同一台远端存储系统。

    6、几种容灾技术对比

          

    7、容灾演练方案的流程

     

    展开全文
  • 目前市场上有多种成熟的容灾技术可以选择,这些容灾技术最主要的技术差异在于数据复制的发起平台和接受平台。根据这些平台的不同,可以分为:基于主机的复制技术、基于磁盘阵列的复制技术、基于智能SAN 虚拟存储设备...
  • 对常见数据库容灾技术进行直观比较,帮助用户正确理解各种数据库容灾技术的本质特征,结合自己的业务特点,选择正确的容灾方案。
  • 高端磁盘阵列及容灾技术
  • IBM 容灾技术白皮书

    2009-04-10 16:34:11
    IBM 容灾技术白皮书 现在有最好的容灾技术白皮书
  • Oracle10g DataGuard远程容灾技术
  • oracle容灾技术

    2018-11-19 12:53:45
    介绍Oracle容灾相关技术,对于想了解灾备方面的知识的初学者来说不错,可以借鉴。
  • Compellent远程容灾技术

    2011-02-20 17:18:04
    Compellent远程容灾技术的原理及实现方法,首次发布。
  • EMC_容灾技术及产品介绍EMC_容灾技术及产品介绍
  • 京东云备份和容灾技术白皮书精品报告2020.pdf
  • VMGW和MGW负荷分担技术主要是针对MGW的容灾技术,而Iu-flex和双归属技术还可以用于MSC Server中。Iu-flex技术适合在热点地区或小规模组网中应用,Iu-flex技术如果能和VMGW技术或者Iu口应用IP承载相结合,将能更大的...
  • oracle容灾技术.

    2007-08-27 20:24:25
    oracle容灾技术.
  • 数据中心网络存储容灾技术白皮书数据中心网络存储容灾技术白皮书
  • 为提升教务管理系统的容灾抗毁能力,通过对容灾技术及相关优缺点进行分析,设计一种简单、经济的容灾备份方案,即每天定时进行本地数据备份和远程异地数据备份。实践证明,该方案对灾难具有很好的抵御能力。
  • EMC存储容灾技术交流

    2010-06-07 15:34:09
    EMC厂家的PPT,主要介绍容灾技术,介绍一些解决方案和技术方案
  • 介绍数据容灾技术的综述性论文,对比分析各种容灾技术,PDF格式文件。
  • 容灾技术方案

    2012-08-09 10:56:18
    关于容灾架构技术方面的内容,同时介绍了具体产品的有缺点。
  • 容灾技术Data Guard搭建

    2016-10-20 23:15:55
    Oracle Data Guard容灾技术是一种备份容灾策略,简称DG。以下是DG的搭建过程: 准备条件:两台虚拟机,一台装载主库,另一台装载备库(备库为空库,只有安装好oracle软件) ----主库: PROD/IP...
    Oracle Data Guard容灾技术是一种备份容灾策略,简称DG。以下是DG的搭建过程:

    准备条件:两台虚拟机,一台装载主库,另一台装载备库(备库为空库,只有安装好oracle软件)
    ----主库: PROD/IP:192.168.2.6
    ----备库:  PROD/IP:192.168.2.4   # 备库名PROD(提前定义)要与主库名一致。

    --关闭主库,从spfile创建pfile:

    SQL> create pfile from spfile;

    File created.

    --在主库修改参数文件:
    [oracle@enmo dbs]$ vi initPROD.ora
    PROD.__db_cache_size=352321536
    PROD.__java_pool_size=4194304
    PROD.__large_pool_size=8388608
    PROD.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment
    PROD.__pga_aggregate_target=335544320
    PROD.__sga_target=503316480
    PROD.__shared_io_pool_size=0
    PROD.__shared_pool_size=130023424
    PROD.__streams_pool_size=0
    *.audit_file_dest='/u01/app/oracle/admin/prod/adump'                    #审计文件目录
    *.compatible='11.2.0'
    *.control_files='/u01/app/oracle/oradata/PROD/ora_control1.ctl','/u01/app/oracle/oradata/PROD/ora_control2.ctl'    #控制文件对象
    *.db_block_size=8192
    *.db_domain='oracle.com'            #domain名
    *.db_name='PROD'
    *.db_recovery_file_dest_size=3221225472
    *.db_recovery_file_dest='/u01/app/FRA/'
    *.dispatchers='(PROTOCOL=TCP) (SERVICE=ORCLXDB)'
    *.memory_target=800M
    *.open_cursors=300
    *.processes=150
    *.remote_login_passwordfile='EXCLUSIVE'
    *.undo_tablespace='UNDOTBS1'

    DB_UNIQUE_NAME=PROD                       #主库唯一库名
    LOG_ARCHIVE_CONFIG='DG_CONFIG=(PROD,ENMO)'
    LOG_ARCHIVE_DEST_1=
     'LOCATION=/home/oracle/arch/PROD/        #主库本地归档日志存放目录
      VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
      DB_UNIQUE_NAME=PROD'
    LOG_ARCHIVE_DEST_2=
     'SERVICE=ENMO ASYNC                     #此处ENMO只是作为连接备库ENMO库的网络链接串(tnsnames)
      VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
      DB_UNIQUE_NAME=ENMO'
    LOG_ARCHIVE_DEST_STATE_1=ENABLE
    LOG_ARCHIVE_DEST_STATE_2=ENABLE
    REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
    LOG_ARCHIVE_FORMAT=%t_%s_%r.arc            #主库备库的归档日志文件命名方式的定义
    LOG_ARCHIVE_MAX_PROCESSES=30

    FAL_SERVER=ENMO                            #备库库名
    DB_FILE_NAME_CONVERT='ENMO','PROD'
    LOG_FILE_NAME_CONVERT=
     '/home/oracle/arch/ENMO/','/home/oracle/arch/PROD/'              #备库主库存放日志文件目录的交换,可以简写为:'ENMO','PROD'
    STANDBY_FILE_MANAGEMENT=AUTO


    --从pfile生成spfile,测试打开主库,并强制开启force logging:
    SQL> create spfile from pfile;
    File created.

    SQL> startup
    ORACLE instance started.

    Total System Global Area  835104768 bytes
    Fixed Size                  2257840 bytes
    Variable Size             541068368 bytes
    Database Buffers          289406976 bytes
    Redo Buffers                2371584 bytes
    Database mounted.
    Database opened.
    SQL> 
    SQL> alter database force logging;
    Database altered.

    SQL> select force_logging from v$database;

    --查看主库的重做日志文件组:
    SQL> select group#,member from v$logfile;

        GROUP# MEMBER
    ---------- --------------------------------------------------
             1 /u01/app/oracle/oradata/PROD/redo01.log
             2 /u01/app/oracle/oradata/PROD/redo02.log
             3 /u01/app/oracle/oradata/PROD/redo03.log

    --在主库添加standby日志组(添加规则:普通日志文件<=standby日志文件,且文件大小对应一致
    SQL> alter database add standby logfile group 4
      2  ('/u01/app/oracle/oradata/PROD/redo04_staby.log',
      3   '/u01/app/oracle/oradata/PROD/redo05_staby.log')
      4  size 10M;
    Database altered.

    SQL> alter database add standby logfile group 5
      2  ('/u01/app/oracle/oradata/PROD/redo06_staby.log',
      3   '/u01/app/oracle/oradata/PROD/redo07_staby.log')
      4  size 10M;
    Database altered.

    SQL> alter database add standby logfile group 6
      2  ('/u01/app/oracle/oradata/PROD/redo08_staby.log',
      3   '/u01/app/oracle/oradata/PROD/redo09_staby.log')
      4  size 10M;
    Database altered.

    SQL> alter database add standby logfile group 7
      2  ('/u01/app/oracle/oradata/PROD/redo010_staby.log',
      3   '/u01/app/oracle/oradata/PROD/redo011_staby.log')
      4  size 10M;
    Database altered.

    --增加后查看所有的日志文件:
    SQL> select group#,member from v$logfile;
        GROUP# MEMBER
    ---------- --------------------------------------------------
             1 /u01/app/oracle/oradata/PROD/redo01.log
             2 /u01/app/oracle/oradata/PROD/redo02.log
             3 /u01/app/oracle/oradata/PROD/redo03.log
             4 /u01/app/oracle/oradata/PROD/redo04_staby.log
             4 /u01/app/oracle/oradata/PROD/redo05_staby.log
             5 /u01/app/oracle/oradata/PROD/redo06_staby.log
             5 /u01/app/oracle/oradata/PROD/redo07_staby.log
             6 /u01/app/oracle/oradata/PROD/redo08_staby.log
             6 /u01/app/oracle/oradata/PROD/redo09_staby.log
             7 /u01/app/oracle/oradata/PROD/redo010_staby.log
             7 /u01/app/oracle/oradata/PROD/redo011_staby.log
                    
    --从主库复制pfile参数文件与密码文件到备库的主机上:
    [oracle@enmo dbs]$ ls
    hc_OCMU.dat  initOCMU.ora  init.ora.bck  initPROD.ora.bck  lkPROD     snapcf_OCMU.f  spfileOCMU.ora
    hc_PROD.dat  init.ora      initPROD.ora  lkORA11GR2        orapwPROD  snapcf_PROD.f  spfilePROD.ora
    [oracle@enmo dbs]$ scp initPROD.ora orapwPROD 192.168.2.4:/u01/app/oracle/product/11.2.0/dbhome_1/dbs
    oracle@192.168.2.4's password: 
    initPROD.ora                                                                            100% 1432     1.4KB/s   00:00    
    orapwPROD                                                                               100% 1536     1.5KB/s   00:00

    ----配置静态监听,相互访问:
    ---主库PROD库静态监听配置:
    SID_LIST_LISTENER=
      (SID_LIST=
        (SID_DESC=
         (GLOBAL_DBNAME=PROD.oracle.com)
         (ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1)
         (SID_NAME=PROD))
      )

    --主库PROD库tns配置:
    ENMO =
      (DESCRIPTION =
        (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.2.4)(PORT = 1521))
        (CONNECT_DATA =
          (SERVER = DEDICATED)
          (SERVICE_NAME = ENMO.oracle.com)
        )
      )

    --主库PROD主库启动并注册监听:
    STATUS of the LISTENER
    ------------------------
    Alias                     LISTENER
    Version                   TNSLSNR for Linux: Version 11.2.0.4.0 - Production
    Start Date                18-OCT-2016 16:40:46
    Uptime                    1 days 3 hr. 2 min. 57 sec
    Trace Level               off
    Security                  ON: Local OS Authentication
    SNMP                      OFF
    Listener Parameter File   /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora
    Listener Log File         /u01/app/oracle/diag/tnslsnr/enmo/listener/alert/log.xml
    Listening Endpoints Summary...
      (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=enmo.oracle.com)(PORT=1521)))
      (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
    Services Summary...
    Service "ORCLXDB.oracle.com" has 1 instance(s).
      Instance "PROD", status READY, has 1 handler(s) for this service...
    Service "PROD.oracle.com" has 2 instance(s).
      Instance "PROD", status UNKNOWN, has 1 handler(s) for this service...
      Instance "PROD", status READY, has 1 handler(s) for this service...
    The command completed successfully

    --备库ENMO库静态监听配置:
    SID_LIST_LISTENER=
      (SID_LIST=
        (SID_DESC=
         (GLOBAL_DBNAME=ENMO.oracle.com)
         (ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1)
         (SID_NAME=ORA11GR2 ))
      )

    --备库ENMO库tns配置:
    PROD =
      (DESCRIPTION =
        (ADDRESS_LIST =
          (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.2.6)(PORT = 1521))
        )
        (CONNECT_DATA =
          (SERVICE_NAME =  PROD.oracle.com)
        )
      )

    --备库ENMO备库启动并注册监听:
    STATUS of the LISTENER
    ------------------------
    Alias                     LISTENER
    Version                   TNSLSNR for Linux: Version 11.2.0.4.0 - Production
    Start Date                19-OCT-2016 19:51:01
    Uptime                    0 days 0 hr. 2 min. 2 sec
    Trace Level               off
    Security                  ON: Local OS Authentication
    SNMP                      OFF
    Listener Parameter File   /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora
    Listener Log File         /u01/app/oracle/diag/tnslsnr/oracle/listener/alert/log.xml
    Listening Endpoints Summary...
      (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=oracle)(PORT=1521)))
      (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
    Services Summary...
    Service "ENMO.oracle.com" has 2 instance(s).
      Instance "ENMO", status BLOCKED, has 1 handler(s) for this service...
      Instance "ORA11GR2", status UNKNOWN, has 1 handler(s) for this service...
    The command completed successfully
    监听的配置与备库参数文件的先后顺序没有要求,这都是自己安排设计的。

    --在备库ENMO库的参数文件修改:
    *.audit_file_dest='/u01/app/oracle/admin/enmo/adump'                #备库的审计文件目录
    *.compatible='11.2.0'
    *.control_files='/u01/app/oracle/oradata/ENMO/ora_control1.ctl','/u01/app/oracle/oradata/ENMO/ora_control2.ctl'   #备库ENMO库控制文件对象
    *.db_block_size=8192
    *.db_domain='oracle.com'
    *.db_name='PROD'                   #备库名与主库名保持一致
    *.db_recovery_file_dest_size=3221225472
    *.db_recovery_file_dest='/u01/app/FRA/'
    *.dispatchers='(PROTOCOL=TCP) (SERVICE=ORCLXDB)'
    *.memory_target=800M
    *.open_cursors=300
    *.processes=150
    *.remote_login_passwordfile='EXCLUSIVE'
    *.undo_tablespace='UNDOTBS1'
    DB_UNIQUE_NAME=ENMO             #备库的唯一库名
    LOG_ARCHIVE_CONFIG='DG_CONFIG=(PROD,ENMO)'
    LOG_ARCHIVE_DEST_1=
     'LOCATION=/home/oracle/arch/ENMO/                          #归档日志文件存放目录
      VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
      DB_UNIQUE_NAME=ENMO'
    LOG_ARCHIVE_DEST_2=
     'SERVICE=PROD ASYNC                                        #此处PROD只是作为连接备库PROD库的网络链接串(tnsnames)
      VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
      DB_UNIQUE_NAME=PROD'
    LOG_ARCHIVE_DEST_STATE_1=ENABLE
    LOG_ARCHIVE_DEST_STATE_2=ENABLE
    REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
    LOG_ARCHIVE_FORMAT=%t_%s_%r.arc                            #主库备库的归档日志文件命名方式的定义
    LOG_ARCHIVE_MAX_PROCESSES=30

    FAL_SERVER=PROD                                            #备库库名
    DB_FILE_NAME_CONVERT='PROD','ENMO'
    LOG_FILE_NAME_CONVERT='PROD','ENMO'
    STANDBY_FILE_MANAGEMENT=AUTO
    在备库修改pfile参数文件后,从pfile文件生成spfile文件,并启动实例到nomount状态:

    --在主库复制文件到备库:
    [oracle@enmo ~]$ rman target / auxiliary sys/oracle@enmo
    Recovery Manager: Release 11.2.0.4.0 - Production on Wed Oct 19 20:22:10 2016
    Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
    connected to target database: PROD (DBID=336361349)
    connected to auxiliary database: PROD (not mounted)

    RMAN> duplicate target database for standby from active database dorecover nofilenamecheck;
    Starting Duplicate Db at 19-OCT-16
    using target database control file instead of recovery catalog
    allocated channel: ORA_AUX_DISK_1
    channel ORA_AUX_DISK_1: SID=20 device type=DISK
    contents of Memory Script:
    {
       backup as copy reuse
       targetfile  '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwPROD' auxiliary format 
     '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwENMO'   ;
    }
    executing Memory Script
    Starting backup at 19-OCT-16

    ... ...

    executing Memory Script
    executing command: SET until clause
    Starting recover at 19-OCT-16
    using channel ORA_AUX_DISK_1
    starting media recovery
    archived log for thread 1 with sequence 96 is already on disk as file /home/oracle/arch/ENMO/1_96_924523013.arc
    archived log for thread 1 with sequence 97 is already on disk as file /home/oracle/arch/ENMO/1_97_924523013.arc
    archived log file name=/home/oracle/arch/ENMO/1_96_924523013.arc thread=1 sequence=96
    archived log file name=/home/oracle/arch/ENMO/1_97_924523013.arc thread=1 sequence=97
    media recovery complete, elapsed time: 00:00:01
    Finished recover at 19-OCT-16
    Finished Duplicate Db at 19-OCT-16                        #完成把主库所有文件复制到备库
    RMAN> 
    完成文件的移动。

    --备库同步数据:
    SQL> select open_mode from v$database;
    OPEN_MODE
    --------------------
    MOUNTED

    SQL> RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;  #打开使用日志文件功能,是主库备库保持同步。
    Media recovery complete.
    SQL> select database_role,open_mode from v$database;
    DATABASE_ROLE    OPEN_MODE
    ---------------- --------------------
    PHYSICAL STANDBY MOUNTED

    SQL> recover managed standby database cancel;                                         #关闭使用日志文件功能
    Media recovery complete.

    --查看备库使用日志的状况:
    SQL> select SEQUENCE#,APPLIED from v$archived_log;
     SEQUENCE# APPLIED
    ---------- ---------
            97 YES
            96 YES
            98 YES
            99 YES
           100 YES
             1 NO
           101 YES
             2 NO
             3 NO
           105 YES
           106 YES
     SEQUENCE# APPLIED
    ---------- ---------
           103 YES
           102 YES
           104 YES
           107 YES
           108 YES
           109 YES
           110 YES
           111 NO
           111 YES
           112 NO
           112 YES
    22 rows selected.

    --snapshot standby:
    --Oracle 11g物理Data Guard之Snapshot Standby数据库功能

    SQL> alter database convert to snapshot standby;
    Database altered.
    SQL> select open_mode,protection_mode,switchover_status,database_role from v$database;

    OPEN_MODE            PROTECTION_MODE      SWITCHOVER_STATUS    DATABASE_ROLE
    -------------------- -------------------- -------------------- ----------------
    READ WRITE           MAXIMUM PERFORMANCE  NOT ALLOWED          SNAPSHOT STANDBY

    备库的角色有两种:一种是PHYSICAL STANDBY,另一种是SNAPSHOT STANDBY。
    备库的这两种角色可以通过alter database convert to snapshot standby;
    与alter database convert to physical standby;相互转换。snapshot standby角色
    只是作为测试角色,没有使用日志文件的功能,所以一般是保持physical standby角色。

    --打开备库:
    SQL> alter database open;
    Database altered.

    --备库的状态信息:
    SQL> select open_mode,protection_mode,switchover_status,database_role from v$database;

    OPEN_MODE            PROTECTION_MODE      SWITCHOVER_STATUS    DATABASE_ROLE
    -------------------- -------------------- -------------------- ----------------
    READ WRITE           MAXIMUM PERFORMANCE  NOT ALLOWED          SNAPSHOT STANDBY

    --主库的状态信息:
    SQL> select open_mode,protection_mode,switchover_status,database_role from v$database;
    OPEN_MODE            PROTECTION_MODE      SWITCHOVER_STATUS    DATABASE_ROLE
    -------------------- -------------------- -------------------- ----------------
    READ WRITE           MAXIMUM PERFORMANCE  TO STANDBY           PRIMARY

    --备库不开启(或者监听不启动)时主库的状态:
    SQL>  select open_mode,protection_mode,switchover_status,database_role from v$database;

    OPEN_MODE            PROTECTION_MODE      SWITCHOVER_STATUS    DATABASE_ROLE
    -------------------- -------------------- -------------------- ----------------
    READ WRITE           MAXIMUM PERFORMANCE  FAILED DESTINATION   PRIMARY

    到这里,Datab Guard(简称DG)已经搭建完成。

    来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31392094/viewspace-2126841/,如需转载,请注明出处,否则将追究法律责任。

    转载于:http://blog.itpub.net/31392094/viewspace-2126841/

    展开全文
  • 第一讲:双活容灾技术和方案概述

    千次阅读 2019-12-29 17:32:04
    容灾建设在我国已有十多年的历史了,尤其是2007年发布国标GB/T20988-2007《信息系统灾难恢复规范》后,各行各业对容灾建设都非常重视,各种新的容灾技术和产品也得到了快速的发展和应用。在我国容灾发展的前十年,...
  • 本文从普通用户而不是厂家(不谈 RPO、RTO、MDT、MTBF、MTTR等等专业术语)角度出发来审视和比较各种数据库容灾技术,希 望能帮助广大用户在选购方案时少被忽悠、少走弯路、避免不必要的经济损失和系统事故。...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,981
精华内容 792
关键字:

容灾技术