精华内容
下载资源
问答
  • 目前,针对oracle数据库的...如果不是数据量大的惊人,其他方式没办法做到同步,或者要同时对数据库和应用进行容灾,存储级的方案是没有什么优势的,尤其是它对网络的环境要求是非常高的,在异地环境中几乎不可能实现。
  • http://blog.sina.com.cn/s/blog_8379b7160100txh5.html
    展开全文
  • 容灾数据复制技术的比较

    千次阅读 2017-05-12 10:08:28
    容灾数据复制技术的比较   一、概述 近几年来,容灾已经成为信息数据中心建设的热门课题。很多容灾技术也快速发展起来,对用户来说也有很广阔的选择余地。但由于容灾方案的技术复杂性和多样性,一般用户很难搞...

    容灾数据复制技术的比较

     

    一、概述

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

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

    二、离线式容灾

    所谓的离线式容灾主要依靠备份技术来实现。其重要步骤是将数据通过备份系统备份到磁带上面,而后将磁带运送到异地保存管理。离线式容灾具有实时性低、可备份多个副本、备份范围广、长期保存、投资较少等特点,由于是备份一般是压缩后存放到磁带的方式所以数据恢复较慢,而且备份窗口内的数据都会丢失,因此一般用于数据恢复的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


    展开全文
  • OracleDataguard数据同步复制容灾技术方案.doc
  • 数据库容灾复制解决方案全分析 https://blog.csdn.net/weixin_33985507/article/details/91535654 工程师小C的小店我也想开通小店 Python编程三剑客:Python编程从入门到实践第2版+快速上手第2...

    数据库容灾、复制解决方案全分析

    最近发现论坛上关于数据库远程复制和异地容灾等问题的帖子比较多,现在把我知道的一些解决方案进行一下分析,能力有限,还希望大家多多补充、纠正![@more@]
    数据库容灾、复制解决方案全分析  http://www.tianyar.net/blog/user1/10202/archives/2006/8967.shtml

    最近发现论坛上关于数据库远程复制和异地容灾等问题的帖子比较多,现在把我知道的一些解决方案进行一下分析,能力有限,还希望大家多多补充、纠正!

    目前,针对oracle数据库的远程复制、容灾主要有以下几种技术或解决方案:
    (1)基于存储层的容灾复制方案
    这种技术的复制机制是通过基于SAN的存储局域网进行复制,复制针对每个IO进行,复制的数据量比较大;系统可以实现数据的同步或异步两种方式的复制.对大数据量的系统来说有很大的优势(每天日志量在60G以上),但是对主机、操作系统、数据库版本等要求一致,且对络环境的要求比较高。
    目标系统不需要有主机,只要有存储设备就可以,如果需要目标系统可读,需要额外的配置和设备,比较麻烦。

    (2)基于逻辑卷的容灾复制方案

    这种技术的机制是通过基于TCP/IP的网络环境进行复制,由操作系统进程捕捉逻辑卷的变化进行复制。其特点与基于存储设备的复制方案比较类似,也可以选择同步或异步两种方式,对主机的软、硬件环境的一致性要求也比较高,对大数据量的应用比较有优势。其目标系统如果要实现可读,需要创建第三方镜像。个人认为这种技术和上面提到的基于存储的复制技术比较适合于超大数据量的系统,或者是应用系统的容灾复制。

    我一直有一个困惑,存储级的 复制,假如是同步的,能保证 数据库所有文件一致吗 ?或者说是保证在 异常发生的那一刻有足够的缓冲来保障?

    也就是说,复制的时候起文件写入顺序和oracle的顺序一致吗?如果不一致就可能有问题,那么是通过什么机制来实现的呢?


    上次一个存储厂商来讲产品,我问技术工程师这个问题,没有能给出答案

    我对存储级的复制没有深入的研究过,主要是我自己的一些理解,你们帮我看一下吧……
    我觉得基于存储的复制应该是捕捉原系统存储上的每一个变化,而不是每隔一段时间去复制一下原系统存储上文件内容的改变结果,所以在任意时刻,如果原系统的文件是一致的,那么目标端也应该是一致的,如果原系统没有一致,那目标端也会一样的。形象一点说它的原理可能有点像raid 0,就是说它的写入顺序应该和原系统是一样的。不知道我的理解对不对。另外,在发生故障的那一刻,如果是类似断电的情况,那么肯定会有缓存中数据的损失,也不能100%保证数据文件的一致。一般来说是用这种方式做oracle的容灾备份,在发生灾难以后目标系统的数据库一般是只有2/3的机会是可以正常启动的(这是我接触过的很多这方面的技术人员的一种说法,我没有实际测试过)。我在一个移动运营商那里看到过实际的情况,他们的数据库没有归档,虽然使用了存储级的备份,但是白天却是不做同步的,只有在晚上再将存储同步,到第二天早上,再把存储的同步断掉,然后由另外一台主机来启动目标端存储上的数据库,而且基本上是有1/3的机会目标端数据库是起不来的,需要重新同步。

    所以我觉得如果不是数据量大的惊人,其他方式没办法做到同步,或者要同时对数据库和应用进行容灾,存储级的方案是没有什么优势的,尤其是它对网络的环境要求是非常高的,在异地环境中几乎不可能实现。

    不知道我的理解对不对,也不知道是不是回答了你的问题,呵呵。欢迎指正!

    应该说部分地回答了我的问题,呵呵

    因为 实际上存储设备的写入顺序 和 oracle 的进程的写入顺序肯定是不一样的,存储设备一定是做过重整的,那 不管同步或者异步的拷贝都 有可能 存在问题的。

    所以我一直对这个方案的可靠性不敢完全相信,这样一来,倒不如 data guard 可靠了


    因为很明显,存储设备拷贝过去的数据文件 不一致是有很大的概率的

    你的意思是说即使不考虑目标端,仅在源端的情况下,存储设备的写入顺序也是和Oracle不一致的?这应该是一个原因。我觉得还有一种可能性就是在忽略存储设备的这种情况下,在主系统当机,发生切换的时候,主系统存储上的数据文件也不一定能保证一致,就算目标系统保持了完全的同步,也一样不能保正目标端数据可可以启动。

    不太理解,为什么说存储设备的写入顺序会和oracle进程的写入顺序不一致阿
    如果说仅在源端情况下,存储设备的写入顺序也是和Oracle进程不一致,那么不考虑异地冗灾,那么是不是意味着即使本地服务器crash,也无法启动存储上的数据文件?

    我也有这个疑问,以前一直觉得仅考虑主系统的情况下,存储设备的写入顺序应该是和数据库的写入顺序一致的, 但我觉得biti_rainy的理解也是有道理的,存储设备毕竟和一般的磁盘不一样,很可能再写入的时候会作重新的组合,不过不知道具体的证据是什么啊?
    按照这种理解,再写入的某一瞬间,数据库的写入顺序和存储的写入顺序可能是不一致的,但既然存储写入的结果跟oracle的写入结果肯定是一致的,那么我们可以把一个比较长的写入过程分成若干个时间段,在每个时间段的结尾,oracle和存储设备的写入结果都是完全一致的,那么这个时间段的大小是多少呢?
    呵呵,说得我自己都快晕了,也不知道大家明白我的意思没有……
    o
    biti_rainy能不能给我们解释一下啊?或者论坛里有没有对存储设备比较了解的兄弟啊?

    系统上通常不一致没关系是因为还有 logfile 的存在,而日志文件通常是被写入了磁盘的,oracle本身是顺序写的,还不需要读,应该是被重整的几率比较小

    还有存储设备上,比如掉电没关系,是因为存储设备都有足够的短时间供电能力使得 cache 中的数据能被写入磁盘,这个如果不能保证那一掉电基本都要出问题的


    但是在复制的那端,我就不清楚是怎么处理的,比如我要停掉复制,开始用起这数据来,或者说设备掉电了,这个时候是怎么处理的


    在复制的那端,我感觉是没有经过特殊处理的,因为存储设备完全是物理上的同步,在你停掉复制的时候,他最多只能保证在停止复制或原系统掉电的这一刻所有文件在物理上是和原系统的存储是完全一致的,但他绝对不会去校验或保证oracle的数据文件在逻辑上是否一致,所以会造成复制端在停止复制后有很大几率不能正常启动。我在客户那的情况就是在原系统正常运行的情况下,停止存储的复制,然后启动目标端数据库,但还是有1/3的几率无法启动,如果是在原系统发生故障或断电的情况下,估计就更不好说了。
    我还是比较佩服那个客户的勇气,一个省级移动运营商的数据中心,数据库连归档都没有,一旦系统崩溃,至少要损失当天的数据,同时容灾端的数据库能不能起来还是个问题……
    还好目前还没有出问题,要是出了问题,不知道他们会怎么办……

    上次做存储设备的来公司,谈到这个问题的时候说: 很多客户就是这么做的

    我就说: 很多人这么做的并不能说就没问题,因为很多 人没有出现事故,是因为隐藏的问题没有机会暴露出来。我需要:
    1:机制上的可靠保障,这个可能只有非常理解 原理的人能回答
    2:实际系统的测试,要经过在我们自己提供的数据场景下反复测试

    通过这两点之后我们才敢放心使用


    同意,确实很多人都是这么用的,也确实都很可能出现问题,所以我一直以为基于存储的数据库容灾方案是有问题的,但在有些环境中好像还只能这么做,例如我们的一个客户,也是一个省级的移动运营商,其数据库每天的日志量达到100G以上,在这种条件下,好像只有这种解决方案比较可行,其他的都会有一些问题,至少那些使用软件实现的逻辑复制方案是不行的,我感觉oracle自己的standby好像也负担不了吧?不过他们的数据库至少还是归档的,还有一点保证。呵呵。

    从ORACLE的角度来衡量基于存储的容灾肯定是有问题的,不可能做到100%可用。

    即使是ORACLE的DATA GUARD也不能保证100%没有数据丢失(当前日志组的数据)。

    换个思路了,使用基于应用的同步方案吧。


    (3)基于oracle redo log的逻辑复制方式
    使用这种方式的主要有一些第三方的软件,以及oracle自己的DATAGUARD 中的logical Standby。先介绍一下第三方的软件产品吧……

    目前,国外已经有了很多比较成熟的产品及成功案例,国内也有类似的产品, 但在产品的成熟程度和成功案例上跟国外还有一定的差距。
    这类产品的原理基本相同,其工作过程可以分为以下几个流程:
    使用oracle以外的独立进程,捕捉redo log file 的信息,将其翻译成sql语句,再通过网络传输到目标端数据库,在目标端数据库执行同样的sql。如果其进程赶不上oracle日志切换,也可以捕捉归档日志中的内容。也有的产品在源端以事务为单位,当一个事务完成后,再把它传输到目标端。所有的产品一般都是以表为单位进行复制,同时也支持大部分DDL的复制(主要在oracle9i环境中)。
    这种技术的技术特点和优势主要有以下几点:
    目标端数据库一直是一个可以访问的数据库;
    能保证两端数据库的事务一致性;
    因为使用oracle以外的进程进行捕捉,且其优先级低于oracle进程,所以对源系统数据库的性能影响很小;
    基于其实现原理及多个队列文件的使用,复制环境可以提供网络失败、数据库失败、主机失败的容错能力;
    因为这类软件复制的只是sql语句或事务,所以他可以完全支持异构环境的复制,硬件的型号,oracle的版本,操作系统的种类、版本等都没有要求。
    这种方式还可以支持多种复制方式,比如数据集中、分发、对等复制、或者多层测的复制等。
    由于传输的内容只是redolog 或archive log中的一部分,所以对网络资源的占用很小,可以实现不同城市之间的远程复制。

    基于redolog的逻辑复制产品有很多的优势,但跟上面提到过的其他方案比较起来,也有一些缺点:
    数据库的吞吐量太大时,其实据会有较大的延迟,当数据库每天的日量达到60G或更大时,这种方案的可行性交差;
    实施的过程可能会有一些停机时间,来进行数据的同步和配置的激活;
    复制环境建立起来以后,对数据库结构上的一些修改需要按照规定的操作流程进行,有一定的维护成本。
    不过目前这类产品的发展很快,上面的这些问题,在大部分产品的最新版本中都有很大的改进。

    您说的备中心1/3机会不可用,是同步复制还是异步复制的情况?

    是指同步复制的情况。
    这个数字我不敢保证它的准确性,因为我没有做过实际的实验来验证,但从我在客户那里看到的实际情况来说,基本属实。

    您能告诉我你的客户用的那一家的产品吗?

    不管是同步环是异步只要不是在数据库里面做宕机时总应该有数据不一致的情况吧 因为数据库写文件是由操作系统来最终完成的,而操作系统本身又有cache,在通过逻辑复制把数据异步或同步复制到其他存储设备上,中间无论哪个环节有问题,远程存储设备的数据都不能同现有数据保持一致,所以我认为 biti的怀疑是很有道理的。到10g oracle可以使用assm,直接同存储设备对话,这样是否能够好一些,不太确定

    存储是通过快照来记录状态,然后再进行复制进行备份的。
    其实最好的方法应该是捕捉redo log file 的信息,将其翻译成sql语句

    这就是oracle stream 和quest shareplex实现的功能

    利用oracle 9i的高级复制,加上第三方的管理工具就可以了

    我对oracle 的高级复制研究较多,觉得这是最好的方法,能够完全保证数据的一致性。
    但管理起来比较麻烦,需要利用第三方的管理工具就可以了。我用的是 深圳华尔东城公司的管理工具,能够自动进行简单故障处理,目前设置的10分钟增量同步,最大表有4000多万条记录,目前还只同步了一部分表,数据量达到了50G。

    容灾实际例子,不知道是不是有帮助

    曾经评估了几个这方面的方案,一是利用存储本身提供的功能,在两端距离比较远(几百几千公里)的时候,只能用异步的方式,同步的话对网络的带宽要求很高,除非两端能够用光纤直接连接。异步的方式根据厂商的解释是这样的,远端存储上的写是无序的,不会根据生产端的次序写入,对用户来说是透明的,没有办法干预,也就是说对oracle来说是不同步的,如果没有人为的干预进行一次同步的话,数据库也没有办法启动。但是如果要同步的话就会对生产数据库产生影响,处于suspend状态。至于停电等各种极端情况我们在同城同步做过测试,没有问题,存储能够保证数据的一致和可用。异地异步没有测试过,不知有哪位兄弟做过这个试验,能告诉结果。

    看了大家的帖子,我也想说点东西,一直以来做的就是容灾和备份的事情。
    目前的所谓的容灾可能包含两种方式:
    1.真正的容灾,目的就是为了防止在灾难发生的时候能减少下线时间。这个过程没有一个能做到零下线的。
    2.”假“容灾,即所谓的ods,数据复制。出来的数据不单单能达到容灾的目的,而且目的端数据可以实时被使用。

    第一种方式可能是鸡肋,因为花那么大的投资使用当前的硬件容灾方式去达到一个可能领导在任期间都不能发生的灾难,实在让人觉得不太值得,除非厂商给了这个领导很大一笔钱,不过当前许多电信行业都说要建容灾中心。
    第二种方式确实是一种很诱人的方式,也是我现在做的产品。这种方式主要采用两种方式实现:
    a.使用我们现在的同步工作实现首次同步(逻辑上的导出,也是一种鬼才写出了这个东西,当然他是我们老总),然后直接转入监控online redolog进行日志监控分析转化,然后传送到目标端装载。
    b.使用类似于bcv/ca/flashcopy这些快照类软件在磁盘存储级做成首次同步,然后使用我现在的产品做日志监控,加载到目的端。

    这个产品作了1年多,应该说比quest的shareplex强大的多了,但是我并非在此宣传产品,所以我要说的是公平话。

    通过oracle内部方式去达到实时同步可能本身就是一个错误,类似于oracle本身的advance replication以及data guard也是日志分析方式的,他的主要缺点在于效率上存在问题,就是装载数据量很大的时候,根本不能应付,这也是shareplex的毛病。因此我现在的产品在这个上面是克服了这些缺点,效率绝对的高。我和oracle的stream,quest的shareplex,以及非用于容灾方式的data guard等对比过,大家互有长短。
    关键就是,采用基于这种精确分析的复制方式,如何保证数据是完全准确的:
    1.没有有效的检验方式,检查数据是否一致,有类似于select minus select的方式,但是对于超过100M的表,除非你有足够的耐心,我经常见到表最大是92G,没有分区,很变态。
    2.就算你知道了丢失数据,如何把这个数据补回来。现在的类似于我们的软件,都采用了rowidmap的方式去做精确定位,所以如果丢失了,你如何补回来。我知道quest 是重新同步,我们是把整个表重新同步,因为我们的逻辑到处快。
    这些都是基于oracle精确复制需要解决的最大的问题。

    呵呵,当然了关于这个里面处理很多oracle的特殊操作的时候还有很多需要做的事情,quest做了8年多了吧,到5年后才支持chained row,不能不说这是一个悲剧。还有许多的操作类型怎么办:ddl
    ,truncate,rollback savepoint,nologging等等,当然日志了没有的时候,你如何做。
    我个人的观点,基于oracle的精确分析复制方式,除了oracle以后能做好,其他人不要轻易尝试。

    不知道能否把产品名字透露一下啊?
    如果没有猜错应该是DSG的了?
    DGS和shareplex的比较让市场来说话吧。

    每个人都会说自己的产品好,但是希望在itpub这个地方
    还是要说出一些更多技术上的东西。

    samchj说“此我现在的产品在这个上面是克服了这些缺点,效率绝对的高”,并且也提到你们的产品也是通过监控redo的变化,提取SQL,那么为什么你们的效率会绝对的高?

    希望能从机制上说明一下这个问题。

    首先我澄清一下,我没有宣传产品的意思。

    我必须让事实说话,而不是市场说话,市场存在很多人为因素。

    在效率上,对于处理chained row这种在数据库中经常出现的东西,不能采用sql statment执行的方法。而shareplex是使用的这种方法。曾经我在测试的时候就对比过这个东西。因为chained row 包括migrate row &chain row 两种。而mr在oracle中只有一个rowid,而cr却不止。因此如果你采用的是rowmap方式精确定位两边的表,那么在处理chain row的时候,除非你能很好的处理,否则最简单和准确的方式就是直接在源端找到这个行,然后通过sql statment的方式装到目的端。这样在速度上是很慢的。

    效率的提高主要从分析速度和装载速度上讲的。
    我不知道shareplex日志分析是如何进行的,这当然也是这类型软件的kernel了,这是算法问题,我想起基本原理和logminer都差不多,在算法上优化分析速度是很重要的。

    在装载问题上,其实shareplex也曾经使用过direct path的装载方式,但是因为direct path本身就存在很多bug,因此干脆就放弃了这种方式,因为据我所接触的通过direct path装载的bug就很多,例如索引不能使用等。所以只能通过conventional path来装载。这就是规规矩矩的转换成sql statment,然后交给oracle通过解释成binary 后在装载
    了,这是很浪费时间的,而且对于qmi(基本由creat table as select引起的oracle特殊插入处理)来说,这是很不合理的,因此在这里应该做些事情,当然细节不便于说。

    另外对于首次同步的导出和装载,现在的oracle10g也许就是使用的这种方式了,你可以看看oracle10g的export为什么如此快。

    我还是说,不论是否市场怎么样,使用基于oracle精确分析装载的软件要慎重使用,因为他的问题是很多的。

    楼上的你们产品是什么啊

    关于这类产品的一些特别情况的处理我一直很关心

    另: 10G 使用的 *expdp* 和 *impdp* 应该是由 DUL + SQLLDR direct 思想的结合吧

    我们现在用的是Oracle 9i ,想用复制软件VERITAS Storage Replicator 3.0使两台服务器上的数据库同步,应该复制Oracle下的那些数据文件,表空间?还有复制后应该怎么做?

    服务器硬件说明:
    两台服务器为了节约成本,没有使用双机热备,没用磁盘阵列,每台服务器用4块SCSI硬盘做成Raid 5,两台服务器操作系统,数据库安装路径,设置都一致,有没有解决办法啊?

    使用SQL Server 2000数据库把数据文件复制到另外一台服务器,数据库可以实现同步,但是Oracle 9i把一台服务器上的表空间复制到另一台服务器后数据库不用能。

    对于samchj 一直说:然后通过sql statment的方式装到目的端。这样在速度上是很慢的,然后交给oracle通过解释成binary 后在装载了,这是很浪费时间的 ?
    ------------------------
    能否举出实际的例子?拿出具体的数据来说话, 你所谓的慢是什么程度?
    澄清一下,shareplex 不是使用你所谓的direct path 方式。

    dx6340老兄,我不是在宣传产品,我再澄清一次。如果有人对我现在做的产品感兴趣,可以给我写邮件,但是我们只谈技术,不谈市场,但是在itpub上或者任何其它场合,我不会说我的产品是如何的好,虽然我的和shareplex做的对比测试很多。他们各有各的优缺点。
    shareplex确实不使用direct path装载,这个我也说过“其实shareplex也曾经使用过direct path的装载方式”,我是说曾经,从研发上讲。你可以用shareplex或者oracle的data guard等做实验,当大数据量的时候,你可以看看他是否能分析过来和装载过来,延迟时间多少。一秒钟能支持的update有多少,insert有多少,如果做ddl是否需要先停止复制。这些还只是很基本的处理。logminer尚且对日志的分析很慢(不过可以用多进程来弥补,如果你有很多的系统资源)。

    wbo兄弟的“Oracle 9i把一台服务器上的表空间复制到另一台服务器后数据库不用能。”,我的理解是,如果你使用基于存储级的复制产品,你同步的应该是整个设置的卷或者卷组,他没有什么oracle的逻辑结构复制方法吧,要么就是把这个表空间创建在一个卷组上,然后设定复制这个卷组。如果你硬是要复制一个表空间过去,我觉得你应该先通过oracle的TRANSPORT_TABLESPACE来,但是好像很没有必要。使用存储级的复制不能实时打开,打开必须断开。

    对于基于复制中的特殊方式处理,主要有这些:
    1.采用何种装载方式
    2.如何准确快速执行delete和update,因为这两个操作需要rowid,有人采用在数据库本身创建很多的表来维护rowid。
    3.对chain row的处理
    4.对各种ddl的处理(truncate,create,drop,alter)
    5.对于未提交的事务的处理
    等等,因为我确实还没有来总结这些资料,这里先列各提纲,我一个一个来总结.

    1.装载方式:
    在oracle中装载数据库不外乎两种方式:direct path和conventinal path装载,其中类似direct path装载就是例如sqlload等工具使用的装载方式,因为它省去了sql语句的编译绑定(kk/kx),直接转换成绑定后的格式对extent进行操作.而conventinal path装载方式确实普通的装载方式,即类似于标准的sql语句的装载.后者比前者在同等条件下要慢5倍.当然两种方式的装载速度还和表本身的结构和大小有关.我测试的速度最大有12倍的差距.
    在装载上,你还要考虑更多内容,你不能单单调用oracle sqlloader,因为在oracle中有很多的oracle特殊处理的东西,例如:qmi,qmd.oracle在这里对于这些操作有在redo中有特殊的标志,如果你采用create table as select来创建表,你会觉得它比现创建然后用sql语句插入要快的多,在日志中他也只有很少的记录.因此,在处理这些的时候,你要采用特殊的算法,所以调用oracle的现成工具是不理想的,曾经在oracle7之前oracle并没有将upi (好像是这个名字)封掉,但是在oracle8i后,oracle不再开放该接口,因此很多的程序员对于这个层面了解很少.当然现在你很难找到.oci只是封装后更高级的接口而已.
    因此装载程序的设计,对于基于oracle精确分析方式的复制有很大的决定作用,这里面还有更多的处理,我也不能一一列出了.

    呵呵,楼上的这个工具就是你自己开发的吗?

    如果你老板能找到一个肯研究 OCI --&gt UPI ---&gtOPI 的手下 并一直坚持对oracle的研究,在国内简直是太不容易了。


    没其他意思,如果不是你开发的,除了对这一部分外,对oracle的整体问题你有过研究吗?

    呵呵,我不知道oracle的整体问题是什么意思,oracle太大了,我涉及的有关于oracle的备份恢复(包括非归档物理热备份,各种恢复方式,以及你们都已经在讨论的热备到底在做什么,那都是我很早前学的,反正备份的东西夸大点就是知道原理的东西多些,不过不敢在任何地方卖弄,因为技术这个东西很难说,嘻嘻)。
    搞我们这个容灾产品也有很久了,基本涉及的有联机日志分析,各种特殊操作的原理等等,不能详细罗列,但是在装载上说实话,我只是知道经过哪些层次,并没有开发,而是帮助开发作单元测试,所以知道比较详细些而已,知道对于我上面写的东西如何处理。同时对比过诸如:shareplex,stream,data guard等软件产品性能和基本的一些原理,也和存储级复制软件结合,做过组合测试而已。

    对于oracle的调优工作,我还是不如大家的,不过我看eygle老兄的东西都很接近我学的东西,因为确实我曾经站在了“巨人”的肩膀上,嘻嘻,还要向大家多学习,学习。

    要说深入oracle,也只是在看大家写的东西的同时,自己总结在这些年学习的东西,和大家分享,因为我觉得,我在网络上学了些,当然我也想将我学到的东西给大家分享,呵呵。

    明天继续对于这种产品存在的各种瓶颈作分析,也希望大家指正,我申明一点,我不做产品宣传,只是在我都测试过的基础上总结,绝不胡说

    其实也没什么,整体方面是说oracle的文件、内存、进程等比较全面的东西,
    对于 oracle internal 比较有兴趣一些,如 oracle 内存、文件管理、进程间通信

    宏观方面 备份恢复、tuning、体系结构 ,这些都是在前面internal基础上的具体应用,了解了internal后在管理方面就不局限于固定的模式了。

    比如喜欢这样的探讨:


    呵呵,当然,我关注的也是这些。

    我努力想成为一个像我们老板一样的高手,他能将这些东西转换成程序,呵呵。

    但是我不能把他拉到itpub上来,否则,中国的oracle研究者有福了。不过我愿意将我在他那里学的东西共享给大家,和大家一起研究。也请多指教。

    你们老板……当初是从哪里学来的呢

    因为如果原来不是oracle的人的话,我仅仅知道国外这样的人有一些,国内的同时精通oracle+os + 开发 的人,很罕见的 。我只是听闻国内有oracle的人出去做这类产品去了,但具体名字不清楚,不知道是不是你们老板。

    这个如果基于存储的复制方式是同步的,这是可以保证的.因为同步复制是复制IO,而且是主机端写IO的顺序技术复制的顺序,主要分成以下四步:主机端一个IO下来,存储复制到远端,然后远端完成IO,最后返回通知主机IO完成. 但是存储不保证数据库在此时逻辑上是一致的,这是靠数据库本身的机制来完成的. 即此时源端数据库崩溃,如果可以通过数据库相应恢复手段来恢复的话,远端复制的存储也可以.

    但如果是异步方式的话,问题就比较麻烦. 异步与同步的区别就是,异步主机IO下来后不需要等远端存储IO完成和确认,直接返回主机端IO完成. 这些IO暂时存放在源端存储缓存里,等累计到一定程度或满足给顶条件时,在传送到远端. 此时如何保证传递的IO顺序从而保证逻辑一致,就与具体的产品有比较大的关系了. 有的产品没有保证机制,直接用存放的顺序发送, 但在实际传送过程中没有保证,如由于线路等原因造成部分传送等. 有比较好的旧有时间戳和顺序号,而且还有逻辑分组,即主机端IO下来的时候是事务相关和逻辑分组的. 存储就将这一组IO逻辑分组,按写下的顺序标号, 这样在异步传送到远端后就可以根据逻辑分组和IO标号来完成IO. 类似具有事务的性质.

    同步如果是从主机下来的IO直接复制,这样频繁的小IO将造成网络的大量问题,这对网络的要求太高了。 以前都是听人说同步是从 存储的cache 来的,拷贝的时候封锁cache不允许写……

    我觉得这个和同步I/O和异步I/O没有关系,对于存储级的复制,他们都有一个队列来保证I/O的次序,这是类似于ca/emc等厂商的这些存储级(varitas文件系统级)复制的一个共同点。至少我知道veritas声称的原理是这样的。

    如果不能保证I/O的次序,存储级复制没有任何意义。而且像ca这样的软件,他并不是实时改变多少就穿多少,我觉得他记录在磁盘头的tab应该隔多少时间加一次锁,然后新的插入写cache,所以如果这个时间源端off的话,cache中的数据应该是丢失的(磁盘坏)。
    软件级的复制也一样,你总有一个队列来处理ops/rac的事务顺序,这个队列有放在磁盘上用文件来排队的,也有直接在内存中排队的,这些也是关键的东西。当然像软件复制这样的软件可以通过重新分析日志的方式来弥补,如果磁盘没有坏的话。

    同步绝对就是那样,每个在SOURCE端写入的东西必须被远端的存储设备写入成功(不一定是写入磁盘)才返回主机写入成功,基本可以认为就是一个距离很远的RAID1。一致性的问题不用担心,但是带宽要求等等都是很高的。
    异步的方法,在之前很多是不能保证一致的,呵呵。最近据说多了很多能保证一致的方法,就知道HDS会吧所有写记录到本地一个日志卷,EMC和IBM的方法还没有弄的很清楚。

    看看我们的实际应用

    现在介绍我们数据库同步的成功案例,你们提到的问题都可以解决。
    现在我们的数据同步已经投入了实际运行,采用逐步增加表的方式。目前已经同步了149个表,其中包括详单表,统计基表等。最大的6000多万记录,有16个超过1000万记录,采用10分钟异步复制。主要有以下特点:
    1、关键业务数据(排出了很多垃圾数据),数据量最小
    2、对生产机影响较小,目前一般只用到300M 空间
    3、目标端数据不可以修改,完全保证数据一致
    4、初始同步快捷、方便,不需要停止生产系统应用。影响小,只相当如一个select。
    5、管理方便、灵活:能够看到各表上次同步时间;上次同步后又有多少条新数据;上次各表同步耗费多长时间等。
    目前每天进行一次count(*) 检查,没有发现有问题。


    我们一前也试用过dsj和shareplex的产品,从名气上来说,应该还不错。具体不是我亲自试用的,但最后没有能够成功,我想与我们的系统复杂、数据库本身不是很稳定、要求太高有关。
    1、这是一个24小时运行的系统,停止应用程序来进行初始同步比较麻烦。
    2、需要在每天早晨从同步的数据中产生关键的数据和报表,要求不能耽误。
    3、要求管理维护简单、灵活:要求运行稳定,同步中断后能够简单快速处理完。

    现在我们用的oracle机制,加上第三方数据同步管理软件,只用了1个晚上就将主体数据同步好,一周就正式投入使用。然后逐步完善增加同步的表,目前已经同步了149张表,还对同步数据进行了分区处理等优化,从目前的近一个月的情况来看效果理想。
    经过一年半还多的时间试用了2家产品没有能够成功,用一周时间就解决了问题(主要报表实际上第二天就正式使用了),心里是多么的欣慰、兴奋和富有成就感。
    所以写了这么多东西。

    就是用了ORACLE物化视图技术+一个图形界面配置,还以为是啥东东哦。

    还有谁为建立报表机和容灾的数据同步而烦恼吗?

    oracle的功能确实很强大,这需要大家一起去挖掘,才会有基于oracle的更多更好的应用软件产生。

    samchj兄,你是DSG的吧?海龟从ORACLE,IBM出来,而且专攻容灾的公司,我想不出第二家。你们的技术很牛,对底层很清楚,但让人担心对ORACLE后续版本的支持。虽然所宣称的产品功能实现很吸引人,在测试中有不少问题,亟待完善。VP忙着改BUG,应该是没有什么时间来这灌水。

    关于BITI担心的存储同步问题,楼上的已经解释很清楚了。之所以存储厂商要求主节点、容灾节点更换成他们的存储设备,就是要解决I/O,CACHE的问题,从而保证同步端能够做到完全镜像。

    容灾端只有停掉同步,才能打开数据库,然后下一次再重做同步。而且他们还提供SNAPSHOT的功能,建立一个快照数据库,对于一个大数据库,需要的存储很可观。

    我个人认为,存储厂商的最大优势在于维护量少,有保障。DATA GUARD配置灵活,不依赖于底层,但需要人为监控。

    声明:我们这用的不是DATA GUARD

    是一个第三方软件,目前报表机同步底层用的是 实例化视图。
    如果建立应用级的容灾,数据需要实时同步,估计需要用到同步复制技术了。目前还没有下决心做,担心性能问题。目前有过1个表的初步测试,还没有进行大量表的测试。

    对你的ppt提几个疑问:
    1。传统同步软件方案为10年前的技术,比较落后。
    这个恐怕有些武断,相反对于数据库的复制我个人更看好如Quest的shareplex等产品。同样dataguard也使用类似技术,绝对不是如你所言是10年前的落后技术。

    2。传统同步软件方案,因其本身的缺陷,导致需要大量复杂的机制和操作来保证数据的一致,实施成本大。
    复杂的机制不是最终客户需要考虑的,相反这些软件的实施成本是相应较小的(当然如果你的成本是指money的话,那自然是比物化视图高,不过仍然可以选用DG),说起复杂的机制,即使是你使用的物化视图,也仍然有大量内部的控制是较复杂的,不过这些不需要实施者去考虑而已。

    3。采用硬件存储快照的方式,同步方式不灵活,将生产系统上所有的数据全部同步。(经过长时间运行和维护的生产系统往往大量的临时表和大量的垃圾数据,这些实际上是不需要同步的。
    通常基于存储的复制提供了卷一级的管理,完全可以通过配置不同的数据文件在不同的卷上来达到复制关键数据的目的。

    4。采用硬件存储快照的方式,耗费大量的存储设备,成本巨大。
    就我所知,至少veritas的vvr不需要太多额外的存储。

    5。华尔东城公司采用的独特方案,采用oracle的各种技术相结合,结合本公司独特的同步参数设置。通过本公司软件控制进行同步的管理。
    其实你这个ppt真是说的很含糊,用于单纯的sales宣传恐怕还可以,如果是用于技术交流实在是有些不痛不痒。

    6。华尔东城产品重要的益处,保证容灾数据完全一致,报表数据与10分钟前一致 。
    既然有10分钟的差距,为何仍然说容灾数据完全一致?如果说你们使用了物化视图的方案,那么就不可能在一个刷新期内(你们这儿的10分钟?)保证数据不丢失。除非还有业务log的分析软件作后备。

    7。华尔东城产品重要的益处,对主机性能影响小。
    其实物化视图的刷新对于主机并不是很小的影响,如果10分钟之内需要刷新大量的数据,可以明显的看到CPU的波峰,特别是oracle本身对于mvlog的处理还是有些问题的,所以不确定你们是否真的作过跟其它专业同步软件的主机性能影响的比较。

    8。本公司得益于oracle新技术的推出,加上本公司的努力,终于能够为数据同步提供完美的方案,这也是我们值得骄傲的一件事情。
    不否认你们确实作出了一个比较完备的同步解决方案,但是希望能够本着技术交流的想法在itpub讨论问题,而不是作单纯的商业宣传。我想很多人都希望知道你所指的oracle新技术是什么?不应该说就是物化视图吧。

     

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

    转载于:http://blog.itpub.net/34329/viewspace-911085/

    展开全文
  • 数据库容灾复制解决方案全分析http://www.tianyar.net/blog/user1/10202/archives/2006/8967.shtml最近发现论坛上关于数据库远程复制和异地容灾等问题的帖子比较多,现在把我...
    数据库容灾、复制解决方案全分析 http://www.tianyar.net/blog/user1/10202/archives/2006/8967.shtml

    最近发现论坛上关于数据库远程复制和异地容灾等问题的帖子比较多,现在把我知道的一些解决方案进行一下分析,能力有限,还希望大家多多补充、纠正!

    目前,针对oracle数据库的远程复制、容灾主要有以下几种技术或解决方案:
    (1)基于存储层的容灾复制方案
    这种技术的复制机制是通过基于SAN的存储局域网进行复制,复制针对每个IO进行,复制的数据量比较大;系统可以实现数据的同步或异步两种方式的复制.对大数据量的系统来说有很大的优势(每天日志量在60G以上),但是对主机、操作系统、数据库版本等要求一致,且对络环境的要求比较高。
    目标系统不需要有主机,只要有存储设备就可以,如果需要目标系统可读,需要额外的配置和设备,比较麻烦。

    (2)基于逻辑卷的容灾复制方案

    这种技术的机制是通过基于TCP/IP的网络环境进行复制,由操作系统进程捕捉逻辑卷的变化进行复制。其特点与基于存储设备的复制方案比较类似,也可以选择同步或异步两种方式,对主机的软、硬件环境的一致性要求也比较高,对大数据量的应用比较有优势。其目标系统如果要实现可读,需要创建第三方镜像。个人认为这种技术和上面提到的基于存储的复制技术比较适合于超大数据量的系统,或者是应用系统的容灾复制。

    我一直有一个困惑,存储级的 复制,假如是同步的,能保证 数据库所有文件一致吗 ?或者说是保证在 异常发生的那一刻有足够的缓冲来保障?

    也就是说,复制的时候起文件写入顺序和oracle的顺序一致吗?如果不一致就可能有问题,那么是通过什么机制来实现的呢?


    上次一个存储厂商来讲产品,我问技术工程师这个问题,没有能给出答案

    我对存储级的复制没有深入的研究过,主要是我自己的一些理解,你们帮我看一下吧……
    我觉得基于存储的复制应该是捕捉原系统存储上的每一个变化,而不是每隔一段时间去复制一下原系统存储上文件内容的改变结果,所以在任意时刻,如果原系统的文件是一致的,那么目标端也应该是一致的,如果原系统没有一致,那目标端也会一样的。形象一点说它的原理可能有点像raid 0,就是说它的写入顺序应该和原系统是一样的。不知道我的理解对不对。另外,在发生故障的那一刻,如果是类似断电的情况,那么肯定会有缓存中数据的损失,也不能100%保证数据文件的一致。一般来说是用这种方式做oracle的容灾备份,在发生灾难以后目标系统的数据库一般是只有2/3的机会是可以正常启动的(这是我接触过的很多这方面的技术人员的一种说法,我没有实际测试过)。我在一个移动运营商那里看到过实际的情况,他们的数据库没有归档,虽然使用了存储级的备份,但是白天却是不做同步的,只有在晚上再将存储同步,到第二天早上,再把存储的同步断掉,然后由另外一台主机来启动目标端存储上的数据库,而且基本上是有1/3的机会目标端数据库是起不来的,需要重新同步。

    所以我觉得如果不是数据量大的惊人,其他方式没办法做到同步,或者要同时对数据库和应用进行容灾,存储级的方案是没有什么优势的,尤其是它对网络的环境要求是非常高的,在异地环境中几乎不可能实现。

    不知道我的理解对不对,也不知道是不是回答了你的问题,呵呵。欢迎指正!

    应该说部分地回答了我的问题,呵呵

    因为 实际上存储设备的写入顺序 和 oracle 的进程的写入顺序肯定是不一样的,存储设备一定是做过重整的,那 不管同步或者异步的拷贝都 有可能 存在问题的。

    所以我一直对这个方案的可靠性不敢完全相信,这样一来,倒不如 data guard 可靠了


    因为很明显,存储设备拷贝过去的数据文件 不一致是有很大的概率的

    你的意思是说即使不考虑目标端,仅在源端的情况下,存储设备的写入顺序也是和Oracle不一致的?这应该是一个原因。我觉得还有一种可能性就是在忽略存储设备的这种情况下,在主系统当机,发生切换的时候,主系统存储上的数据文件也不一定能保证一致,就算目标系统保持了完全的同步,也一样不能保正目标端数据可可以启动。

    不太理解,为什么说存储设备的写入顺序会和oracle进程的写入顺序不一致阿
    如果说仅在源端情况下,存储设备的写入顺序也是和Oracle进程不一致,那么不考虑异地冗灾,那么是不是意味着即使本地服务器crash,也无法启动存储上的数据文件?

    我也有这个疑问,以前一直觉得仅考虑主系统的情况下,存储设备的写入顺序应该是和数据库的写入顺序一致的, 但我觉得biti_rainy的理解也是有道理的,存储设备毕竟和一般的磁盘不一样,很可能再写入的时候会作重新的组合,不过不知道具体的证据是什么啊?
    按照这种理解,再写入的某一瞬间,数据库的写入顺序和存储的写入顺序可能是不一致的,但既然存储写入的结果跟oracle的写入结果肯定是一致的,那么我们可以把一个比较长的写入过程分成若干个时间段,在每个时间段的结尾,oracle和存储设备的写入结果都是完全一致的,那么这个时间段的大小是多少呢?
    呵呵,说得我自己都快晕了,也不知道大家明白我的意思没有……
    o
    biti_rainy能不能给我们解释一下啊?或者论坛里有没有对存储设备比较了解的兄弟啊?

    系统上通常不一致没关系是因为还有 logfile 的存在,而日志文件通常是被写入了磁盘的,oracle本身是顺序写的,还不需要读,应该是被重整的几率比较小

    还有存储设备上,比如掉电没关系,是因为存储设备都有足够的短时间供电能力使得 cache 中的数据能被写入磁盘,这个如果不能保证那一掉电基本都要出问题的


    但是在复制的那端,我就不清楚是怎么处理的,比如我要停掉复制,开始用起这数据来,或者说设备掉电了,这个时候是怎么处理的


    在复制的那端,我感觉是没有经过特殊处理的,因为存储设备完全是物理上的同步,在你停掉复制的时候,他最多只能保证在停止复制或原系统掉电的这一刻所有文件在物理上是和原系统的存储是完全一致的,但他绝对不会去校验或保证oracle的数据文件在逻辑上是否一致,所以会造成复制端在停止复制后有很大几率不能正常启动。我在客户那的情况就是在原系统正常运行的情况下,停止存储的复制,然后启动目标端数据库,但还是有1/3的几率无法启动,如果是在原系统发生故障或断电的情况下,估计就更不好说了。
    我还是比较佩服那个客户的勇气,一个省级移动运营商的数据中心,数据库连归档都没有,一旦系统崩溃,至少要损失当天的数据,同时容灾端的数据库能不能起来还是个问题……
    还好目前还没有出问题,要是出了问题,不知道他们会怎么办……

    上次做存储设备的来公司,谈到这个问题的时候说: 很多客户就是这么做的

    我就说: 很多人这么做的并不能说就没问题,因为很多 人没有出现事故,是因为隐藏的问题没有机会暴露出来。我需要:
    1:机制上的可靠保障,这个可能只有非常理解 原理的人能回答
    2:实际系统的测试,要经过在我们自己提供的数据场景下反复测试

    通过这两点之后我们才敢放心使用


    同意,确实很多人都是这么用的,也确实都很可能出现问题,所以我一直以为基于存储的数据库容灾方案是有问题的,但在有些环境中好像还只能这么做,例如我们的一个客户,也是一个省级的移动运营商,其数据库每天的日志量达到100G以上,在这种条件下,好像只有这种解决方案比较可行,其他的都会有一些问题,至少那些使用软件实现的逻辑复制方案是不行的,我感觉oracle自己的standby好像也负担不了吧?不过他们的数据库至少还是归档的,还有一点保证。呵呵。

    从ORACLE的角度来衡量基于存储的容灾肯定是有问题的,不可能做到100%可用。

    即使是ORACLE的DATA GUARD也不能保证100%没有数据丢失(当前日志组的数据)。

    换个思路了,使用基于应用的同步方案吧。


    (3)基于oracle redo log的逻辑复制方式
    使用这种方式的主要有一些第三方的软件,以及oracle自己的DATAGUARD 中的logical Standby。先介绍一下第三方的软件产品吧……

    目前,国外已经有了很多比较成熟的产品及成功案例,国内也有类似的产品, 但在产品的成熟程度和成功案例上跟国外还有一定的差距。
    这类产品的原理基本相同,其工作过程可以分为以下几个流程:
    使用oracle以外的独立进程,捕捉redo log file 的信息,将其翻译成sql语句,再通过网络传输到目标端数据库,在目标端数据库执行同样的sql。如果其进程赶不上oracle日志切换,也可以捕捉归档日志中的内容。也有的产品在源端以事务为单位,当一个事务完成后,再把它传输到目标端。所有的产品一般都是以表为单位进行复制,同时也支持大部分DDL的复制(主要在oracle9i环境中)。
    这种技术的技术特点和优势主要有以下几点:
    目标端数据库一直是一个可以访问的数据库;
    能保证两端数据库的事务一致性;
    因为使用oracle以外的进程进行捕捉,且其优先级低于oracle进程,所以对源系统数据库的性能影响很小;
    基于其实现原理及多个队列文件的使用,复制环境可以提供网络失败、数据库失败、主机失败的容错能力;
    因为这类软件复制的只是sql语句或事务,所以他可以完全支持异构环境的复制,硬件的型号,oracle的版本,操作系统的种类、版本等都没有要求。
    这种方式还可以支持多种复制方式,比如数据集中、分发、对等复制、或者多层测的复制等。
    由于传输的内容只是redolog 或archive log中的一部分,所以对网络资源的占用很小,可以实现不同城市之间的远程复制。

    基于redolog的逻辑复制产品有很多的优势,但跟上面提到过的其他方案比较起来,也有一些缺点:
    数据库的吞吐量太大时,其实据会有较大的延迟,当数据库每天的日量达到60G或更大时,这种方案的可行性交差;
    实施的过程可能会有一些停机时间,来进行数据的同步和配置的激活;
    复制环境建立起来以后,对数据库结构上的一些修改需要按照规定的操作流程进行,有一定的维护成本。
    不过目前这类产品的发展很快,上面的这些问题,在大部分产品的最新版本中都有很大的改进。

    您说的备中心1/3机会不可用,是同步复制还是异步复制的情况?

    是指同步复制的情况。
    这个数字我不敢保证它的准确性,因为我没有做过实际的实验来验证,但从我在客户那里看到的实际情况来说,基本属实。

    您能告诉我你的客户用的那一家的产品吗?

    不管是同步环是异步只要不是在数据库里面做宕机时总应该有数据不一致的情况吧 因为数据库写文件是由操作系统来最终完成的,而操作系统本身又有cache,在通过逻辑复制把数据异步或同步复制到其他存储设备上,中间无论哪个环节有问题,远程存储设备的数据都不能同现有数据保持一致,所以我认为 biti的怀疑是很有道理的。到10g oracle可以使用assm,直接同存储设备对话,这样是否能够好一些,不太确定

    存储是通过快照来记录状态,然后再进行复制进行备份的。
    其实最好的方法应该是捕捉redo log file 的信息,将其翻译成sql语句

    这就是oracle stream 和quest shareplex实现的功能

    利用oracle 9i的高级复制,加上第三方的管理工具就可以了

    我对oracle 的高级复制研究较多,觉得这是最好的方法,能够完全保证数据的一致性。
    但管理起来比较麻烦,需要利用第三方的管理工具就可以了。我用的是 深圳华尔东城公司的管理工具,能够自动进行简单故障处理,目前设置的10分钟增量同步,最大表有4000多万条记录,目前还只同步了一部分表,数据量达到了50G。

    容灾实际例子,不知道是不是有帮助

    曾经评估了几个这方面的方案,一是利用存储本身提供的功能,在两端距离比较远(几百几千公里)的时候,只能用异步的方式,同步的话对网络的带宽要求很高,除非两端能够用光纤直接连接。异步的方式根据厂商的解释是这样的,远端存储上的写是无序的,不会根据生产端的次序写入,对用户来说是透明的,没有办法干预,也就是说对oracle来说是不同步的,如果没有人为的干预进行一次同步的话,数据库也没有办法启动。但是如果要同步的话就会对生产数据库产生影响,处于suspend状态。至于停电等各种极端情况我们在同城同步做过测试,没有问题,存储能够保证数据的一致和可用。异地异步没有测试过,不知有哪位兄弟做过这个试验,能告诉结果。

    看了大家的帖子,我也想说点东西,一直以来做的就是容灾和备份的事情。
    目前的所谓的容灾可能包含两种方式:
    1.真正的容灾,目的就是为了防止在灾难发生的时候能减少下线时间。这个过程没有一个能做到零下线的。
    2.”假“容灾,即所谓的ods,数据复制。出来的数据不单单能达到容灾的目的,而且目的端数据可以实时被使用。

    第一种方式可能是鸡肋,因为花那么大的投资使用当前的硬件容灾方式去达到一个可能领导在任期间都不能发生的灾难,实在让人觉得不太值得,除非厂商给了这个领导很大一笔钱,不过当前许多电信行业都说要建容灾中心。
    第二种方式确实是一种很诱人的方式,也是我现在做的产品。这种方式主要采用两种方式实现:
    a.使用我们现在的同步工作实现首次同步(逻辑上的导出,也是一种鬼才写出了这个东西,当然他是我们老总),然后直接转入监控online redolog进行日志监控分析转化,然后传送到目标端装载。
    b.使用类似于bcv/ca/flashcopy这些快照类软件在磁盘存储级做成首次同步,然后使用我现在的产品做日志监控,加载到目的端。

    这个产品作了1年多,应该说比quest的shareplex强大的多了,但是我并非在此宣传产品,所以我要说的是公平话。

    通过oracle内部方式去达到实时同步可能本身就是一个错误,类似于oracle本身的advance replication以及data guard也是日志分析方式的,他的主要缺点在于效率上存在问题,就是装载数据量很大的时候,根本不能应付,这也是shareplex的毛病。因此我现在的产品在这个上面是克服了这些缺点,效率绝对的高。我和oracle的stream,quest的shareplex,以及非用于容灾方式的data guard等对比过,大家互有长短。
    关键就是,采用基于这种精确分析的复制方式,如何保证数据是完全准确的:
    1.没有有效的检验方式,检查数据是否一致,有类似于select minus select的方式,但是对于超过100M的表,除非你有足够的耐心,我经常见到表最大是92G,没有分区,很变态。
    2.就算你知道了丢失数据,如何把这个数据补回来。现在的类似于我们的软件,都采用了rowidmap的方式去做精确定位,所以如果丢失了,你如何补回来。我知道quest 是重新同步,我们是把整个表重新同步,因为我们的逻辑到处快。
    这些都是基于oracle精确复制需要解决的最大的问题。

    呵呵,当然了关于这个里面处理很多oracle的特殊操作的时候还有很多需要做的事情,quest做了8年多了吧,到5年后才支持chained row,不能不说这是一个悲剧。还有许多的操作类型怎么办:ddl
    ,truncate,rollback savepoint,nologging等等,当然日志了没有的时候,你如何做。
    我个人的观点,基于oracle的精确分析复制方式,除了oracle以后能做好,其他人不要轻易尝试。

    不知道能否把产品名字透露一下啊?
    如果没有猜错应该是DSG的了?
    DGS和shareplex的比较让市场来说话吧。

    每个人都会说自己的产品好,但是希望在itpub这个地方
    还是要说出一些更多技术上的东西。

    samchj说“此我现在的产品在这个上面是克服了这些缺点,效率绝对的高”,并且也提到你们的产品也是通过监控redo的变化,提取SQL,那么为什么你们的效率会绝对的高?

    希望能从机制上说明一下这个问题。

    首先我澄清一下,我没有宣传产品的意思。

    我必须让事实说话,而不是市场说话,市场存在很多人为因素。

    在效率上,对于处理chained row这种在数据库中经常出现的东西,不能采用sql statment执行的方法。而shareplex是使用的这种方法。曾经我在测试的时候就对比过这个东西。因为chained row 包括migrate row &chain row 两种。而mr在oracle中只有一个rowid,而cr却不止。因此如果你采用的是rowmap方式精确定位两边的表,那么在处理chain row的时候,除非你能很好的处理,否则最简单和准确的方式就是直接在源端找到这个行,然后通过sql statment的方式装到目的端。这样在速度上是很慢的。

    效率的提高主要从分析速度和装载速度上讲的。
    我不知道shareplex日志分析是如何进行的,这当然也是这类型软件的kernel了,这是算法问题,我想起基本原理和logminer都差不多,在算法上优化分析速度是很重要的。

    在装载问题上,其实shareplex也曾经使用过direct path的装载方式,但是因为direct path本身就存在很多bug,因此干脆就放弃了这种方式,因为据我所接触的通过direct path装载的bug就很多,例如索引不能使用等。所以只能通过conventional path来装载。这就是规规矩矩的转换成sql statment,然后交给oracle通过解释成binary 后在装载
    了,这是很浪费时间的,而且对于qmi(基本由creat table as select引起的oracle特殊插入处理)来说,这是很不合理的,因此在这里应该做些事情,当然细节不便于说。

    另外对于首次同步的导出和装载,现在的oracle10g也许就是使用的这种方式了,你可以看看oracle10g的export为什么如此快。

    我还是说,不论是否市场怎么样,使用基于oracle精确分析装载的软件要慎重使用,因为他的问题是很多的。

    楼上的你们产品是什么啊

    关于这类产品的一些特别情况的处理我一直很关心

    另: 10G 使用的 *expdp* 和 *impdp* 应该是由 DUL + SQLLDR direct 思想的结合吧

    我们现在用的是Oracle 9i ,想用复制软件VERITAS Storage Replicator 3.0使两台服务器上的数据库同步,应该复制Oracle下的那些数据文件,表空间?还有复制后应该怎么做?

    服务器硬件说明:
    两台服务器为了节约成本,没有使用双机热备,没用磁盘阵列,每台服务器用4块SCSI硬盘做成Raid 5,两台服务器操作系统,数据库安装路径,设置都一致,有没有解决办法啊?

    使用SQL Server 2000数据库把数据文件复制到另外一台服务器,数据库可以实现同步,但是Oracle 9i把一台服务器上的表空间复制到另一台服务器后数据库不用能。

    对于samchj 一直说:然后通过sql statment的方式装到目的端。这样在速度上是很慢的,然后交给oracle通过解释成binary 后在装载了,这是很浪费时间的 ?
    ------------------------
    能否举出实际的例子?拿出具体的数据来说话, 你所谓的慢是什么程度?
    澄清一下,shareplex 不是使用你所谓的direct path 方式。

    dx6340老兄,我不是在宣传产品,我再澄清一次。如果有人对我现在做的产品感兴趣,可以给我写邮件,但是我们只谈技术,不谈市场,但是在itpub上或者任何其它场合,我不会说我的产品是如何的好,虽然我的和shareplex做的对比测试很多。他们各有各的优缺点。
    shareplex确实不使用direct path装载,这个我也说过“其实shareplex也曾经使用过direct path的装载方式”,我是说曾经,从研发上讲。你可以用shareplex或者oracle的data guard等做实验,当大数据量的时候,你可以看看他是否能分析过来和装载过来,延迟时间多少。一秒钟能支持的update有多少,insert有多少,如果做ddl是否需要先停止复制。这些还只是很基本的处理。logminer尚且对日志的分析很慢(不过可以用多进程来弥补,如果你有很多的系统资源)。

    wbo兄弟的“Oracle 9i把一台服务器上的表空间复制到另一台服务器后数据库不用能。”,我的理解是,如果你使用基于存储级的复制产品,你同步的应该是整个设置的卷或者卷组,他没有什么oracle的逻辑结构复制方法吧,要么就是把这个表空间创建在一个卷组上,然后设定复制这个卷组。如果你硬是要复制一个表空间过去,我觉得你应该先通过oracle的TRANSPORT_TABLESPACE来,但是好像很没有必要。使用存储级的复制不能实时打开,打开必须断开。

    对于基于复制中的特殊方式处理,主要有这些:
    1.采用何种装载方式
    2.如何准确快速执行delete和update,因为这两个操作需要rowid,有人采用在数据库本身创建很多的表来维护rowid。
    3.对chain row的处理
    4.对各种ddl的处理(truncate,create,drop,alter)
    5.对于未提交的事务的处理
    等等,因为我确实还没有来总结这些资料,这里先列各提纲,我一个一个来总结.

    1.装载方式:
    在oracle中装载数据库不外乎两种方式:direct path和conventinal path装载,其中类似direct path装载就是例如sqlload等工具使用的装载方式,因为它省去了sql语句的编译绑定(kk/kx),直接转换成绑定后的格式对extent进行操作.而conventinal path装载方式确实普通的装载方式,即类似于标准的sql语句的装载.后者比前者在同等条件下要慢5倍.当然两种方式的装载速度还和表本身的结构和大小有关.我测试的速度最大有12倍的差距.
    在装载上,你还要考虑更多内容,你不能单单调用oracle sqlloader,因为在oracle中有很多的oracle特殊处理的东西,例如:qmi,qmd.oracle在这里对于这些操作有在redo中有特殊的标志,如果你采用create table as select来创建表,你会觉得它比现创建然后用sql语句插入要快的多,在日志中他也只有很少的记录.因此,在处理这些的时候,你要采用特殊的算法,所以调用oracle的现成工具是不理想的,曾经在oracle7之前oracle并没有将upi (好像是这个名字)封掉,但是在oracle8i后,oracle不再开放该接口,因此很多的程序员对于这个层面了解很少.当然现在你很难找到.oci只是封装后更高级的接口而已.
    因此装载程序的设计,对于基于oracle精确分析方式的复制有很大的决定作用,这里面还有更多的处理,我也不能一一列出了.

    呵呵,楼上的这个工具就是你自己开发的吗?

    如果你老板能找到一个肯研究 OCI --&gt UPI ---&gtOPI 的手下 并一直坚持对oracle的研究,在国内简直是太不容易了。


    没其他意思,如果不是你开发的,除了对这一部分外,对oracle的整体问题你有过研究吗?

    呵呵,我不知道oracle的整体问题是什么意思,oracle太大了,我涉及的有关于oracle的备份恢复(包括非归档物理热备份,各种恢复方式,以及你们都已经在讨论的热备到底在做什么,那都是我很早前学的,反正备份的东西夸大点就是知道原理的东西多些,不过不敢在任何地方卖弄,因为技术这个东西很难说,嘻嘻)。
    搞我们这个容灾产品也有很久了,基本涉及的有联机日志分析,各种特殊操作的原理等等,不能详细罗列,但是在装载上说实话,我只是知道经过哪些层次,并没有开发,而是帮助开发作单元测试,所以知道比较详细些而已,知道对于我上面写的东西如何处理。同时对比过诸如:shareplex,stream,data guard等软件产品性能和基本的一些原理,也和存储级复制软件结合,做过组合测试而已。

    对于oracle的调优工作,我还是不如大家的,不过我看eygle老兄的东西都很接近我学的东西,因为确实我曾经站在了“巨人”的肩膀上,嘻嘻,还要向大家多学习,学习。

    要说深入oracle,也只是在看大家写的东西的同时,自己总结在这些年学习的东西,和大家分享,因为我觉得,我在网络上学了些,当然我也想将我学到的东西给大家分享,呵呵。

    明天继续对于这种产品存在的各种瓶颈作分析,也希望大家指正,我申明一点,我不做产品宣传,只是在我都测试过的基础上总结,绝不胡说

    其实也没什么,整体方面是说oracle的文件、内存、进程等比较全面的东西,
    对于 oracle internal 比较有兴趣一些,如 oracle 内存、文件管理、进程间通信

    宏观方面 备份恢复、tuning、体系结构 ,这些都是在前面internal基础上的具体应用,了解了internal后在管理方面就不局限于固定的模式了。

    比如喜欢这样的探讨:


    呵呵,当然,我关注的也是这些。

    我努力想成为一个像我们老板一样的高手,他能将这些东西转换成程序,呵呵。

    但是我不能把他拉到itpub上来,否则,中国的oracle研究者有福了。不过我愿意将我在他那里学的东西共享给大家,和大家一起研究。也请多指教。

    你们老板……当初是从哪里学来的呢

    因为如果原来不是oracle的人的话,我仅仅知道国外这样的人有一些,国内的同时精通oracle+os + 开发 的人,很罕见的 。我只是听闻国内有oracle的人出去做这类产品去了,但具体名字不清楚,不知道是不是你们老板。

    这个如果基于存储的复制方式是同步的,这是可以保证的.因为同步复制是复制IO,而且是主机端写IO的顺序技术复制的顺序,主要分成以下四步:主机端一个IO下来,存储复制到远端,然后远端完成IO,最后返回通知主机IO完成. 但是存储不保证数据库在此时逻辑上是一致的,这是靠数据库本身的机制来完成的. 即此时源端数据库崩溃,如果可以通过数据库相应恢复手段来恢复的话,远端复制的存储也可以.

    但如果是异步方式的话,问题就比较麻烦. 异步与同步的区别就是,异步主机IO下来后不需要等远端存储IO完成和确认,直接返回主机端IO完成. 这些IO暂时存放在源端存储缓存里,等累计到一定程度或满足给顶条件时,在传送到远端. 此时如何保证传递的IO顺序从而保证逻辑一致,就与具体的产品有比较大的关系了. 有的产品没有保证机制,直接用存放的顺序发送, 但在实际传送过程中没有保证,如由于线路等原因造成部分传送等. 有比较好的旧有时间戳和顺序号,而且还有逻辑分组,即主机端IO下来的时候是事务相关和逻辑分组的. 存储就将这一组IO逻辑分组,按写下的顺序标号, 这样在异步传送到远端后就可以根据逻辑分组和IO标号来完成IO. 类似具有事务的性质.

    同步如果是从主机下来的IO直接复制,这样频繁的小IO将造成网络的大量问题,这对网络的要求太高了。 以前都是听人说同步是从 存储的cache 来的,拷贝的时候封锁cache不允许写……

    我觉得这个和同步I/O和异步I/O没有关系,对于存储级的复制,他们都有一个队列来保证I/O的次序,这是类似于ca/emc等厂商的这些存储级(varitas文件系统级)复制的一个共同点。至少我知道veritas声称的原理是这样的。

    如果不能保证I/O的次序,存储级复制没有任何意义。而且像ca这样的软件,他并不是实时改变多少就穿多少,我觉得他记录在磁盘头的tab应该隔多少时间加一次锁,然后新的插入写cache,所以如果这个时间源端off的话,cache中的数据应该是丢失的(磁盘坏)。
    软件级的复制也一样,你总有一个队列来处理ops/rac的事务顺序,这个队列有放在磁盘上用文件来排队的,也有直接在内存中排队的,这些也是关键的东西。当然像软件复制这样的软件可以通过重新分析日志的方式来弥补,如果磁盘没有坏的话。

    同步绝对就是那样,每个在SOURCE端写入的东西必须被远端的存储设备写入成功(不一定是写入磁盘)才返回主机写入成功,基本可以认为就是一个距离很远的RAID1。一致性的问题不用担心,但是带宽要求等等都是很高的。
    异步的方法,在之前很多是不能保证一致的,呵呵。最近据说多了很多能保证一致的方法,就知道HDS会吧所有写记录到本地一个日志卷,EMC和IBM的方法还没有弄的很清楚。

    看看我们的实际应用

    现在介绍我们数据库同步的成功案例,你们提到的问题都可以解决。
    现在我们的数据同步已经投入了实际运行,采用逐步增加表的方式。目前已经同步了149个表,其中包括详单表,统计基表等。最大的6000多万记录,有16个超过1000万记录,采用10分钟异步复制。主要有以下特点:
    1、关键业务数据(排出了很多垃圾数据),数据量最小
    2、对生产机影响较小,目前一般只用到300M 空间
    3、目标端数据不可以修改,完全保证数据一致
    4、初始同步快捷、方便,不需要停止生产系统应用。影响小,只相当如一个select。
    5、管理方便、灵活:能够看到各表上次同步时间;上次同步后又有多少条新数据;上次各表同步耗费多长时间等。
    目前每天进行一次count(*) 检查,没有发现有问题。


    我们一前也试用过dsj和shareplex的产品,从名气上来说,应该还不错。具体不是我亲自试用的,但最后没有能够成功,我想与我们的系统复杂、数据库本身不是很稳定、要求太高有关。
    1、这是一个24小时运行的系统,停止应用程序来进行初始同步比较麻烦。
    2、需要在每天早晨从同步的数据中产生关键的数据和报表,要求不能耽误。
    3、要求管理维护简单、灵活:要求运行稳定,同步中断后能够简单快速处理完。

    现在我们用的oracle机制,加上第三方数据同步管理软件,只用了1个晚上就将主体数据同步好,一周就正式投入使用。然后逐步完善增加同步的表,目前已经同步了149张表,还对同步数据进行了分区处理等优化,从目前的近一个月的情况来看效果理想。
    经过一年半还多的时间试用了2家产品没有能够成功,用一周时间就解决了问题(主要报表实际上第二天就正式使用了),心里是多么的欣慰、兴奋和富有成就感。
    所以写了这么多东西。

    就是用了ORACLE物化视图技术+一个图形界面配置,还以为是啥东东哦。

    还有谁为建立报表机和容灾的数据同步而烦恼吗?

    oracle的功能确实很强大,这需要大家一起去挖掘,才会有基于oracle的更多更好的应用软件产生。

    samchj兄,你是DSG的吧?海龟从ORACLE,IBM出来,而且专攻容灾的公司,我想不出第二家。你们的技术很牛,对底层很清楚,但让人担心对ORACLE后续版本的支持。虽然所宣称的产品功能实现很吸引人,在测试中有不少问题,亟待完善。VP忙着改BUG,应该是没有什么时间来这灌水。

    关于BITI担心的存储同步问题,楼上的已经解释很清楚了。之所以存储厂商要求主节点、容灾节点更换成他们的存储设备,就是要解决I/O,CACHE的问题,从而保证同步端能够做到完全镜像。

    容灾端只有停掉同步,才能打开数据库,然后下一次再重做同步。而且他们还提供SNAPSHOT的功能,建立一个快照数据库,对于一个大数据库,需要的存储很可观。

    我个人认为,存储厂商的最大优势在于维护量少,有保障。DATA GUARD配置灵活,不依赖于底层,但需要人为监控。

    声明:我们这用的不是DATA GUARD

    是一个第三方软件,目前报表机同步底层用的是 实例化视图。
    如果建立应用级的容灾,数据需要实时同步,估计需要用到同步复制技术了。目前还没有下决心做,担心性能问题。目前有过1个表的初步测试,还没有进行大量表的测试。

    对你的ppt提几个疑问:
    1。传统同步软件方案为10年前的技术,比较落后。
    这个恐怕有些武断,相反对于数据库的复制我个人更看好如Quest的shareplex等产品。同样dataguard也使用类似技术,绝对不是如你所言是10年前的落后技术。

    2。传统同步软件方案,因其本身的缺陷,导致需要大量复杂的机制和操作来保证数据的一致,实施成本大。
    复杂的机制不是最终客户需要考虑的,相反这些软件的实施成本是相应较小的(当然如果你的成本是指money的话,那自然是比物化视图高,不过仍然可以选用DG),说起复杂的机制,即使是你使用的物化视图,也仍然有大量内部的控制是较复杂的,不过这些不需要实施者去考虑而已。

    3。采用硬件存储快照的方式,同步方式不灵活,将生产系统上所有的数据全部同步。(经过长时间运行和维护的生产系统往往大量的临时表和大量的垃圾数据,这些实际上是不需要同步的。
    通常基于存储的复制提供了卷一级的管理,完全可以通过配置不同的数据文件在不同的卷上来达到复制关键数据的目的。

    4。采用硬件存储快照的方式,耗费大量的存储设备,成本巨大。
    就我所知,至少veritas的vvr不需要太多额外的存储。

    5。华尔东城公司采用的独特方案,采用oracle的各种技术相结合,结合本公司独特的同步参数设置。通过本公司软件控制进行同步的管理。
    其实你这个ppt真是说的很含糊,用于单纯的sales宣传恐怕还可以,如果是用于技术交流实在是有些不痛不痒。

    6。华尔东城产品重要的益处,保证容灾数据完全一致,报表数据与10分钟前一致 。
    既然有10分钟的差距,为何仍然说容灾数据完全一致?如果说你们使用了物化视图的方案,那么就不可能在一个刷新期内(你们这儿的10分钟?)保证数据不丢失。除非还有业务log的分析软件作后备。

    7。华尔东城产品重要的益处,对主机性能影响小。
    其实物化视图的刷新对于主机并不是很小的影响,如果10分钟之内需要刷新大量的数据,可以明显的看到CPU的波峰,特别是oracle本身对于mvlog的处理还是有些问题的,所以不确定你们是否真的作过跟其它专业同步软件的主机性能影响的比较。

    8。本公司得益于oracle新技术的推出,加上本公司的努力,终于能够为数据同步提供完美的方案,这也是我们值得骄傲的一件事情。
    不否认你们确实作出了一个比较完备的同步解决方案,但是希望能够本着技术交流的想法在itpub讨论问题,而不是作单纯的商业宣传。我想很多人都希望知道你所指的oracle新技术是什么?不应该说就是物化视图吧。

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

    转载于:http://blog.itpub.net/756652/viewspace-242061/

    展开全文
  • Q9、是否支持同步复制、异步复制? A9:支持异步,不支持同步。   Q10、异步复制模式下,数据丢失情况? A10:由于RealSync直接读取Oracle的Online Redo Log,复制操作集中于数据的改变,复制时间间隔可以灵活的...
  • [root@nfs-01 ~]# vim ntpdate.sh #脚本复制好用执行一遍让时间一致 #!/bin/bash ntpdate time.nist.gov hwclock -w [root@nfs-01 nfs-01 ~]# crontab -e * * * * 1 /root/time.sh #每周同步一次 1、搭建...
  • 目前,针对oracle数据库的远程复制容灾主要有以下几种技术或解决方案:(1)基于存储层的容灾复制方案这种技术的复制机制是通过基于SAN的存储局域网进行复制复制针对每个IO进行,复制的数据量比较大;...
  • 介绍几种容灾复制技术

    千次阅读 2014-06-24 09:20:30
     数据复制有多种分类方法,依据复制启动点的不同,可分为同步复制、异步复制。同步复制,数据复制是在向主机返回写请求确认信号之前实时进行的;对于异步复制,数据复制是在向主机返回写请求确认信号之后实时进行的...
  • DSG-RealSync Oracle数据库同步复制容灾技术简述 1 为什么需要数据复制 1.1 信息系统存在的问题及需求 随着计算机应用系统的爆炸式发展,业务量迅速增加,业务种类日益复杂,企业必须管理不断增长的...
  • 常用的容灾技术

    千次阅读 2020-08-26 19:19:52
    容灾的介绍看这里 ... 目录 1、容灾的主要技术 2、主机层容灾技术 ...(一)同步复制容灾 同步复制原理 (二)异步复制原理 异步复制原理 4.2 NAS异步复制容灾 NAS异步复制容灾原理 5、异步远程复..
  •  有关同步数据容灾,在传统意义上讲,就是通过容灾软件(可以含在硬件系统内),将本地生产数据通过某种机制复制到异地。从广义上讲,同步数据容灾是指在异地建立起一套与本地数据实时同步的异地数据。  从图7-1可以...
  • 有人有兴趣讨论下压力大的数据库的容灾嘛?...主中心和容灾中心采用的是异地存储级的同步。在系统繁忙的时候突然断掉主容中心之间的通讯,发现容灾中心的数据库多数情况下是无法启动的。不知道大家有什么好的建议嘛?
  • Dataguard是ORACLE 提供的一种高可用性(HIGHAVAILABLE)的数据库方案,它是在主节点与备用节点间通过日志同步来保证数据的同步,可以实现快速切换与灾难性恢复。中软公司自主研发的基于Dataguard同步引擎的Oracle...
  • 作者:小新时间:04-09-24 08:04 有人有兴趣讨论下压力大的...主中心和容灾中心采用的是异地存储级的同步。在系统繁忙的时候突然断掉主容中心之间的通讯,发现容灾中心的数据库多数情况下是无法启动的。不知道大家有什
  • 前言---世贸大厦的倒塌使得800多家公司和机构的重要数据丢失,无数的企业成为这一恐怖事件的殉葬品。然而正当大家为此扼腕... ----但目前主流的容灾技术(磁盘阵列的复制方案和存储卷的解决方案)却让很多的企业不敢奢
  • DSG RealSync数据复制应用技术白 皮 书 目 录 1 为什么需要数据复制 31.1 信息系统存在的问题及需求 31.1.1 数据流通效率低下,企业信息孤岛现象严重 31.1.2 数据报表、查询和数据共享效率低下 31.2 ...
  • 广西移动采用DSG RealSync数据复制软件实现将营业库和客服库的数据变化分别复制到应急库,使得应急营业库和应急客服库的数据和生产系统的营业库及客户库的数据同步。并能在生产系统的营业库或者客户库有故障时,替代...
  • Ø广西移动营帐系统 •生产环境:2*IBM P690(24cpu,80G 内存) •CPU资源占用:>90% Ø为什么资源占用如此...Ø解决办法:采用DSG RealSync复制一个同样的数据库,一是可以将查询统计功能迁移到第二数据中心上;二是可
  • 杉岩数据:5种常见容灾复制技术图解 https://www.sohu.com/a/455336483_777975 常见的五种复制技术 随着数据持久化能力的提高,单套集群面对服务器宕机等常见硬件故障基本不会造成数据丢失和业务中断,但是单套...
  • 河北地税征管业务选用DSG RealSync用于省中心集中容灾和数据上收功能 (2005年8月) 河北省地税税收业务系统目前采用了在各市局分散应用模式,即十一个市局分别有各自的... 同时为了在各市局本地提供查询业务,要求复制
  • 河北地税征管业务选用DSG RealSync用于省中心集中容灾和数据上收功能 (2005年8月) 河北省地税税收业务系统目前采用了在各市局分散应用模式,即十一个市局分别有各自... 同时为了在各市局本地提供查询业务,要求复制到本
  • ORACLE 数据库容灾复制解决方案share Plex SharePlex® 是业界最成熟的高性能/高可用性数据复制解决方案。具有网络占用少、配置灵活、准实时复制等特点,可以解决关键应用的多种可用性问题。推出五年来,该产品 技术...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 14,634
精华内容 5,853
关键字:

容灾同步复制