大型企业异地容灾解决方案

XXX 异地数据容灾复制解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 迪思杰（北京）数码技术有限公司 二零零七年五月四日 目 录 TOC \o "1-3" \h \z 1 项目背景 4 2 用户的现状和需求 5 2.1 现状 5 2.2 用户需求 5 3 XXX数据复制方案设计 6 3.1 系统结构 6 3.2 软硬件配置需求 7 3.2.1 异地容灾系统的服务器和存储要求 7 3.2.2 DSG REALSYNC的配置 7 4 解决方案功能描述 8 4.1 初始化同步功能和性能 8 4.1.1 初始化的原理 8 4.1.2 dsg初始化性能 9 4.2 实时复制的功能和性能 10 4.2.1 日志 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 速度 10 4.2.2 每秒钟复制的操作数 10 4.2.3 复制数据延迟 11 4.2.4 CPU资源占用 11 4.2.5 源端的缓存空间 11 4.2.6 网络需求 11 4.3 业务接管和回切 12 4.4 数据一致性比较 12 4.4.1 比较原理 12 4.4.2 比较性能 13 4.4.3 特点 14 5 数据复制技术的比较 15 5.1 与磁盘阵列复制技术相比 16 5.2 与存储卷复制技术(VERITAS)相比 17 5.3 DSG RealSync与ORACLE DG的比较 18 5.4 与应用层技术相比 20 6 解决方案的特点 21 6.1 业务功能实现 21 6.1.1 主备系统数据库处于双活状态 21 6.1.2 以数据保护为中心，侧重于保护业务数据安全 21 6.1.3 数据损失 21 6.2 性能和稳定性 22 6.2.1 对源系统性能的影响 22 6.2.2 对网络资源的使用 22 6.2.3 数据延迟 23 6.2.4 对主中心的影响 23 6.2.5 复制环境的健壮性 23 6.2.6 事物的完整性和可用性 24 6.3 配置和实施 24 6.3.1 开放性 24 6.3.2 对源系统的修改工作 24 6.4 可扩展性 24 6.4.1 对系统扩容的影响 24 6.4.2 业务扩展的影响 25 6.4.3 对双机集群的支持 25 7 Realsync部分应用案例 26 1​ 项目背景 XXXXXXX有限公司成立于1998年6月,公司总部位于深圳市福田区XXX，拥有逾2000平米的自有现代化办公区。公司专注于移动通信产品的营销服务，是三星等国际著名品牌在中国的核心代理商，中国移动的战略合作伙伴，国内最大的移动通讯产品代理商之一。xxx在全国各地设立了39个分支机构， 形成了覆盖全国的销售、物流和服务网络是1999年以来手机分销行业内唯一实现年增长数倍的企业。基于INTRANET的xxx信息平台，是行业内最先进的、运用最广泛的、可延展性最深入的IT平台，给公司的手机分销和数据业务推广提供了强大的后台支持。 随着公司业务的发展，企业信息化对公司的业务影响越来越明显，为了更好地支持XXX集团的发展，集团组建专门的信息部负责企业的信息化进行全面的规划和实施维护。随着企业应用的逐渐增加，对一些关键业务的实时保护就变得异常重要，同时对关键数据的保护也变得十分重要。 应用级别的灾难恢复就是在这样的背景下提出的。 2​ 用户的现状和需求 2.1​ 现状 XXX目前采用dataguard的physical standy 模式进行数据的异地容灾处理。结构如下所示： 生产端服务器和容灾端服务器相同 均为ibm p570 aix5.2（6cpu），生产端将redo log 传送到远程然后再容灾端应用，采用physical standby模式。容灾端数据库为关闭状态。由于带宽的限制，初始化同步的时候先在深圳将容灾端服务器做好physical ，然后再将服务器运送至南昌容灾中心。其缺点为 1、​ physical standby 对带宽要求较高，而集团提供的路线仅仅10M。 2、​ 目标数据库处于关闭状态，切换比较繁琐。 2.2​ 用户需求 针对原有复制系统的不足，XXX对数据复制提出了下属的要求； 1、​ 在2M带宽下对数据进行复制。 2、​ 数据复制要保证数据的完整性和一致性，并能提供相应的比对工具。 3、​ 在生产中心和灾备中心可以进行任意灵活的切换，操作简单。 4、​ 灾备中心的数据库处于打开状态，可以有效地利用灾备设备。 3​ XXX数据复制方案设计 3.1​ 系统结构 根据异地容灾系统的需求及其业务特点，我们建议的异地容灾系统结构图如下所示： XXX现有的生产系统：oracle10g + ibm p570 aix5.2（6cpu） XXX现有的灾备系统：oracle10g + ibm p570 aix5.2 (6cpu) 该方案中采用DSG RealSync软件将深圳生产中心的生产数据实时复制到南昌容灾系统上，数据实时复制的时候，集团的10M的带宽完全可以满足要求。 针对数据库内容的完整性和一致性，我们软件配有专用的数据库比较工具，可以针对选择的内容进行快速的一致性比较，从而满足用户的数据验证的需求。 在容灾端，系统地Oracle数据库一直处于OPEN状态。可以在容灾中心上加载一些查询和统计分析的功能应用。 另外需要特别注意的是，对于集团的数据在容灾端回切的时候做增量复制的要求，我们目前的产品还不能满足，现阶段只能要求用户用全同步工具进行数据复制，但公司这方面一直在开发和测试，目前处于测试阶段，预计将在年底会有新版本和相应的成熟的解决方案发布。 3.2​ 软硬件配置需求 3.2.1​ 异地容灾系统的服务器和存储要求 异地实时备份服务器：和本地实时备份服务器一样，一般也选择和生产服务器相同档次的服务器（不过可选择不同厂商的），但一般建议采用单机结构用作备份服务器，无需在本地备份服务器上采用HA或双机结构。存储设备要求不小于源端系统的容量。 3.2.2​ DSG REALSYNC的配置 为了实现本地和异地的数据实时复制架构，我们采用DSG RealSync用于数据复制软件。在生产端和容灾端的数据库服务器上（安装oracle软件的服务器）分别部署两个realsync agent:。经过配置之后，通过生产端和容灾端agent的通信，就可以将源端的数据实施复制到容灾端的数据库服务器。 4​ 解决方案功能描述 在采用了DSG的realsync解决方案后，可提供数据实时复制的需要，包括业务连续性的切换，也包括因为误操作而造成的数据损坏。 4.1​ 初始化同步功能和性能 4.1.1​ 初始化的原理 DSG RealSync提供的首次全同步功能将源系统上的已有数据记录从datafile中直接读取并解析成为DXF数据格式，在利用XIMP将DXF数据批量快速装载到Data target系统上。 RealSync调用Oracle的I/O层的API接口批量读取一张 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf （Table）的记录（每次读多少条是由操作员设定的RealSync系统的Buffer决定的，如果一次读不完，则分为多次读取），然后将读取的记录转化为DXF格式，再将DXF格式表示的一批记录传送到目标端的RealSync Agent进程，目标端进程再调用ORACLE的I/O层的API接口将数据批量写入目标系统中。 对于一个数据库而言，其中有许多张表（Table），RealSync依次将每张表的所有数据按照上述原理复制到目标系统中。 对于xexp导出过程不是通过Oracle的 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 select接口，所以其导出速度非常快。 同时，在采用DSG RealSync实现批量数据装载时，还无需停止源系统上的业务 流程 快递问题件怎么处理流程河南自建厂房流程下载关于规范招聘需求审批流程制作流程表下载邮件下载流程设计 。那么RealSync是如何处理在导出过程中新改变的数据的复制呢？ 因此，RealSync还支持第二阶段的增量数据复制： 当上个步骤的大批量数据完成后，RealSync再将步骤一过程中新增加的交易重新复制到目标系统。 在过程的工作原理是通过跟踪和分析从上个步骤开始时的所有redo.log信息，从Log文件中分析和翻译出这段时间内新增加的记录，然后再将记录在目标系统上插入。 如果在该过程中复制的数据在目标表中已经存在，则RealSync将首先删除目标系统中的该记录，同时插入新复制的记录。 在这两个过程执行过程中，生产系统的业务可以保持运行状态。无需中断业务。 4.1.2​ dsg初始化性能 dsg专业的初始化同步工具，可以快速有效地完成实时复制所需的数据初始化的问题，并且不需要中断业务。下表是用户在带宽没有限制的情况下的初始化同步的性能。 源端导出速度 10个并发任务下： 780GB：3个小时导完 每个并发任务消耗单个cpu的30% 目标端装载速度 10个并发任务下： 780GB：6个小时导完 含建索引 每个并发任务消耗单个cpu的30% 4.2​ 实时复制的功能和性能 realsync 实时复制 源端cpu 单个CPU的10%左右 目标端cpu 单个CPU的20%左右 源端内存 200~400M 目标端内存 200~400M 实时抓取速度 2分钟1GB日志 实时装载速度 3分钟1GB日志 4.2.1​ 日志分析速度 2分钟分析完成10GB积压日志 我们采取了积压日志分析的方式进行测试，利用rac环境下的两台服务器同时产生10GB的日志数据，然后启动realsync测试其在多长时间内能够分析完这些数据。测试结果表名，在rac模式下，由两个数据库节点同时工作，在5分钟内产生的10GB归档日志，共计800万条记录，realsync只需要2分钟40秒即能分析完累积的日志，约9分钟装载完成。日志分析的速度远远高于产生日志的速度。完全能够满足未来的业务需求，即使是在业务高峰期，也不会造成日志累积。 4.2.2​ 每秒钟复制的操作数 每秒钟处理达到18000条操作，满足高峰期的业务并发量。 在测试过程中，我们采用PL/SQL方式在源端产生1万,10万，100万条记录，以及进行1万,10万，100万的update,delete操作等。按照统计结果，DSG RealSync达到平均18000条/s的复制速度。 4.2.3​ 复制数据延迟 RealSync是一种异步准实时的复制技术，其数据延迟非常小。数据延迟的周期可以设置，在生产系统中，数据延迟和源系统复制事物的多少，事物的处理方式有关，以及跟设置的log数据轮询周期有关。在复制数据量正常的OLTP系统中，数据延迟一般在几秒钟。 4.2.4​ CPU资源占用 DSG RealSync通过Oracle日志获得数据的变化信息，它独特的技术优势使得它对源系统的资源占用很小。在生产系统中，实际对源系统的影响和源系统复制事物的多少，事物的处理方式有关。在复制数据量正常的OLTP系统中，正常状态下对CPU资源的占用为几个百分点。 4.2.5​ 源端的缓存空间 当容灾中心暂停或传输异常中断导致复制停止时，RealSync会将数据库的变化内容存储在源系统或目标系统的队列中，当系统恢复后，RealSync会自动识别复制环境，自动从断点处开始复制工作。在上述过程中，主中心的业务不受任何影响。数据的一致性不会破坏。 当复制环境停止的情况下，需要在源系统和目标系统上存储的空间和业务系统每天峰值的日志数有关。 4.2.6​ 网络需求 RealSync对数据传输采用TCP/IP网络传输。 RealSync复制操作只是读取操作系统的日志文件，同时通过TCP/IP方式而不是采用中间件方式传输只发生改变的数据也使网络负载降至最低。RealSync只将日志的三分之一的内容通过网络进行传输。实际每小时传输的数据量=每小时日志文件切换的数量*日志文件的大小*1/3 . 根据XXX的业务量统计峰值时为每分钟产生的日志量为100M。 实际每分钟传输的数据量=每分钟日志量*/3=100/33 M 折算成带宽约为5Mbps。 4.3​ 业务接管和回切 当生产服务器出现故障，导致生产服务器不可用的时候，由于我们实时复制服务器处于打开状态，随时可以接管生产端服务器的业务，所以业务接管时不需要进行额外的工作。当生产端服务器经过处理可以重新使用的时候，需要对生产端的服务器和实时复制服务器做一次数据全同步，在数据初始化同步的过程中不会影响业务。 4.4​ 数据一致性比较 4.4.1​ 比较原理 对于ORACLE而言，数据一致性的检查主要通过数据库的SQL接口读取记录进行对比的方式进行。而这种比对方式耗时巨大，效率十分低下，如果对于一些没有主键的表就几乎无法比较。 DSG在数据一致性校验的检查机制方面做的尤为突出，并且使得这一需求变得可行。在其它同类产品中，DSG RealSync不是通过select接口来读取数据并进行比较，而是通过批量读取的方式从数据库底层直接读取记录，并通过rowid的对应关系来定位记录，并通过数据源的记录值、ROWID，目标端的记录值、ROWID，以及realsync所记录的ROWID映射关系来比较双方的记录是否一样。 其实现原理为： （1）​ 从源端通过realsync自带的导出工具读取某张表的所有记录，将每条记录生成一个CRC校验码。从而形成ROWID和CRC对应的数据文件； （2）​ 将校验文件传输到目标端； （3）​ 目标端也通过realsync自带的导出工具读取需要比较的表的所有记录，将每条记录生成一个CRC校验码。从而形成ROWID和CRC对应的数据文件； （4）​ 利用realsync记录的ROWID MAPPING映射文件比较每条记录的CRC码是否相同，如果不同，则两条记录的肯定有错误。 4.4.2​ 比较性能 该工具的工作方式不是通过select接口读取数据进行比较，而是通过其快速导出工具进行记录导出，并将导出的记录分别形成CRC校验码，然后通过CRC校验码来检验数据是否一致。 根据测试结果表名：对一个有900多万行记录的用户进行一致性比较，比较时间<1分钟； 4.4.3​ 特点 ​ 性能高：对一个有900多万行记录的用户进行一致性比较，比较时间<1分钟； ​ 对特殊数据类型也可以比较：对于long raw,lob等类型都可以比较。 ​ 网络压力小：因为传输的数据不是记录本身，而只是每条记录的crc校验码，因此网络压力很小。 5​ 数据复制技术的比较 在选择数据复制系统的构造时，首先要考虑的就是选择采用合理的异地数据复制技术。数据的远程复制技术是数据复制系统的核心技术，它对于数据系统的一致性和可靠性以及系统的应变能力具有举足轻重的作用，通过有效的数据复制，远程的业务数据中心与本地的业务数据实现同步，确保一旦本地系统故障，远程的数据复制中心迅速进行完整的接管。一般说，在容灾系统方案的数据复制技术上存在两种主流模式： ​ 第一种方式是基于智能存储的数据镜像技术。该技术是将数据复制通过磁盘阵列控制器在进行写入操作的同时通过高速网络向容灾系统的阵列上发送相同的I/O指令来实现，因此该方案对主机的资源占用很小；稳定性好；同步性强。该技术主要由各存储设备生产厂家所推荐，如EMC，IBM，HP等都提供了相应的解决方案。 ​ 第二种方式是基于主机系统的数据复制，该方式是把数据定期、在线地复制到目的地的机器上去。这种方案大部分由存储管理软件厂家提供，尤其是VERITAS推出了一系列基于该方案的存储管理软件解决方案。 而用户在选择复制技术时，除了考虑技术本身以外，还着重考虑以下几个因素： （1）投资回收 与其他任何保险策略一样，对容灾系统而言，没有灾难出现时，我们根本无法意识到容灾系统所起到的作用，无法回收容灾系统建设所需的大量投资。但从系统安全性角度考虑，我们必须为关键的业务支撑系统建设最有效的灾难恢复解决方案。但是在大部分情况下，当未出现灾难时，我们的容灾端系统总是处于空闲状态，花费大量投资买来的系统根本无法有效利用。这个问题一直困扰着用户。 因此，我们建议在容灾系统建设中，需要考虑的第一个问题是如何保证容灾端的系统可以得到充分利用，使容灾端系统的数据实现共享，能够利用容灾系统提供的高性能主机资源、存储资源为企业带来更大的处理能力。 （2）异构平台 因为容灾系统的建设其投资很高，并且所能够选择的系统平台有限。而对目前各大厂商推荐的容灾方案大部分是基于智能存储复制技术，这种技术要求本地系统与容灾系统的系统平台同构。这样用户就很容易受到平台选择的限制。 DSG RealSync主要应用目的是将一个oracle系统上的数据实时复制到另外一个oracle系统上。 实现这些功能的业界常用解决方案主要包括以下几类： ​ 磁盘阵列复制技术：主要由一些磁盘阵列厂商提供，如EMC SRDF、IBM PPRC 、HP BusinessCopy、HDS TrueCopy等； ​ 存储卷复制技术：由一些卷管理软件厂商提供，如VERITAS VVR； ​ 数据库复制技术：由数据库厂商以及一些第三方厂商提供，如DSG RealSync/SmartE，Quest SharePlex等； ​ 应用层复制技术：由各系统的应用厂商自己提供； DSG RealSync属于数据库复制技术。因此下面就该技术与其他几类复制技术的优缺点作一个归纳： 5.1​ 与磁盘阵列复制技术相比 DSG RealSync 磁盘阵列复制技术 适合对象： ​ 适合从工作组级、企业级到数据中心级的复制需求。 ​ 无论系统采用什么样的服务器平台、什么样的存储平台，只要是ORACLE系统之间的复制即可适用。 优点： ​ 目标端数据可用：目标端数据库在复制过程中出于可用状态，可用作数据查询、报表、数据抽取等任务分担； ​ 异构系统复制：源端系统和目标端系统可以采用异构的操作系统平台、存储平台； ​ 支持选择性复制：支持只复制指定的user、指定的Table、指定的行和列。节省存储空间，提高应用灵活性； ​ 支持1对多，多对1的复制结构：能够将多个数据库中的数据复制到一个数据库中；能够将一个数据库中的不同数据分发到不同的数据库中。 ​ 节约带宽和网络资源：所需带宽一般在几Mbps,几十Mbps。 缺点： ​ 只支持ORACLE数据库系统。 ​ 只支持异步复制，不支持同步方式。 ​ 只支持ORACLE系统中的DML复制和常用的DDL复制，对存储的变化不复制。 ​ 占用主机的CPU资源； 适合对象： ​ 主要适用于数据中心级的海量数据复制。 ​ 用户必需采用支持该功能的磁盘阵列型号，而这些阵列大都为高端阵列，投资昂贵。 优点： ​ 支持阵列上的所有数据类型复制。 ​ 可支持同步方式复制 ​ 不占用主机CPU资源 缺点： ​ 目标端数据不可用：目标端数据库在复制过程中不能被打开，造成大量投资浪费； ​ 必需同构：源和目标必需要求相同的磁盘阵列、相同的操作系统、相同的数据库版本； ​ 只能全库复制：复制的对象是整个数据库 ​ 不能实现数据整合和数据分发； ​ 带宽高：要求独占的光纤网络，动辄需要上GB的带宽。 5.2​ 与存储卷复制技术(VERITAS)相比 DSG RealSync/SmartE Veritas vvr 适合对象： ​ 适合从工作组级、企业级到数据中心级的复制需求。 ​ 无论系统采用什么样的服务器平台、什么样的存储平台，只要是ORACLE系统之间的复制即可适用。 优点： ​ 目标端数据可用：目标端数据库在复制过程中出于可用状态，可用作数据查询、报表、数据抽取等任务分担； ​ 异构系统复制：源端系统和目标端系统可以采用异构的操作系统平台、存储平台； ​ 支持选择性复制：支持只复制指定的user、指定的Table、指定的行和列。节省存储空间，提高应用灵活性； ​ 支持1对多，多对1的复制结构：能够将多个数据库中的数据复制到一个数据库中；能够将一个数据库中的不同数据分发到不同的数据库中。 ​ 节约带宽和网络资源：所需带宽一般在几Mbps,几十Mbps。 缺点： ​ 只支持ORACLE数据库系统。 ​ 只支持异步复制，不支持同步方式。 ​ 只支持ORACLE系统中的DML复制和常用的DDL复制，对存储的变化不复制。 适合对象： ​ 主要适用于工作组级的数据复制。因为对CPU资源占用高 优点： ​ 支持存储卷上的所有数据类型复制。 ​ 可支持同步方式复制 缺点： ​ 目标端数据不可用：目标端数据库在复制过程中不能被打开，造成大量投资浪费； ​ 操作系统必需同构：源和目标必需要求相同的操作系统和相同的数据库版本，但不要求相同的存储设备 ​ 只能全库复制：复制的对象是整个数据库 ​ 不能实现数据整合和数据分发； ​ 带宽高：传输数据量比DSG RealSync/SmartE高5倍以上。 5.3​ DSG RealSync与ORACLE DG的比较 DSG RealSync ORACLE DG 适合对象： ​ 适合从工作组级、企业级到数据中心级的复制需求。 ​ 无论系统采用什么样的服务器平台、什么样的存储平台，只要是ORACLE系统之间的复制即可适用。 优点： ​ 目标端数据可用：目标端数据库在复制过程中出于可用状态，可用作数据查询、报表、数据抽取等任务分担； ​ 异构系统复制：源端系统和目标端系统可以采用异构的操作系统平台、存储平台； ​ 支持选择性复制：支持只复制指定的user、指定的Table、指定的行和列。节省存储空间，提高应用灵活性； ​ 支持1对多，多对1的复制结构：能够将多个数据库中的数据复制到一个数据库中；能够将一个数据库中的不同数据分发到不同的数据库中。 ​ 节约带宽和网络资源：所需带宽一般在几Mbps,几十Mbps。 ​ 性能高于ORACLE DG，DSG RealSync软件已经应用于广西移动的营帐系统的环境，数据容量达到2TB，每天产生的日志量最大能够处理到600GB/天 ​ 提供不停业务的初始化同步，提供记录级的抽取和装载功能，在此过程中源端业务不用停止。 缺点： ​ 需要单独购买 ​ 只支持异步复制，不支持同步方式。 适合对象： ​ 主要适用于小型数据库的容灾使用。 优点： ​ Free ​ 可实现同步复制模式。 缺点： ​ 目标端数据不可用：目标端数据库在复制过程中处于RECOVER状态，不能被用来使用； ​ 操作系统必需同构：源和目标必需要求相同的操作系统和相同的数据库版本； ​ 只能全库复制：复制的对象是整个数据库 ​ 不能实现数据整合和数据分发； ​ 性能低下，目前的应用案例多在小型数据库上使用。 ​ 重新同步一次非常复杂，需要通过备份恢复的方式来进行首次初始化，并且最好很死停止业务。 ​ 数据丢失量：将可能丢失一个REDO LOG的数据量 5.4​ 与应用层技术相比 DSG RealSync/SmartE 应用层复制技术 适合对象： ​ 适合于构建在ORACLE系统上的所有应用系统和应用类型 优点： ​ 无需二次开发； ​ 标准的工业化软件，成熟度远远高于应用复制； ​ 专业厂商支持和维护； ​ 应用案例远多于应用层复制技术； 缺点： ​ 与应用的关系比较松散，无法完全按照应用需求定制 适合对象： ​ 只适合那些在应用中提供了该技术的应用，而非常少。 优点： ​ 与应用集成紧密，可按照应用的需求作调整。 ​ 从理论上讲能够解决所有的应用需求 缺点： ​ 非标准化：不同应用软件的复制方式不同； ​ 开发和维护工作量大，任何应用的变动都可能导致复制技术的变动； ​ 应用不成熟、不普遍。 ​ 无法实现大量应用案例之间的知识共享。 6​ 解决方案的特点 方案从满足用户需求为基本出发点，可以充分满足数据同步的需求，并且还能够对系统的优化部署提供更大的支持。 6.1​ 业务功能实现 6.1.1​ 主备系统数据库处于双活状态 容灾数据库承担了数据容灾备份，在任何一个生产数据库发生灾难时需要及时提供业务的接管和及时的数据恢复，同时，灾备数据库一直处于open状态，可以对灾备数据库进行实时访问，系统保持生产中心和灾备中心的数据库处于双激活状态； 推荐解决方案采用了DSG RealSync实现生产数据库源系统到容灾系统的复制工作。可以从技术上保障目标数据库在线可用，容灾数据库的数据实时可读取，复制过程和数据读取不产生矛盾。RealSync的复制延迟很小，从容灾数据库读取到的数据是实时最新数据，不需要为了读取到最新数据而进行一些切换工作。 6.1.2​ 以数据保护为中心，侧重于保护业务数据安全 灾难备份的目标有两个，一是保护数据的完整性，尽量减少业务数据丢失，最好没有业务数据丢失，从而减少业务风险。二是快速恢复数据，使业务系统停顿时间最短。数据是业务系统的生命线，因此在制定灾难备份策略时应侧重于保护业务数据安全，将确保数据安全作为灾难备份的首要目标。 推荐解决方案采用了RealSync进行数据库复制，不存在在极端情况下（如掉电、站点失败）灾备数据库无法访问的风险。目标数据库一直处于OPEN状态过程实际上是对数据风险的有效控制。 6.1.3​ 数据损失 推荐解决方案在一般性灾难发生时一般不存在数据丢失。这些一般灾难包括数据库失败、操作系统失败等等。对于一些极端的情况下，掉电、站点失败时，DSG RealSync也作了大量测试不会出现数据丢失（但从理论上讲这些极端情况无法100%避免数据丢失，因为这种情况可能造成了系统的严重破坏）。 网络失败：网络恢复时继续复制，没有数据损失 数据库关闭：数据库恢复时从断点继续复制，没有数据损失 操作系统重起：重新启动复制软件，从断点处继续复制，没有数据损失 掉电：DSG RealSync也作了大量测试不会出现数据丢失（但从理论上讲这些极端情况无法100%避免数据丢失，因为这种情况可能造成了系统的严重破坏）。不过对于重要的生产系统一般通过UPS预防断电情况,发生概率非常小. 站点失败：由于目标系统在线可用，不存在任何数据风险。但对于还没来得及传输到目标系统的数据可能出现丢失。 6.2​ 性能和稳定性 6.2.1​ 对源系统性能的影响 DSG RealSync通过Oracle日志获得数据的变化信息，它独特的技术优势使得它对源系统的资源占用很小。在生产系统中，实际对源系统的影响和源系统复制事物的多少，事物的处理方式有关。在复制数据量正常的OLTP系统中，正常状态下对CPU资源的占用为5个百分点，对内存资源的占用为几十M至100M。 6.2.2​ 对网络资源的使用 推荐方案所需网络带宽有限，能够在有限传输带宽上保证复制工作不延迟。 因为RealSync复制操作只是读取操作系统的日志文件，同时通过TCP/IP方式而不是采用中间件方式传输只发生改变的数据也使网络负载降至最低。RealSync只将日志的三分之一的内容通过网络进行传输。实际每小时传输的数据量=每小时日志文件切换的数量*日志文件的大小*1/3 . 例如用户峰值每小时生成的日志量为720M。 实际峰值期间每小时传输的数据量=每小时日志文件切换的数量*日志文件的大小*1/3=720/3=240M 考虑20%的传输开销，所需要的带宽为240*1.2/3600=80KB/S,系统对传输带宽的要求为640kbps。 6.2.3​ 数据延迟 RealSync是一种异步准实时的复制技术，其数据延迟非常小。数据延迟的周期可以设置，在生产系统中，数据延迟和源系统复制事物的多少，事物的处理方式有关，以及跟设置的log数据轮询周期有关。在复制数据量正常的OLTP系统中，数据延迟一般在几秒钟。 6.2.4​ 对主中心的影响 当容灾中心暂停或传输异常中断导致复制停止时，RealSync会将数据库的变化内容存储在源系统或目标系统的队列中，当系统恢复后，RealSync会自动识别复制环境，自动从断点处开始复制工作。在上述过程中，主中心的业务不受任何影响。数据的一致性不会破坏。 当复制环境停止的情况下，需要在源系统和目标系统上存储的空间和业务系统每天峰值的日志数有关。例如用户峰值每小时生成的日志量为720M。需要容错24小时。 容错期间需要处理的日志量=每小时日志文件切换的数量*日志文件的大小*1/3＊24=240M*24=5.76G 在网络中断情况下，考虑数据暂时存放在源系统24小时所需要的存储空间。按照50%的存储开销计算，所需要的空间为5.76*1.5=8.64G，也就是说，对于每小时产生720M日志的数据库系统，在保存24小时传输内容的情况下，需予留8.64G的存储空间。 6.2.5​ 复制环境的健壮性 推荐解决方案具备足够的健壮性。源系统和目标系统的任何故障都不会影响到复制环境。在以下故障发生时，RealSync故障处理方法如下： 源系统主机故障：源系统主机故障修复后，当Oracle数据库和操作系统重新启动后，RealSync自动重试连接数据库，并从断点继续进行复制工作。 数据库故障：当源系统数据库故障修复后，当Oracle数据库重新启动后，可以从断点继续进行复制工作。 复制软件故障：复制软件在源系统有三个进程，目标系统有两个进程。当复制软件的进程遇到问题时，可以自动重起相关进程。 网络故障：当网络恢复后可以自动从断点进行复制工作。 目标系统的主机故障：数据存储在目标系统队列中，当目标系统主机故障修复后，从断点继续进行复制工作。 数据库故障：数据存储在目标系统队列中，当目标系统数据库修复后，从断点继续进行复制工作。 6.2.6​ 事物的完整性和可用性 RealSync是一个数据库级的软件解决方案，其复制的基本单位就是一个事务(Transaction)，RealSync在从oracle log中读取到交易数据后，根据交易的关系，将属于一个事务的所以操作组合在一起，以一个基本单位发送给目标端，目标端在执行时也严格按照交易进行，因此严格保证了交易的完整性。 对于事务与事务之间的顺序，RealSync严格按照ORACLE 的SCN标记进行排序。确保事务之间的先后秩序。 6.3​ 配置和实施 6.3.1​ 开放性 推荐解决方案采用开放系统环境，和存储设备、硬件设备、操作系统、Oracle数据库版本无关。由于采用了RealSync的复制解决方案，源数据库和目标数据库可以运行在不同类型的操作系统和Oracle数据库的不同版本上。同时，也能够支持不同类型的存储环境。 6.3.2​ 对源系统的修改工作 推荐解决方案对源系统不进行复杂的配置修改工作。RealSync建立复制环境所需要工作量少。不需要对硬件、软件、磁盘卷的划分进行任何额外的操作。减少了建立冗灾环境对系统结构和应用所作的修改工作。使用RealSync，不需要在实施的过程中和系统整合时对空间进行从新划分，极大地降低了工作量。 6.4​ 可扩展性 6.4.1​ 对系统扩容的影响 由于采用了RealSync的复制解决方案，对今后的扩容没有任何影响。使用RealSync，源数据库和目标数据库可以运行在不同类型的操作系统和同一Oracle数据库的不同版本上。同时，也能够支持不同类型的磁盘阵列。这不仅能够满足目前异构环境，还能适应未来的扩展需求。随着业务量规模的不断扩大，在硬件升级时，新旧硬件产品可以随意调换，不受限制。 6.4.2​ 业务扩展的影响 推荐解决方案对未来容灾功能扩展没有任何影响。未来需要将其他业务系统进行容灾时，可以非常方便地将需要容灾的系统纳入容灾框架。 6.4.3​ 对双机集群的支持 对于源系统，RealSync解决方案提供对双机集群的支持。因为RealSync的所有可执行文件和队列都存储在文件系统中，当primary出现问题后，可以在passive 机器上启动RealSync并继续进行复制工作。 对于目标系统，RealSync提供灵活的方式进行复制。目标系统可以配置或不配置成集群方式。RealSync也能够将所有数据源都复制到一个目标系统。这时容灾系统作为数据源，同样也支持集群方式。 7​ Realsync部分应用案例 客户名称 应用目的 系统规模 福建电信 本项目的建设需求是为福建电信集中计费系统上线后建立一个独立的查询系统，将帐务数据库和统计数据库上的数据同步到一个对的查询数据库中，通过该查询数据库实现24个月的计费话单数据保存、对外数据接口、以及对外查询业务。 生产系统由统计系统和帐务系统组成。 ​ 统计数据库的大小： 2台IBM P595服务器 数据量大小：2TB，每天日志两100GB. ​ 帐务数据库的大小： 2台IBM P595服务器 数据量大小：6TB，每天日志两500GB. 广西移动 将生产中心的的营业数据库（ORACLE RAC）和客服数据库容灾到一台应急容灾系统上。 使得应急营业库和应急客服库的数据和生产系统的营业库及客户库的数据同步。并能在生产系统的营业库或者客户库有故障时，替代故障库，接管应用。当故障库修复以后，能及时将应急库中的数据同步到修复后的生产数据库。 营业数据库布放在两台P690服务器上，采用ORACLE 9I RAC，数据量主要分布在两个SCHEMA下。共计数据量有900GB多。 客服数据库布放在另外一套HA环境下，数据量有100多GB 山东联通 计费系统和缴费卡系统的应用级容灾方案。同时将容灾的数据用作测试平台和查询应用 计费系统客户量650万户，日处理话单数6500万条；高峰期的每分钟处理话单数130000条。2个月数据量为1.2TB左右 辽宁网通 实现省中心6大业务支撑系统（计费、营业、服务平台、结算、网管、采集等）复制到一个报表系统上。 6大系统业务系统，设计容量总和达30T，单个系统设计最大容量为10TB左右。 江苏联通 用RealSync从计费系统、帐务系统中的指定表的数据复制到VIP统上。进行VIP业务管理和查询、统计分析等。 综和营帐系统： 采用4台服务器组成oracle数据服务器，承担所有业务的营业和统一帐务功能； 数据量总共约为1.2TB 计费系统： 采用两台服务器作为oracle数据库服务器； 数据量约为800GB左右； 上海松江财政 松江财政局建设集中的数据中心，将所属的相关单位的财政数据集中收集到数据中心。通过收集过来的数据实现两类目的： 作为各单位重要数据的灾备中心；通过实时复制的方式将各下属单位的重要财政数据上收到数据中心，当各系统能够因为灾难造成业务停止或数据丢失时，能够在灾备中心进行业务接管和数据恢复。 建立数据仓库平台；通过实时复制的方式将各下属单位的重要财政数据上收到数据中心，再从集中数据库中通过ETL工具抽取关心的业务数据进入数据仓库中，进行财政数据的分析、汇总和数据挖掘。 一期将其下属的三个重要的数据库进行上收。 上收的数据包含3个oracle 数据库; 共计约400个user下的数据； 数据量总共为几十GB。 河北地税 该省地税税收业务系统目前采用了在各市局分散应用模式，即十一个市局分别有各自的数据中心，负责税务征管和帐务处理。 为了实现对关键业务数据的异地容灾备份，同时实现数据的省级集中用于决策支持系统的数据源，需要在省局建立各市局数据的准实时备份。 同时为了在各市局本地提供查询业务，要求复制到本地另一台服务器上一套税务征管数据用于查询。 11个地市的税务征管系统： 每个系统由两台IBM 服务器组成HA结构 每个地市数据量约为50GB，数据总量约600GB. Realsync运行套数： 11套1:1的本地复制系 统； 11套N:1的集中复制系统 济南钢铁ORACEL ERP数据抽取 建议济南钢铁市场信息自动化数据库，从ERP系统\MES系统以及计质量系统上抽取数据，用于市场信息化数据库的数据来源 RealSync软件安装在ERP,MES和计质量三个数据库上，从这些系统上将数据复制到市场信息化集中数据库上。 ERP系统的组成： ORACLE ERP系统 SUN Solaris服务器 200GB数据量 附件一： Realsync的一些说明 关于数据库switch back操作的问题 Switch back时，为了保证生产中心和灾备端数据库保持严格一致，我们建议用户进行所有数据的同步，而不是进行增量数据的同步，这样做有两种好处： 1、​ 可以保证灾备端连续运行，不需要进行影像业务的操作。 2、​ 可以保证数据的完整性，数据保持严格一直 3、​ 另外realsync的同步速度非常快，压缩后超过400G/h，在贵公司10M/s的情况下，100G的数据同步时间大约为7个小时。 RealSync for Oracle功能支持： （1）​ 支持的DML操作类型 • Insert； • Update； • Delete； （2）​ 支持对Truncate Table操作复制 （3）​ 支持DIRECT PATH LOADING(SQL LOADER)在Logging模式下批量装载数据的复制 （4）​ 提供ROWID Mapping模式的映射关系（支持Unique key和非unique key的表的复制） （5）​ 支持的DATA TYPES： • CHAR • DATE • NUMBER • LONG VARCHAR • VARCHAR • VARCHAR2 • FLOAT • LONG • LONG RAW • BLOB • CLOB （6）​ 支持的Table 类型 • Table with partitions • Table with chained－rows （7）​ DDL操作类型支持 Objects type Operate type 备注 tables Create table Drop table Truncate table Alter table: column_clauses:: add_column_clauses modify_column_clauses drop_column_clause rename_column_clause constraint_clauses:: ADD constraints MODIFY constraints Drop constraints alter_table_partitioning:: add_table_partition drop_table_partition truncate partition indexes Create Alter Drop views Create Alter Drop sequences Create Alter functions Create Alter Drop procedures Create Alter Drop packages Create package Create package body Alter package Drop package Drop package body （8）​ 不支持的DATATYPE • UDT(user defined type) • BFILE （9）​ 不支持的TABLE类型 • IOT • CLUSTER （10）​ 支持多个节点组成的RAC系统 在realsync v6.1.0.0中只支持2个节点组成的RAC系统。在v6.2中支持了超过2个节点组成的RAC系统，包括3个、4个节点组成的rac系统。