1 医院数据中心异地灾备系统建设 |
医院数据中心 异地灾备系统建设 项目建议书 迪思杰（北京）数码技术有限公司 2010-8-24 1 项目背景 随着医院信息化进程的不断深化，信息系统成为了支撑医院业务运行的重要平台，医院的全部业务流程都依赖于信息系统提供的服务来运作。为了保证该系统的稳定、安全、有效的运行，医院的IT部门都采用了双机、RAID、磁带备份等技术，来回避由于磁盘故障，人为失误，应用程序的逻辑错误，自然灾害等原因带来的系统停机或者数据丢失。但大部分医院并没有建立一个容灾机制，一旦数据库或硬件出现故障，较长时间不能恢复，对医院来说都是一次灾难，将会给给医院的声誉带来了恶劣的影响并造成了极大的经济损失： ü 广东省人民医院电脑故障让患者受累 ü 北京妇产医院挂号故障千人排队苦等 ü 上海市第十人民医院停机4个多小时 ü 通山县人民医院电脑故障无法交费 老汉等2小时猝死检测室 ü 闵行区医院电脑故障 千余人等数小时挂号 ü 华山医院网络故障2小时取不了药 ü 中山市中医院系统出现故障，医院收费环节完全瘫痪，导致数千人看病受到影响 ü 第八人民医院医院电脑临时出故障沟通不畅引患者投诉 ü 北京安贞医院电脑系统出现故障，造成大厅聚集近百名患者 ü 上海一医院突发电脑故障 造成大量病人滞留 ü 齐鲁医院电脑突发故障 患者排长队苦等 ü 上海龙华医院电脑系统故障致排队人至门口 ü 东方医院电脑系统突发故障 数百患者苦等三小时 因此迫切需要建设容灾系统，以保证计算机业务系统的连续运行，并提高信息系统抵御突发性灾难的能力，保证医院稳定运行。 本方案是迪思杰(北京)数码技术有限公司根据****医院提出的以上需求，所提出的利用DSG Realsync数据同步复制软件实现数据的实时复制，从而满足“建设容灾系统，实现数据的远程备份和业务的不中断运行“的需求。 DSG Realsync数据同步复制目前在国内有200多家客户，占到第三方数据复制软件市场70%以上的市场份额。 本方案如有欠缺或遗漏之处，敬请谅解！ 2 容灾技术分析 2.1 容灾技术的选择 在选择容灾系统的构造时，首先要考虑的就是选择采用合理的异地数据复制技术。数据的远程复制技术是容灾系统的核心技术，它对于数据系统的一致性和可靠性以及系统的应变能力具有举足轻重的作用，通过有效的数据复制，远程的业务数据中心与本地的业务数据实现同步，确保一旦本地系统故障，远程的容灾中心迅速进行完整的接管。 实现这些功能的业界常用解决方案主要包括以下几类： 1. 磁盘阵列复制技术： 主要由一些磁盘阵列厂商提供，如EMC SRDF、IBM PPRC 、HP BusinessCopy、HDS TrueCopy等, 该技术是将数据复制通过磁盘阵列控制器在进行写入操作的同时通过高速网络向容灾系统的阵列上发送相同的I/O指令来实现； 2. 存储卷复制技术： 由一些卷管理软件厂商提供，如VERITAS VVR； 3. 存储虚拟化技术： 飞康的CDP等，该技术是将系统中各种异构的存储设备映射为一个单一的存储资源，对用户完全透明，达到屏蔽存储设备的异构和主机的异构的目的。 4. 数据库复制技术： 由数据库厂商以及一些第三方厂商提供，如DSG RealSync/SmartE等； 磁盘阵列复制技术、存储卷复制技术、存储虚拟化技术与数据库复制技术在容灾应用的层面相比较起来，有几个明显的缺点： 不足一：切换的复杂性 在灾难发生的时候，如果采用的是盘阵/卷/虚拟类的容灾方案，那在业务切换（接管）时需要经过： 1、主机启动、 2、存储启动、 3、Oracle数据库启动、 4、中间件启动 5、网络切换、 6、应用切换， 7、相关参数修改 等等多个环节才能成功完成整个过程，而在突发事件产生的时候，现场是否有能有这么多技术人员保障，能够解决各个环节的启动、切换等，这个一个非常现实的问题。 由于Realsync软件实施的容灾数据库是OPEN状态的，所以没有主机、存储、数据库重启等繁琐步骤，只需要将容灾端ORACLE数据库的trigger激活，并将应用服务器器连接到接管的数据库服务器上。 Realsync是所有方案中切换最简单、最方便的，相信这个操作大部分的IT部门人员都可以完成。 不足二：30分钟切换（接管）的压力较大 由于采用磁盘阵列/存储卷/虚拟容灾方案，在业务切换（接管）时需要经过主机启动、存储启动、Oracle数据库启动、网络切换、应用切换等多个环节；其中仅UNIX操作系统启动（含服务器外围设备和网络等元素的启动）和Oracle启动两个步骤就要花费几十分钟（至少为15+10=25分钟）。 在很多关键行业，如果要实现30分钟内接管业务，这是有一定压力的。 因此，在证券等实时性较高的行业，数据库复制技术被大规模采用。（DSG目前在金融证券基金期货行业，拥有50多个灾备客户） 不足三：备份数据库是否一定能够接管还存在疑问 由于磁盘阵列/存储卷/虚拟容灾方案是采用基于IO级别的同步，而这个同步和Oracle的写操作是不完全一致的，所以备份数据库存在几个疑问： n 疑问一：灾难产生时，备份系统的Oracle是否一定能够起得来？ n 疑问二：即使Oracle能够起得来，数据是否一定都能够读取？ n 疑问三：灾难切换后系统的性能是否处于正常状态？ 不足四：无法避免物理错误（如磁盘坏块），导致数据不一致、不安全 由于磁盘阵列/存储卷/虚拟容灾方案是采用基于IO级别的同步，无法解决磁盘经常出现的物理错误，例如：数据库坏块，这是Oracle数据库经常出现的典型问题（我们可以提供许多实例）。因此，基于磁盘阵列/存储卷/虚拟容灾的方案将面临数据丢失的风险。 而数据库复制技术则不会有这样的问题。 2.2 推荐采用“RealSync产品” 要建立查询数据库的关键技术，就是数据库的实时复制。 目前****医院是采用的Oracle数据库，而实现Oracle数据库数据实时复制的产品只有两类方案，一是Oracle自带的工具，二是第三方的数据库复制工具。 而Oracle自带的工具在资源占用、效率和功能等方面，还满足不了****医院现有系统的需求，因此在本方案里，DSG推荐采用Realsyc产品，该产品目前在业内应用范围广泛，主要实现如下功能： (一) 核心业务的灾备平台 通过数据同步建立灾备中心可以实现对业务关键数据的容灾及保护，在不影响生产数据库性能的同时为生产数据库在本地或异地建立一份准实时镜像，以保证在生产数据库发生灾难时可使用容灾数据库进行业务接管和数据恢复。 (二) 业务负载分担 由于复制的第二数据中心的数据处于实时可读取状态，数据库处于OPEN状态，从而实现系统业务模块的重新部署。 通过第二数据中心实现对核心系统的业务模块进行负载分担，将那些只对数据进行读取操作的模块都迁移到第二数据中心上来，主要包括： ü 提供帐务和话单实时查询； ü 提供统计报表运行； ü 提供经营分析数据抽取；提供其他系统的数据访问接口； 社保卡怎样查余额这样作将达到两个好处： ü 提高数据访问的效率，提高外围系统部署的灵活性； ü 提高核心系统的运行效率，提高核心系统运行的稳定和可靠性； 2.3 为什么推荐RealSync产品 我们建议采用DSG RealSync软件的原因在于： 1. 提供可靠的应急切换，避免物理错误的复制 实现对业务关键数据的容灾及保护，打开的Oracle数据库确保在业务切换时数据库一定可以打开接管业务，避免了数据库可能无法启动的风险；DSG Realsync是基于交易指令的复制，因此对于那些产生坏块，或者是文件被破坏等操作将不会在目标系统重现。 2. 支持不同硬件平台之间的复制 RealSync技术是逻辑级的数据复制技术，因此对于生产系统和目标系统来说，其硬件平台可以属于不同的厂商、不同的型号，亦可采用不同的操作系统等等。它的优点在于：一方面，在系统建设时，为用户提供硬件平台的灵活选择空间；同时，提供了在同一解决方案架构下，实现企业不同平台上的多个信息系统的统一复制的支持。 如支持UNIX/AIX---Linux的复制容灾，大大节约成本。 3. 复制目标数据库处于OPEN状态、数据是实时的、可以支持实时数据库访问 RealSync维护的容灾数据库在数据复制过程中始终处于打开状态，客户可通过打开的Oracle数据库实现快速切换，且在目标端数据库提供数据查询、报表和ETL抽取等功能，实现业务分担；满足此次提供的业务需求。 4. 按需复制，满足业务需求，降低存储成本和网络成本 根据客户建设管理数据库的业务需求，很多情况下，仅仅对需要的数据表信息进行复制，realsync软件完全可以支持这类需求，这样也可以减轻复制的压力、减少存储和网络带宽的成本。 5. 对生产系统的低干扰性 DSG实时数据复制技术不需要通过任何数据库的引擎来获取变更数据，而是通过数据库自身的信息获取源系统上的改变并传送给目的系统，这不会对生产系统造成性能影响。 6. 提供不停业务的首次全同步功能和单表修复功能 RealSync还提供目标端系统数据初始装载功能支持，将主系统上的已有存量数据，在不中断业务的情况下平滑的装载到目标数据库上。这是realsync软件独有的功能。 7. 支持长距离复制、更低的网络带宽要求和运行成本 目前Realsync 是全球同类方案中要求最低的，交易级复制软件仅需要在网络上传输的量为Oracle redo log的1/3，一方面比Oracle DG的带宽要求低，当然更远远低于磁盘阵列、卷文件、虚拟存储复制所需要的带宽。 8. 成熟的产品、稳定的应用 DSG从2002年在中国成立以来，在RealSync这个数据库复制产品的项目实施方面也经过了很长的一段路。DSG始终以“客户需求为导向”的原则发展自己的产品，到目前为止，DSG RealSync产品已经在数据量超大的电信行业、安全性要求极高的金融行业、环境较为复杂的政府和企业中被广为采用，主要包括： l 电信行业：北京移动、广西移动、甘肃移动、贵州移动、青海移动、澳门电信、广西电信、陕西电信、贵州电信、四川电信、山东电信、内蒙电信、河北电信、辽宁电信、吉林电信、江西电信、云南电信、安徽电信、海南电信、福建电信、甘肃电信、宁夏电信、新疆电信、广东电信、杭州电信、舟山电信、绍兴电信、湖州电信、辽宁网通、山东联通、江西联通、福建联通、广西联通、湖南联通、江苏联通、四川联通、吉林联通、广东联通、贵州联通、湖北联通、内蒙联通、贵州联通、云南联通… l 金融行业：广发银行、太平洋保险集团、上海黄金交易所、中国金融期货交易所、中国期货保证金监控中心、天平保险、华夏基金、易方达基金、金元比联基金、友邦基金、招商基金、南方基金、鲁证期货、中银期货、东吴期货、信达期货、西部期货、国泰君安期货、鲁能金穗期货、东航期货、中原期货、中大期货、广发证券、银河证券、民族证券、宏源证券、新时代证券、上海证券、远东证券、太平洋证券、东兴证券、万联证券、金元证券、信达证券、江南证券、华泰证券、南京证券、信泰证券、东吴证券、长江证券、国联证券、东海证券、西南证券、山西证券、金通证券、中原证券、财达证券、西部证券、国盛证券、国海证券、华福证券、恒泰证券、湘财证券、华鑫证券、财富证券、中天证券、财通证券、国金证券、中投证券、华欧证券、中邮证券、德邦证券、爱建证券、华宝证券、联合证券、日信证券、英大证券… l 政府行业： 国家知识产权局、北京电力、四川电力、河南电力、江西电力、青海电力、吉林电力、湖南电力、安徽电力、宁夏电力、天富热电、厦门电力、河北省地税、重庆地税、深圳地税、深圳市统计局、武汉财政、上海松江财政、吉林省交通厅 、辽宁省征稽局、蛇口码头、宁波港、江苏省航道局、江苏农垦、无锡公积金、贵州公安、东营公安、青岛有线、泰州社保、南通社保、阿克苏社保、太仓社保、中国一汽、济南钢铁、南京军区总医院、格力电器、深圳神州通集团、深圳统计局、阿里巴巴、河北省地税11地市征管数据集中容灾备份系统、江西省电力12地市营销数据集中容灾备份…… 2.4 RealSync在应急灾备方面的特点 l 零时间数据库切换的热容灾： 系统恢复时间是指当主系统出现故障不能在短期内恢复，而需要启动容灾端系统时，容灾端系统启动的时间。该时间不仅仅是指容灾端的硬件系统启动，更主要的、也是更耗费时间的是容灾端数据库系统的启动、业务系统的启动和外部接口的切换等。其中又以数据库的启动最为耗费时间，因为容灾端数据库不属于正常下线，因此重起时需要作许多检查和恢复，花费的时间非常长。 RealSync维护的容灾数据库系统在数据复制过程中也始终处于打开状态，保证数据复制在逻辑上的完整性，保证灾难切换的时效性和可靠性，RealSync技术为源系统提供了永远可用的后备数据库系统。在源系统出现故障时，应用系统可实现实时访问备用数据库系统。达到数据库系统的零切换目的。 打开的备份数据库保证数据复制在逻辑上的完整性，为源系统提供了永远可用的后备数据库系统，确保容灾系统的可靠性。 当源系统出现故障时，应用系统可实现实时访问备用数据库系统，无需重新启动备用数据库，达到数据库的秒级切换目的。 l 异构的系统平台，开放的硬件选择： RealSync技术是逻辑级的数据复制技术，因此对于生产系统和容灾系统来说，其硬件平台可以属于不同的厂商、不同的型号，可采用不同的操作系统等。它的优点在于：一方面为用户提供容灾系统建设时，硬件平台的可灵活选择空间；同时提供了在同一容灾解决方案架构下，实现企业不同平台上的多个信息系统的统一容灾支持。 l 支持从高到中低端应用需求： 由于RealSync在建设容灾系统时，对服务器、存储阵列和传输带宽要求都无特殊要求，而不同于传统容灾技术要求高端磁盘阵列、高端服务器、数GB的传输带宽，所以该系统适应于高端的电信、金融客户、也适合中端的政府机构、大型企业、同时也适合于运行PC平台的中小型企业应用。 l 投资回报分析（ROI）： 采用RealSync容灾技术，容灾数据库始终处于打开状态，不同于其他模式下容灾数据库系统不可用的状态。因此，可以通过RealSync维护的容灾系统，提供数据共享服务： 为决策分析和报表系统提供快速的数据抽取功能 提供准实时脱机查询，提高查询效率 为试验系统提供真实的生产数据 将以上本来需要在主系统上运行的业务与生产系统完全隔离，充分利用容灾系统的资源，实现企业应用负载分担，减少对生产系统的影响，提高服务系统响应效率；从而将容灾系统这个成本中心转化为利润中心。 l 灵活的组网结构和低带宽资源需求 RealSync采用交易（Transaction）传输方式，极大的减少了复制过程中需要传输的数据量。使得在网络上传输的数据量大大减少，要求更低的网络带宽。 Realsync支持标准的TCP/IP网络传输，用户可灵活布建容灾网络架构。 系统可支持1:1、N:1、1:N和双向容灾结构支持，提高企业容灾结构的灵活性。 2.5 RealSync在报表分担、数据共享利用等方面的特点 l 按需复制 查询和统计系统往往不需要所有的原始数据，因此完全可以按需要复制数据。RealSync系统支持对指定信息的按需复制，如指定需要复制的表、字段和条件等，减少存储和网络带宽的成本。 l 实时数据更新 实时更新保证副本系统快速反映源系统的变化，提供账单查询、话单查询等的及时性。经过大量的测试，实时数据复制技术使源系统和目的系统的数据延迟<10秒。 l 对生产系统的低干扰性 DSG实时数据复制技术不需要通过任何数据库的引擎来获取变更数据，而是通过数据库自身的信息获取源系统上的改变并传送给目的系统，不会对生产系统造成性能影响。 l 系统异构，可提供更多的优化空间 源数据库系统和目的数据库系统的可异构，主要包括索引规则和存储参数（如数据块大小、回滚段等）。因此可以在目标数据库上根据业务特点进行调整和优化，完全不受源系统的限制。 3 方案设计 数据库同步复制软件是****医院实施关键系统灾备工程的一个重要组成部分，当生产系统出现异常或故障时，备份系统的数据库能够完全代替生产系统的Oracle 数据库管理系统，以实现关键系统的正常运行。 l 业务功能实现： 在关键业务应用系统的数据库上安装复制软件代理程序，通过代理程序获取数据库的交易，实现数据变化的实时跟踪。抓取的数据通过1000Mbps以太网进行实时传输，实现系统数据同步到备份系统上的实时传输。 l 技术实现： 复制软件是采用交易复制的方式进行数据同步；灾备数据库上的Oracle数据库处于OPEN状态，可提供实时数据访问；如可将生产系统上的统计查询等业务运行在历史的Oracle数据库上，数据复制的时延可以空载在3-5秒左右；具体细节如下： 历年高考满分作文3.1 方案设计 根据以上系统状况和功能要求，本期项目将采用1套Realsync数据库复制软件来完成： 根据业务需求，在关键系统安装DSG RealSync程序，该程序对ORACLE数据库产生的redo log进行实时分析，生成sql语句。并将sql语句通过IP网络传输到历史数据库。 3.2 Realsync软件配置 DSG realsync软件的安装分为生产系统和目标系统两个方面： n 生产系统上： DSG realsync在每个数据库实例都要安装一个production agent，用来分析本agent产生的redo log数据。 n 目标系统上： DSG reasync在备份中心的服务器上，分别安装一个realsync，但需要为每个instance启动一个destination agent port。
各模块的作用： RealSync for Production Server： 安装在源系统（Data Source）上运行数据库实例的服务器上，每个数据库实例配置一个License； 该模块中又包含以下功能： ü Analyzer Module：日志分析功能 ü Synthisizer Module：交易合成功能 ü sender Module：数据传输（输出端）功能 RealSync for Destination Server： 安装在复制目标系统（Data Target）上运行数据库实例的服务器上，每个数据库实例配置一个License； 该模块中又包含以下功能： ü Importer Module：数据传输（输入端）功能 ü Loader Module：交易指令装载功能 RealSync Full Sync 首次全同步功能； 提供从源数据库上把已有的存量数据初始化同步到目标系统上来，即将源系统上的所有表的数据export出来传输到备份系统上import进去，实现初始数据的同步。 该模块的特点是在初始化过程中无需业务停机，而且可以多路并发，可处理全同步过程中的变量数据。 RealSync management console： 管理控制界面； 3.3 性能和资源需求估算 在关键业务系统中的应用，性能和压力是复制软件的核心，是每天每时每刻都用到的，尤其是在业务高峰期情况下，能否跟得上日志的产生速度、能否不大量的占用系统资源、能否保证复制的及时性是整个数据库复制软件产品最为核心的内容。 根据我们在各种国内的几十家应用情况显示来看DSG RealSync在实时复制方面的性能是同类产品中领先的。主要体现在： n 网络需求 RealSync对数据传输采用TCP/IP网络传输。RealSync复制操作只是读取操作系统的日志文件，同时通过TCP/IP方式而不是采用中间件方式传输只发生改变的数据也使网络负载降至最低。RealSync只将日志的三分之一的内容通过网络进行传输。实际每小时传输的数据量=每小时日志文件切换的数量*日志文件的大小*1/3。根据估算，如客户每天产生的日志量约为10GB，我们按照80%的日志量在1天的20%时间内（这里设为4小时）产生的，那么我们可以估计高峰期的日志量为8GB/3*1024*1024/(4*3600)=1.5Mb/s。同时为了预留一定的带宽，建议将带宽作为10Mbps就能满足日常的复制需求。本项目的带宽情况完全能够满足要求。 n 日志分析速度 我们采取了积压日志分析的方式进行测试，利用rac环境下的两台服务器同时产生10GB的日志数据，然后启动realsync测试其在多长时间内能够分析完这些数据。测试结果表名，在rac模式下，由两个数据库节点同时工作，在5分钟内产生的10GB归档日志，共计800万条记录，realsync只需要2分钟40秒即能分析完累积的日志，约9分钟装载完成。日志分析的速度远远高于产生日志的速度。完全能够满足用户IT系统的业务需求，即使是在业务高峰期，也不会造成日志累积。目前DSG的用户中，广西移动每天的增量日志达到600G，realsync依然稳定运行。 n 每秒钟复制的操作数 在测试过程中，我们采用PL/SQL方式在源端产生1万,10万，100万条记录，以及进行1万,10万，100万的update,delete操作等。按照统计结果，DSG RealSync达到平均18000条/s的复制速度。完全能够满足单系统上用户IT系统的业务要求。 n 复制数据延迟 RealSync是一种异步准实时的复制技术，其数据延迟非常小。数据延迟的周期可以设置，在生产系统中，数据延迟和源系统复制事物的多少，事物的处理方式有关，以及跟设置的log数据轮询周期有关。在复制数据量正常的OLTP系统中，数据延迟一般在几秒钟。如果每天产生30GB的日志量，在30Mb带宽的情况下，可确保数据的延迟在5秒钟左右。 n CPU资源占用 DSG RealSync通过Oracle日志获得数据的变化信息，它独特的技术优势使得它对源系统的资源占用很小。在生产系统中，实际对源系统的影响和源系统复制事物的多少，事物的处理方式有关。在复制数据量正常的OLTP系统中，正常状态下对CPU资源的占用为<5%的CPU资源占用。根据我们在河北地税的使用情况来看，在系统高峰期每2分钟产生100MB的日志量，而REALSYNC的日志分析资源占用仅为2%（4cpu,8G ram）。 n 源端的缓存空间 当灾备中心暂停或传输异常中断导致复制停止时，RealSync会将数据库的变化内容存储在源系统或目标系统的队列中，当系统恢复后，RealSync会自动识别复制环境，自动从断点处开始复制工作。在上述过程中，主中心的业务不受任何影响。数据的一致性不会破坏。当复制环境停止的情况下，需要在源系统和目标系统上存储的空间和业务系统每天峰值的日志数有关。根据每天平均产生25GB的日志计算，我们建议在源端给REALSYNC预留的缓存空间能够满足一天的缓存量：按照1/3的比例计算并增加一定的富裕量，需予留10GB的缓存存储空间。 n 业务切换 RealSync是通过对Oracle Log日志进行分析获取跟踪源系统的交易指令实时的将指令传输到目标端进行加载，且目标端数据库始终在OPEN状态，可实时在目标端进行查询和统计，所以当灾难发生时或在主机源端发生故障以后，可直接将生产端数据库切换到容灾端，目标端数据库不需要重新启动，确保目标端数据的可用性，并大大提高了RTO、RPO指标。 3.4 系统实施概述 （一）系统安装 REALSYNC的安装点包括如下： l 在每个系统的数据库服务器上（RAC环境下是安装在一台服务器上，一个服务器上有多个INSTANCE时，需要为每个INSTANCE安装一个Realsync Agent），配置一个REALSYNC AGENT，启动一个agent端口； l 在灾备中心的每个服务器上安装一个ORACLE Agent，但要为每个instance启动一个agent端口； （二）首次全同步 首次全同步是此次项目中一个非常复杂的问题，因为如何将生产系统首次同步到查询中心是一个非常复杂的问题，也是本项目中的一个难题。 复制环境的建立，首先需要将生产系统中的已有数据初始化同步到目标系统上，同时记录各种系统状态和映射关系等。因此如何快速、有效的建立复制的初始化环境是每个复制系统都非常关心的问题。 全同步是关键系统中一个非常复杂的问题，因为如何将生产系统首次同步到灾备中心是一个非常复杂的问题，也是本项目中的一个难题。 从目前的技术来看，能够实现首次全同步的方式有多种方案： 第一：备份/恢复的方式 第二：ORACLE EXPORT/IMPORT方式； 第三：采用复制软件自带的首次初始化功能。 在传统办法中，数据首次同步过程大都采用Oracle的EXP/IMP工具，将源端数据库数据抽取出来，通过网络传输至目标端数据库进行加载。或者是借助第三方的备份软件工具，将源端的数据进行备份，再通过磁带运输至目的地，将磁带数据恢复到目标数据库，从而达到首次数据同步的目的。 这种方式存在大量的问题： （1） 性能低下：通过Export/Import方式，最大的问题在于性能很慢，对于一个几十GB的数据库，进行一次export/import，则大约费时8－10小时以上。 （2） 完全需要手工干预：数据的导出（Export），传输和装载（Import）等过程都需要手工干预和执行。 （3） 业务必需停止：在执行export/imp过程中，业务必需中断。 （4） 易出错：尤其在Import过程中，由于表之间的关联性存在，往往出现由于违反参照完整性规则而导致装载中断，非常难于操作。 根据关键系统的需求来看，我们在作首次同步的时候必需满足以下几个条件： 一：大数据量下如何快速首次同步 二：如何简化首次全同步的操作步骤 三：如何作到首次全同步过程中对生产业务不造成影响 四：如何支持异构环境下的数据首次同步？ 根据以上几个条件，我们认为采用DSG realsync自带的首次全同步功能才能够简化首次同步的操作复杂程度。因为前两种方式无论在操作复杂程度上，还是是否需要停止业务方面都表现得不好，主要在于： l 备份/恢复方式：数据量大，无法通过网络传递； l exp/imp：数据量大，导出时间漫长。同时导出时需要停止业务。 而DSG在数据的一致性同步方面有着非常好的解决方案，这是其它方案所不具备的。DSG的RealSync集成有数据的一致性同步工具，能够自动化的进行数据的首次同步和出现差异情况下进行一致性同步的工作，无需人工干预，维护工作量小，且大大提高了工作效率： （1） 速度快：对于几十GB的数据量，在正常情况下，只需要1小时左右完成初始数据同步。 （2） 完全自动化：采用DSG RealSync只需要１条命令就完成系统的初始化工作，系统自动进行导出、传输和装载任务，完全无需人为干预，减少出错机会。 （3） 不中断业务：在DSG Realsync在进行首次数据装载时，无需停止源端业务，实现不停机的系统初始化； （三）全同步实施步骤 对于一个数据库的全同步过程包括： 1. 在容灾端安装ORACLE数据库 因为容灾端是两个ORACEL INSTANCE，创建ORACEL DATABASE。 2. 启动实例并create database 采用逻辑同步方式，必需手工在目标端建立好instance和database. 为了确保目标端的性能最优，可采用与生产数据库相同的参数。使用源端的SPFILE参数。 3. 创建tablespace和user tablespace和user由管理员创建。DSG可以提供导出脚本的程序帮助管理员生成现成的脚本，管理员只需要作简单的修改后就可在容灾系统上创建。 4. 调用realsync的set dict命令创建所有的用户对象 DSG 提供了的set dict命令用于在目标端创建与生产端相同的所有objects。包括：functions、procedures、packages、types、triggers、java sources、jobs、libraries、directories、tables(含indexes,constraints,grants)、views、sequences、profiles、roles、synonyms、database links等 5. 数据抽取与装载 执行命令set dm 1.1 account account –sync ftciq –th 20进行数据的同步，系统自动进行数据抽取、传输、装载，并自动分析其间产生的日志。无需人为干预。 当存量数据装载完后，系统自动利用期间产生的日志进行数据的修补到一致状态。 首次同步结束后，系统自动进入到增量实时复制阶段，不需要人为干预。 （四）时间估算 根据生产系统为40GB的量计算，在4Mb带宽下，全同步的时间主要是数据传输时间和目标端装载时间。 数据传输时间： 40GB的数据量经过压缩后约为10GB左右，按照4Mb带宽计算为： 10GB*1024*8/4Mb/3600=5小时。 按照一定的富裕量计算，可在6小时左右完成数据的首次全同步。 因此对于40GB的数据量，根据工程性能指标参考，可在6个小时左右完成全同步。 （五）开始实时复制 当对系统的初始化环境工作结束后，RealSync自动进入实时复制状态，无需手工干预。 4 RealSync产品原理 目前此类软件没有相应的技术标准，因此特将RealSync软件的原理展示给大家，作为评判的标准。 示意图： 如上图所示，RealSync在Data Source端和Data Target端分别安装Agent进程，Source端的Agent进程对ORACLE日志进行监控，发现改变及时对目标数据库进行更新。 当应用系统在Data Source端向数据库进行任何操作时时，这些信息都将在Redo Log中保存，RealSync Agent通过对实时获取的Log日志进行分析，获得本次操作的交易指令和交易数据，然后将这些交易指令和交易数据经过格式转化生成DXF数据格式，并实时通过网络传送到Data Target系统。 Data Target系统的RealSync Agent接收数据库包，经过校验码检查，确认正确的数据库包后，调用Oracle函数按照交易的先后顺序在Data Target系统中执行该交易。 4.1 日志抓取（Data Capture） RealSync对数据的抓取是通过安装在Data Source端的Agent模块定时分析Oracle Redo Log来获取Data Source端的交易类型及数据的。 RealSync Agent在判断Data Source端的Oracle系统是否有新的交易产生时是通过定期检查Oracle Controle file中记录的当前SCN号来判断的，这样避免每次检都通过读取log文件来判断否有新的交易产生时造成的系统影响。 在Controle file中确认有新的交易产生时，可以同时获得当前的Redo Log 组，以及最新日志在日志文件的最新位置。 RealSync Agent模块根据这些信息将上次抓取时记录的日志位置与本次读取的最新位置之间的Log读取并加以分析。然后将这些数据保存在Online Log Cache文件中，等待下一步作交易合成处理。 RealSync的优势： 与其他类似日志复制产品相比，RealSync对日志进行分析，得到交易信息再进行传送；而其他类似产品不对日志作分析，传送全部日志，然后在目标端通过日志作Recover， 这样一来，不仅传送数据量大，而且目标端数据库不能打开。 4.2 日志分析（Analyze） Oracle数据库的所有更改都记录在日志中，其中记录了对数据库中的每一个变化。 当我们候需要需要了解数据库中所作的交易时，一个最有效实用而又低成本的方法就是分析Oracle数据库的日志文件。 RealSync Agent中集成了DSG的优秀日志分析功能，该功能完全不同于Oracle提供的Logminer日志分析工具，在性能和功能上都大大提高，主要体现在系统性能的优化上，大幅度提高日志分析的速度，使得对于高并发业务系统的复制成为可能。按照RealSync的日志分析设计目标，每秒能够分析的日志量达到10M/s。 RealSync通过对日志的分析，得到该数据库中的每个SQL指令，并将这些SQL指令生成DXF（DSG Extend Format）格式的表达方式。 DXF格式是DSG公司的专有技术，该技术是DSG公司用来表达SQL指令的方式，该数据格式能够通过DSG的专有转换算法能够直接转换为ORACL的内部数据表达格式，从而在分析和转载时需要最小的转化，提高分析和装载速度，减少资源占用、丰富能够表达的各种数据类型。 4.3 交易合成（Synthesize） 通过ORACLE REDO LOG分析的交易指令存在如下的几个特点： （1）这些指令是交叉出现的，属于一个交易（Transaction）的多条SQL指令是非连续存储的，多个交易的SQL之间是相互穿插的； （2）Redo log中记录了所有的commit的交易以及没有commit的交易； 所以，为了提高系统的可控制性、保证逻辑完整性、避免数据丢失，最好将复制的最小单位为一个交易（Transaction），而不是以单个SQL指令为复制单位，这样在Data Target端的交易装载更加容易控制。 同时，对于复制的数据而言，只有那些Commit的数据对于Data Target端系统是有意义的，而对于那些Rollback的数据无需复制到Data target系统上。 所以RealSync在复制过程中不是复制每个SQL语句，而是对抓取的数据进行交易整合后以交易（Transaction）为单位进行复制，同时只复制COMMIT的交易。 如上图所示，在Online Log Cache文件中，包括Commit的交易，没有Commit的交易和Rollback的交易。交易合成模块首先按照交易序号对SOL语句进行划分，每个交易包含多条SOL语句。然后，以交易为单位进行处理，将已经Commit的交易，传至传输处理模块；将未提交的交易保存在本地，一旦通过日志得知保存的未提交交易已提交，立即将该交易发送到传输处理模块；对Rollback的交易作丢弃处理。 RealSync的优势： RealSync是以交易为单位进行传输的，而不是以SOL语句为单位进行传输的，更容易保证数据的一致性和完整性。 4.4 交易传输 RealSync技术为了保证数据传输的安全、可靠，在传输处理上作了特殊的处理与支持: （1） 数据在传输之前首先存入Data Source端的Cache，传输进程（Export Process）从Cache中读取交易数据封装为TCP/IP数据包传送给Data target端的Import进程。 （2）在data target端，Import进程在收到传输的交易数据包后，首先存入Queue，然后由Load进程从Queue中严格按照交易的顺序装载交易信息。 如上图所示，负责传输的进程（Export Process）从本地队列中按照先进先出的原则抓取需要传输的交易，将交易数据封装成一个数据包后通过TCP/IP协议传递给对端系统。在封装的数据包的包头部分描述了包的大小。 对端系统在接受到传来的数据包后，首先根据包头描述的包大小进行传输的合法性检查，判断是否传输完整。 4.5 数据装载 在传统的复制技术中，常用的数据装载方式是采用Oracle 的SQL接口，通过Insert、Update、Delete等SQL语句实现数据的装载。这种方式在通用性上很好，但关键在于性能问题非常突出。 SQL语句的执行需要经过parse、plan、格式转换等过程，造成大量的系统开销。尤其是update和Delte操作的大量Where子句操作需要进行复杂的查询定位任务，从而导致装载性能低下，对处理能力的要求比生产系统的还高。 DSG RealSync在设计之初就定位于电信级大数据量系统的应用，因此在装载性能上进行了大幅度的改善，使得装载端的性能和处理能力需求降至最低。 在其中DSG RealSync采用了两个关键的技术提高了装载速度： （1）采用DXF数据格式的装载； （2）采用Rowid mapping的方式实现快速定位； (一) 用DXF数据格式的装载： DXF（DSG Extend Format）格式是DSG公司的专有技术，该技术是DSG公司用来表达SQL指令的方式，该数据格式能够通过DSG的专有转换算法能够直接转换为ORACL的内部数据表达格式，从而在分析和转载时需要最小的转化，提高分析和装载速度，减少资源占用、丰富sql语句的表达方式。 Oracle数据库系统在设计上提供了4个层次的接口，其中包括User层，SQL层，Transformation层和I/O层。其结构为： 在这四层当中，当采用SQL接口进行数据装载时，调用的是User层， 而DSG RealSync通过DXF数据格式装载时，调用I/O层直接将数据通过Oracle的最底层函数写入系统中，所以DSG RealSync在装载层上有一定优势； (二) Row mapping实现快速定位 对于交易中的操作，存在着大量的Where子句操作，在采用标准SQL语句执行这些操作时，系统需要首先定位目标记录所在的数据文件的位置信息，这将带来大量的索引查询开销，当并发执行数千条指令时，系统的开销将变得非常庞大。 DSG RealSync工具不采用该方式实现装载数据的定位，而是通过ROW Mapping的方式实现记录的快速定位： 当RealSync从源端Log文件中读取交易数据时，将获得该交易对应记录的所在位置，用rowid表示为rowid_ds； 当该交易在目标端装载时，系统不翻译为Where子句，而是去通过保存在目标端的row mapping表获得对应目标端该记录的所在位置rowid，记录为rowid_dt。 从而在目标端装载时通过rowid能够直接定位于该数据需要写入的位置。避免了大量的索引查时间。 每条记录的row mapping信息是在该记录执行insert操作、sql loader或首次批量同步时建立起来的。 RealSync的优势： DSG扩展格式DXF(DSG Extend Format)是RealSync产品的一个核心技术，是一种最高效率表示ORACLE记录的数据格式，该格式只需要经过最小的转换过程就能够装载到ORACLE数据库中，并且装载效率非常高。 n 无需标准SQL语句执行的复杂过程 n 加快装载速度 n 对于Update，Delete等带Where子句的交易，可以大幅度提高装载速度 5 应急响应方案与灾备演练计划 5.1 容灾管理规划 众所周知，容灾不是简单的设备冗余。除了IT技术方面的设计，还应着重考虑管理层面的问题，例如灾难管理组织结构、灾难恢复流程等。灾难管理组织结构中定义了灾难发生前、中、后，各相关人员的职责；灾难恢复流程书面化各恢复工作的流程和执行步骤。BCP和DRP中应包含以下内容： l 灾难管理组织结构 l 应急响应流程 l 灾难评估流程 l 灾难恢复决策流程 l 容灾系统启动流程 l IT系统切换和回切流程 l 业务验证流程 l 业务恢复流程 l BCP或DRP的管理方法 l 容灾演习的规划 5.2 复制软件的日常维护 作为realsync软件的运行，日常维护也是非常重要的方面，维护的内容主要包括： l 检查复制软件是否运行正常 l 启动和停止复制任务进程 l 排除复制过程出错的错误 l 检查复制的工作状态是否与业务需求有较大偏差 l 数据一致性的检查 l 修复不一致的数据 l 维护容灾端Oracle数据库工作状态 以上是针对复制软件日常维护需要作的事情 5.3 人员组织结构规划 根据容灾项目的运行维护特点，一般要求容灾项目的部门、个人的设置包括如下几个方面。 容灾项目领导小组 l 对容灾项目总体负责 l 制定项目组工作制度 l 制定项目计划 l 跟踪项目过程 l 控制项目变更 l 审核项目成果 l 评价项目组成员、部门的工作情况 l 协调项目所涉及的内部及外部资源 l 为项目组各部门提供良好的沟通渠道 l 召开项目评审会，组织项目验收工作 容灾项目经理 l 作为技术负责人和技术经理在容灾系统建设件领域有多年的经验 l 有丰富的不同类型容灾技术实施方法的分析和设计的经验 l 有经验于容灾的设计研究，可能采用的容灾系统设计模型/方法 /工具的拟定，以至于容灾系统的二次设计 l 定义灾难管理框架 l 规范灾难管理流程 l 制定业务连续性计划规范 l 协助客户建立灾难管理组织结构 l 协助并指导业务连续性计划的开发 l 制定灾备测试要求 l 主持制定灾备演练计划 l 主导灾备演练并给予指导 l 其它相关咨询工作 系统专家 结合关键系统的实际情况、容灾项目的具体要求为数据中心异地容灾项目提供有效、稳定、高效、可靠的运行优化，系统技术部分包括： l 服务器和UNIX操作系统管理员 l 磁盘阵列和SAN存储管理员 l ORACLE数据管理员 l 中间件技术管理员 l 应用程序管理员 l 数据库复制软件管理员 网络专家 复制容灾项目中的网络建设、尤其是容灾切换过程中的网络切换过程专家。 5.4 《重大故障应急备份切换方案》 安装情况不同，备份切换分为备份数据库的切换，服务器切换、存储切换以及其他子系统的切换。分别描述如下。 （1）基于DSG系统的数据库灾难恢复步骤（灾备中心）： 在生产数据库系统发生灾难的情况下，此时可使用容灾数据库首先接管业务，然后进行数据的反向恢复，最后进行时间一致性检查，恢复系统正常状态。 在生产数据库系统发生灾难的情况下，此时可使用容灾Oracle数据库，首先接管业务，然后进行数据的反向恢复。DSG系统的具体步骤为：
以上过程是利用灾备中心的系统首先接管业务后，再进行生产中心的修复和数据的反向复制，因此不会造成长时间的业务中断。 （2）数据一致性检查: 对于ORACLE而言，数据一致性的检查主要是通过数据库的SQL接口读取记录，进行对比的方式进行。而这种比对方式耗时巨大，效率十分低下，如果对于一些没有主键的表就几乎无法比较。 DSG在数据一致性校验的检查机制方面做的尤为突出，并且使得这一需求变得可行。在其它同类产品中，DSG Realsync不是通过select接口来读取数据并进行比较，而是通过批量读取的方式从数据库底层直接读取记录，并通过rowid的对应关系来定位记录，并通过数据源的记录值、ROWID，目标端的记录值、ROWID，以及Realsync所记录的ROWID映射关系来比较双方的记录是否一样。 这种方式省却了大量的从select接口查询记录的资源占用和时间消耗。并且能够比较到每条记录，能够清晰定位不一致的记录。无论被比较的表含有主键或者没有主键，都能进行比较，并且比较的性能一样。 （3）系统恢复计划:
5.5 《重大故障应急方案演练计划》
5.6 《系统巡检报告》 《&&&&公司巡检报告》
本次质检内容 质检详细描述：
客户意见及签字：
客户服务中心反馈情况：
6 DSG公司简介 DSG是全球领先的数据与存储管理软件提供商。在当今存储行业把备份、SRM和数据复制作为存储软件的三大主流方向的时候，DSG已经提前两年在这三个领域方面取得了突破性进展，推出了DMP系列产品，推动了数据管理领域的变革。 DSG努力成为全球最大的数据与存储管理软件提供商，提供优秀的数据管理软件和数据安全、灾难恢复、数据抽取共享、数据归档检索和一体化管理平台在内的解决方案。 6.1 DSG成立和组成 DSG北京公司于2002年8月在北京成立，同时被授予“高科技企业”的称号。DSG公司的前身是DSGuardian Inc.公司，注册于美国，早期致力于大型企业应用系统的调优服务，曾服务于波音、通用汽车、SONY等国际知名企业。 DSG公司技术核心人员来自IBM、ORACLE等美国IT领先企业，他们长期担任关键技术职务，在数据存储管理、企业信息处理方面有丰富的实践经验和专业的技术知识。 DSG公司在美国于1996年开始软件研发，具有完全知识产品的数据保护和容灾产品。DSG陆续推出新一代的磁盘备份技术（SnapAssure）、异构热容灾技术（RealSync）、数据复制和抽取技术（SmartE）以及数据库日志分析技术（Ologx），并投放市场，深受用户好评。 6.2 DSG业务范围 DSG-迪思杰（北京）数码技术有限公司是业界专注于为用户提供数据管理平台解决方案和服务的提供商，提供的产品和解决方案，包括： ü 高速数据备份和恢复解决方案： SnapAssure ü Oracle数据库复制和容灾解决方案：RealSync/SmartE ü 备份数据共享和业务部署支持方案：SnapShare ü Oracle数据库管理工具包：日志分析（Ologx），快速数据装载（xf1ldr），快速数据导出技术（xexp）等。 数据库服务提供，包括： ü Oracle数据维护、调优 ü Oracle故障诊断和排除 ü Oracle数据库迁移、升级服务 ü Oracle数据急救服务 ü 企业信息模型规划和实施 6.3 DSG核心技术 DSG公司拥有的自主知识版权的关键技术： ü 获得美国专利的“版本压缩数据存储技术” ü 数据块增量备份技术 ü 数据库实时容灾复制技术 ü 异构分布式数据存储管理技术 ü 快速数据提取、装载技术和数据分析 6.4 DSG公司的业务方向 随着计算机应用系统的爆炸式发展，业务量迅速增加，业务种类日益复杂，企业必须管理不断增长的信息流量；随着信息量的急剧增大，核心数据的管理变得日益困难。如何安全、可靠地存储业务数据及满足未来业务数据高速增长的需要；如何有效管理日益增长的业务数据；如何实现业务数据的共享并在现有业务数据之上建立新兴的增值应用，如数据仓库、客户关系管理（CRM）等，成为了各企业建立信息系统的关键所在。 目前，各企业信息系统在数据管理领域存在着普遍的问题： ü 数据流通效率低下，企业信息孤岛现象严重 ü 数据报表、查询和数据共享效率低下 ü 系统安全保护、业务连续运行水平低下 因此，各企业比以往任何时候相比，管理和有效使用这些信息系统的能力高低都更能决定了长期生存和发展能力，因此比以往任何时候，企业都更关注于如下领域： ü 提高系统运行效率，提高业务报表、提高客户服务质量，并降低客户流失率。 ü 加强企业信息流通、提高企业信息的附加值、进一步挖掘企业信息价值、迅速开发和推广新业务，创造更多收入并保持竞争能力。 ü 提高信息系统业务连续运行能力，提高数据安全保护水平。 DSG公司凭借在全球数据保护、数据共享领域长期以来的积累，形成了包含数据流通、数据共享和数据安全保护在内的一体化的数据管理平台，为企业信息系统提供了统一数据管理基础平台（DMF）。 良好的企业数据管理基础架构，能够带来： ü 更灵活的业务系统部署，提高关键业务系统运行水平； ü 提高系统部署的延续性，避免分散建设的重复投资； ü 提高投资回收率，充分利用各种投资。 6.5 DSG在国内的主要应用客户 ü 中国电信：电信总部、北方电信9省、江苏电信、浙江电信、重庆电信、江西电信、广西电信、新疆电信、青海电信、海南电信、贵州电信、甘肃电信、宁夏电信、福建电信、成都电信； 辽宁高考数学答案ü 中国移动：江西移动、广西移动、甘肃移动、新疆移动、青海移动； ü 中国网通：辽宁网通、周口通信、沧州通信； ü 中国联通：广东联通、江苏联通、天津联通、辽宁联通、山东联通、陕西联通、四川联通、河北联通、重庆联通、吉林联通； blue什么意思ü 证券行业：银河证券、华泰证券、长江证券、国联证券、民族证券、金通证券； ü 政府机构：河北省地方税务局、新疆电力、上海市松江区财政局、广州公安、广西公安、新疆电力、杭州电力、东莞社保、江汉油田、辽宁交通厅、济南钢铁总公司等 ü 军队及其它：海军某部、火箭研究院、陆军某部、信息产业部（含浙江、江苏、陕西、黑龙江、福建、江西、甘肃、吉林、宁夏和重庆等信产部直属机构）； 7 DSG在类似项目的成功范例和相关经验 7.1 成功案例的列表 DSG从2002年在中国成立以来，在RealSync这个数据库复制产品的项目实施方面也经过了很长的一段路。DSG始终以“客户需求为导向”的原则发展自己的产品，到目前为止，DSG RealSync产品已经在电信、政府、政券和企业采用，主要包括： l 电信行业：北京移动、广西移动、甘肃移动、贵州移动、青海移动、澳门电信、广西电信、陕西电信、贵州电信、四川电信、山东电信、内蒙电信、河北电信、辽宁电信、吉林电信、江西电信、云南电信、安徽电信、海南电信、福建电信、甘肃电信、宁夏电信、新疆电信、广东电信、杭州电信、舟山电信、绍兴电信、湖州电信、辽宁网通、山东联通、江西联通、福建联通、广西联通、湖南联通、江苏联通、四川联通、吉林联通、广东联通、贵州联通、湖北联通、内蒙联通、贵州联通、云南联通… l 金融行业：广发银行、太平洋保险集团、上海黄金交易所、中国金融期货交易所、中国期货保证金监控中心、天平保险、华夏基金、易方达基金、金元比联基金、友邦基金、招商基金、南方基金、鲁证期货、中银期货、东吴期货、信达期货、西部期货、国泰君安期货、鲁能金穗期货、东航期货、中原期货、中大期货、广发证券、银河证券、民族证券、宏源证券、新时代证券、上海证券、远东证券、太平洋证券、东兴证券、万联证券、金元证券、信达证券、江南证券、华泰证券、南京证券、信泰证券、东吴证券、长江证券、国联证券、东海证券、西南证券、山西证券、金通证券、中原证券、财达证券、西部证券、国盛证券、国海证券、华福证券、恒泰证券、湘财证券、华鑫证券、财富证券、中天证券、财通证券、国金证券、中投证券、华欧证券、中邮证券、德邦证券、爱建证券、华宝证券、联合证券、日信证券、英大证券… l 政府行业：国家知识产权局、北京电力、四川电力、河南电力、江西电力、青海电力、吉林电力、湖南电力、安徽电力、宁夏电力、天富热电、厦门电力、河北省地税、重庆地税、深圳地税、深圳市统计局、武汉财政、上海松江财政、吉林省交通厅 、辽宁省征稽局、蛇口码头、宁波港、江苏省航道局、江苏农垦、无锡公积金、贵州公安、东营公安、青岛有线、泰州社保、南通社保、阿克苏社保、太仓社保、中国一汽、济南钢铁、南京军区总医院、格力电器、深圳神州通集团、深圳统计局、阿里巴巴、河北省地税11地市征管数据集中容灾备份系统、江西省电力12地市营销数据集中容灾备份…… 这些系统都为DSG RealSync的实施积累了宝贵的经验。 7.2 长江证券集中交易系统灾备应用 1、业务需求： 长将证券从2004年开始着手全公司大集中交易系统建设工作。集中交易系统的目的是实现所属所有网点数据大集中，涵盖长江证券目前现有业务(AB股，基金、债券、三板、集合理财、银证通、多币种等)，整合并兼容长江证券即将开展的保险、期货等可预见金融业务的集中交易系统。是一套集金融产品研发、销售、管理为一体的信息系统。 随着证券集中交易系统的建设，对系统的安全性、可靠性和业务连续性方面提出了很高的要求。因为该系统是长江证券的业务得以正常运转的前提和保证。 而大量的意外事件，如不可抗自然灾难（地震、洪水）、意外灾难（火灾）、战争、恐怖事件（如911）、外界因素电网、通讯等处界因素、运营中心容错措施失效等原因都将会导致集中交易系统的数据丢失、业务中断，势必造成巨大的经济损失。 为此，长江证券提出了建设一套高效、可靠、投资回收比高的灾难备份系统。确保系统的数据安全和灾难发生时的快速恢复。 2、解决方案 DSG作为数据管理平台解决方案的提供商，推出了包括数据安全、数据共享和数据生命周期管理等在内的全套数据管理解决方案。 该解决方案中的数据库复制技术realsync正是为数据复制和备份提供了最佳的解决方案。该软件在工作组和企业级的关键应用的容灾支持上，能够提供比竞争对手更低成本、更高投资回报、结构更灵活、更容易实施和维护的容灾解决方案，提供对主流Linux和Unix等跨平台的Oracle数据库系统的复制和备份支持。 在大型企业和数据中心级的关键应用上，RealSync是完全满足数据中心级每秒数千条交易量的实时复制支持、减少数据丢失。同事通过处于打开（open）状态的备份数据库提供数据查询、统计报表等支持企业应用模块的重新部署。 为此，长江证券选择了DSG RealSYnc作为其交易系统的复制和备份解决方案： 系统结构： 如图所示，长江证券集中交易系统容灾备份实现如下目的： （1） 本地复制： 将集中交易系统复制到局域网内部的系统上用于查询和本地业务接管功能； （2） 远程异地复制： 将位于武汉的集中交易系统远程复制到上海证通灾备中心，广域网链路2M. （3） 满足业务备份和恢复指标 要求灾难发生时数据丢量控制在最小范围之内，业务恢复事件缩短，减少对证券用户的交易影响。 支持平台： 数据库：Oracle 9.2.0.4 RAC 操作系统：HP-UX 应用效果和特点： 总的说来，采用DSG RealSync数据复制和备份解决方案，非常适合长江证券的业务需求： （1） 支持1:2的复制模式，满足一个数据源复制到多个目标数据库的业务需求 （2） 备份数据库出于打开状态，通过该打开数据库可用于分担集中交易系统的查询和统计等业务功能 （3） 支持异构模式的数据复制，支持数据源、目标数据库之间采用灵活的软件和硬件平台，而无需要求相同的操作系统和数据库版本 （4） 减少带宽占用，满足2M带宽的广域网复制需求 （5） 数据复制实时性好，数据复制频率可调整，复制周期可减少到秒级以内，减少数据丢失。 7.3 西北证券灾备一体化方案 西北某证券股份有限公司是经中国证券监督管理委员会批准设立，于2001年元月正式注册开业的证券经营机构，注册资本金壹拾亿元人民币，注册地为陕西省西安市，公司在上海设有投资管理、客户资产管理、投资银行、研发中心等业务部门，并在陕西、北京、上海、深圳、山东设立了22家证券营业部和14家证券服务部。 业务需求 win7换xp系统 西北某证券集中交易系统在2005年实现交易集中并升级到Linux + Oracle平台，系统稳定运行。2006年以来，随着中国股市转牛，交易活跃，系统所承受的压力越来越大。一旦集中交易系统出现故障，将导致严重的后果。因此，西北某证券考虑升级以往的应用级容灾系统，采用专业的灾备软件对集中交易系统进行完善的保护，包括: 1) 实现灾、备一体化的数据保护 对集中交易系统实现灾、备一体化保护，即在出现地震、火灾、存储故障、大面积电力中断、网络中断等情况下使用容灾系统实现业务快速接管；在出现诸如表数据丢失、数据逻辑错误、软件BUG等情况下可以通过备份系统快速在线修复系统。同时整合两种灾备模式，做到全方位保护。 2) 实现本、异地结合，查询、容灾结合的数据同步 在中心机房和异地机房之间各保留一份同步数据。中心机房的同步数据用于历史查询、数据分析等，作为“温备”数据。异地同步数据用于容灾切换，作为“灾备”数据。 3) 强调应急处理及演习体制的建设，实现灾备制度保证 在关键时刻容灾切换是否能够成功，不但取决于灾备软件，而且和平时的灾备演练、系统维护以及应急体制息息相关。因此，西北某证券要求灾备系统的建设同时应建设应急处理制度、演习制度并形成规范文档和应急指导手册，切实提高容灾系统的应用效果。 解决方案 根据西北某证券的实际情况，DSG采用RealSync+SnapAssure的灾备一体化方案来满足客户的需求。解决方案示意图如下: 如上图所示: 1) 配置两套DSG RealSync软件，分别实现从本地交易服务器组同步数据到中心机房的查询服务器以及异地机房的灾备服务器，实现本地和异地的数据同步； 2) 同步到中心机房的数据，用于历史查询、数据统计分析使用；同步到异地机房的数据，基本上不使用，作为容灾数据；数据同步实时进行，保持和交易系统一致。 3) 配置1套DSG SnapAssure软件，实现从交易服务器组到灾备服务器的异地备份。两地之间的网络为千兆单模光纤。 4) 备份到异地的集中交易系统数据，可以用来快速恢复或者在线修复系统。数据备份每个交易日执行一次，每次备份包括数据文件、日志文件、控制文件以及参数配置文件等。 5) 在项目实施中，分析系统可能遭遇的各种故障，根据故障情况判断故障等级和危害程度；分析两种灾备方式对不同故障的处理的优缺点，选择最优的处理方案，并写明详细的操作步骤，汇总成为应急手册。根据以上应急处理手册，进行日常的演习，通过平时的演练来促进系统故障时反应能力和故障处理能力。 应用效果 西北某证券的灾备一体化系统是我国证券行业内采用先进的灾备软件构建关键业务系统全方位数据保护的首例。该系统建成后，可以实现: 1) 大幅提高集中交易系统在各种故障情况下的安全性。解决方案针对系统可能遭遇到的存储故障、主机故障、数据库故障、文件丢失、日志文件丢失、表丢失、数据异常、大面积停电、网络中断、地震等灾难都制定了相应的处理措施，从而为可能发生的故障准备好了处理预案。和其他的容灾解决方案相比，本方案的措施更全面和具体，更有针对性，覆盖了单纯的容灾技术无法解决的逻辑故障问题这个技术死角，并且提供了更多的在线修复的手段，从而令客户在面对各种灾难是能够选择最合适的方案进行快速处理，把对系统的影响减小到最少。 2) 应急处理措施与技术手段融为一体。在本项目中，除了软硬件系统的安装配置，更多的精力被投入到针对具体故障情况下的切换、恢复以及修复等的处理和演练，从而将技术手段和处理故障的流程、机制等结合起来，从而为今后的系统维护、管理和应急处理铺平了道路。 3) 达到了更高的技术指标。测试表明，在通常的交易复制中，数据延迟时间为1-2秒；数据库的首次数据同步时间不超过20分钟，切换时间不超过5分钟；数据全库备份时间不超过半小时，增量备份时间数分钟，全库恢复时间11分钟。以上技术指标既表明了灾备软件平时运行的高效，也表明了故障情况下能够达到的处理能力。 7.4 武汉财政容灾系统应用案例 业务需求 随着计算机应用系统的爆炸式发展，业务量迅速增加，业务种类日益复杂，系统必须管理不断增长的信息流量；随着信息量的急剧增大，核心数据的管理变得日益困难。如何安全、可靠地存储业务数据及满足未来业务数据高速增长的需要；如何有效管理日益增长的业务数据；如何实现业务数据的共享并在现有业务数据之上建立新兴的增值应用，如数据仓库、客户关系管理（CRM）等，成为了各企业建立信息系统的关键所在。 因次武汉财政局计划建设一个集中的数据中心，将其所下属的相关单位的财政数据集中收集到数据中心。通过收集过来的数据实现两类目的： （1） 作为各单位重要数据的灾备中心； 通过实时复制的方式将各下属单位的重要财政数据上收到数据中心，当各系统能够因为灾难造成业务停止或数据丢失时，能够在灾备中心进行业务接管和数据恢复。 （2） 建立数据仓库平台； 通过实时复制的方式将各下属单位的重要财政数据上收到数据中心，再从集中数据库中通过ETL工具抽取关心的业务数据进入数据仓库中，进行财政数据的分析、汇总和数据挖掘。 方案设计 1、一期建设范围 一期将其下属的三个重要的数据库进行上收。 ü 上收的数据包含3个Oracle 数据库; ü 共计约400个user下的数据； ü 数据量总共为几十GB。 2、系统结构 根据财政核心业务系统的需求及其业务特点，我们建议的系统结构图如下所示： 解决方案特点 1、主备系统数据库处于双活状态 武汉财政系统数据同业务要求在复制链路中的各个数据库都处在活动状态，其中容灾数据库承担了数据容灾备份，在任何一个生产数据库发生灾难时需要及时提供业务的接管和及时的数据恢复，同时，灾备数据库一直处于open状态，可以对灾备数据库进行实时访问，系统保持生产中心和灾备中心的数据库处于双激活状态； 推荐解决方案采用了DSG RealSync实现生产数据库源系统到容灾系统的复制工作。可以从技术上保障目标数据库在线可用，容灾数据库的数据实时可读取，复制过程和数据读取不产生矛盾。RealSync的复制延迟很小，从容灾数据库读取到的数据是实时最新数据，不需要为了读取到最新数据而进行一些切换工作。 2、N:1的容灾架构，适合于集中容灾的方式 DSG的容灾解决方案可实现异构系统下的N:1容灾体系结构，可实现一套容灾系统对多套生产系统提供容灾服务，减少为每套生产系统建设一套容灾系统模式下的高投入。 3、异构环境的容灾方式 RealSync的容灾解决方案为用户提供的是基于逻辑的数据复制解决方案，因此对于本地系统和容灾系统来说，其硬件平台可以属于不同的厂商、不同的型号，可采用不同的操作系统等。基于逻辑的数据复制屏蔽了底层物理数据的差异。 正如此案例，需要上收的系统分别采用了不同的硬件设备，包括HP-UX,AIX,Linux等有使用。这些系统所采用的硬件平台各不相同。系统采用RealSync提供的异构容灾解决方案时可以选择不同的异构存储平台作为容灾系统的存储平台。 7.5 南京军区总医院容灾系统应用案例 南京军区南京总医院是一所医教研协调发展的大型综合性医院。1994年首批被评为“三级甲等医院”，1999年获得“全国百佳医院”称号，2000年经人事部批准，在全国医院系统首家设立博士后科研工作站，2002年被批准独立招收博士后。2003年7月，医院内科学、外科学被国务院学位委员会、教育部批准为博士学位授予权学科。同年医院荣获“全国拥政爱民模范单位”称号。2004年成为军队博士后管理信息中心。 2009年南京军区总医院在系统升级过程中，在门诊机房充分利用现有服务器，选用DSG RealSync大型数据库异构热容灾软件用于数据库实时复制，把网络中心机房的军字一号系统和门急诊系统数据实时复制到门诊机房，门诊机房军字一号系统、门急诊系统数据库服务器安装Linux操作系统。数据复制首次同步为零停机时间，提供整个系统切换的数据基础，保证Oracle数据库中的数据实时同步，复制时目标端的Oracle数据库为活动状态，确保数据库能用并分担业务，这样当灾难产生的时候，就可以通过手工将用户终端切到备份的数据库服务器上去，确保业务的连续性；重新调整检验信息系统、门诊分诊排队叫号系统服务器的位置，从而实现异地系统容灾，在网络中心机房出现故障时，确保门急诊信息系统不间断正常运行，最大程度保障门急诊信息系统，维护医院形象，提高病人的满意度。 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论