惠普-中国人寿IT战略规划项目数据库平台移植分析.docx

《惠普-中国人寿IT战略规划项目数据库平台移植分析.docx》由会员分享，可在线阅读，更多相关《惠普-中国人寿IT战略规划项目数据库平台移植分析.docx（29页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、IT现状评估报告中国人寿IT战略规划项目数据库平台移植分析版本号 V3.0起草人:中国人寿IT规划项目组北京市朝阳区建国路112号中国惠普大厦（100022）电话：010-65643888传真：010-65668278FocusPMPage 2 of 30Error! Unknown document property name. (786432/Error! Unknown document property name.)Error! Unknown document property name.f98bad15e03f5348807d1ea370c44b3f.docxLast printe

2、d 23-9月-22 10:35编号：时间：2021年x月x日书山有路勤为径，学海无涯苦作舟页码：第29页 共29页版权说明本文件中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属中国惠普有限公司咨询与集成事业部所有，受到有关产权及版权法保护。任何个人、机构未经中国惠普有限公司咨询与集成事业部的书面授权许可，不得复制或引用本文件的任何片断，无论通过电子形式或非电子形式。文档信息项目名称：中国人寿信息化战略规划文档版本号：3.0文档作者：中国人寿信息化战略规划项目组生成日期：2004-3-8文档审核者：中国人寿信息化战略规划项目组审核日期：2004-3-8文档

3、维护记录版本号维护日期作者/维护人描述目 录1概述72数据库平台移植的必要性73对未来数据库平台的要求73.1企业级数据库管理系统的一般要求83.2中国人寿对数据库系统的特殊要求104产品等级评分系统114.1适应中国人寿企业架构114.2软件供应商的状况124.3产品功能性-关键属性124.4其他可以参考的评分指标134.5评分表实例135移植方向分析145.1评价对象155.2升级到Informix V9.4155.3移植到新的数据库平台175.3.1 初步筛选175.3.2 优缺点分析175.3.3 DB2和Oracle的比较175.3.4 第三方评价205.4比较和推荐216数据库平台

4、移植方案226.1移植时机选择226.2移植方法226.3移植的主要步骤236.3.1 第一步：移植方案设计236.3.1.1实施方案246.3.1.2技术方案246.3.2 第二步：数据移植工具开发246.3.3 移植计划制定256.3.3.1移植操作计划256.3.3.2移植期后备计划256.3.3.3移植应急计划256.3.3.4移植回退计划266.3.3.5移植后维护监控计划266.3.4 移植计划测试266.3.5 移植演习276.3.6 并发移植方案276.3.6.1单点移植276.3.6.2多点并行移植276.3.7 移植实施286.3.8 后期监控和维护286.4风险和控制方案

5、286.4.1 技术风险和规避计划286.4.2 管理风险和规避计划29图表目录图 51IBM对Informix的产品发展计划16表 41通用产品评分表14表 51和中国人寿相关的产品评价标准19表 52升级和移植的方法比较211 概述本文档主要是通过分析中国人寿目前对数据库管理系统（DBMS）平台的需求，确定新数据库平台的选择方法和选择标准，并介绍目前市场上可供选择的主流数据库平台及其对比，以明确中国人寿未来数据库移植的方向和大致实施方法，并为本项目第三阶段规划过渡计划时具体划分实施项目提供依据，同时，也对中国人寿未来具体实施数据库移植提供框架性的指导。本文主要包括以下内容：- 中国人寿当前

6、状况和需求- 主流数据库平台介绍和对比- 数据库移植的主要实施步骤- 风险分析和规避建议2 数据库平台移植的必要性目前中国人寿的主要业务系统都基于Informix平台，由于Informix被IBM收购，而IBM宣布将于2006年底停止对现行Informix数据库产品（V9.4以前，即原informix公司开发的版本）的支持，因此，中国人寿必须在2006年底前完成对现有informix版本的升级或移植。本文将根据这一需求，就该平台的升级或移植方向和移植的主要实施步骤进行分析。3 对未来数据库平台的要求中国人寿未来的应用系统需要支持若干省甚至全国业务集中处理，这种集中处理模式具有数据量大、交易量大

7、、响应速度要求高、稳定性要求较高等特点，因此支撑这些应用系统的数据库管理系统（DBMS）必须能够满足集中模式下高性能、高稳定性和可扩展性的需求。在以下的分析中我们将首先分析对企业级应用中数据库管理系统功能和性能的一般性需求，这些需求与具体的某个应用关系不大，而是从企业级应用的角度考虑数据库系统应该具备的基本功能和性能水平，该需求可以成为数据库系统的基本选型标准，接下来我们会结合中国人寿未来的企业架构，尤其是集中模式和应用系统架构的分析，归纳出中国人寿对数据库系统的特殊要求。3.1 企业级数据库管理系统的一般要求- 高可用性(High Availablity)高可用性是指在某一台主机上特定的作业

8、因主机设备异常而无法继续运作时,可在最短的时间内在其它正常的主机上重新启动该项作业。实现系统的高可用性需要硬件系统、软件应用、软件管理体系等方面的综合协调和控制。对数据库系统而言，可从以下几个方面支持系统的高可用性：1 较强的容错能力、错误恢复能力、错误记录及预警能力2 支持对数据库在线管理和维护，减少因系统维护和管理导致的计划内停机3 数据备份支持数据的在线备份，减少由于数据备份而导致的系统服务中断数据备份效率高，特别是对于核心系统的大数据量备份，备份效率对系统可用性有较大的影响4 数据恢复5 数据复制支持网络上同构或异构数据库之间的数据有效传输和冗余性复制提供多样化的数据复制策略，如实时复

9、制、定时复制、双向复制、多点方式下的N 向复制、复制转发、复制范围可整表复制或表中部分行复制或修改单元复制数据复制技术的可靠性、可管理性- 高性能及可扩展性1 具有强的查询优化能力，能够自动优化查询语句2 具有快速的并发访问操作，并发控制稳定、可靠、支持多线程、多进程3 具有支持并行操作所需的技术，如多服务器协同、技术事务处理的完整性控制技术等4 具有足够的业务处理能力，包括能够管理的数据量和数据处理速度能满足未来3-5 年系统不断增加的用户访问的需求- 安全性1 提供多样化多层次的安全控制机制，支持C2 或以上级安全标准能够防止对数据的非法访问2 支持数据库存储加密、数据传输通道加密及相应冗

10、余控制- 可管理性1 提供图形化、智能化、自动化的管理工具，降低管理成本与复杂度2 允许用户根据需要制定专门的管理策略3 能够提供必要的管理日志和运行统计报告4 开发工具易使用，开发效率高，维护方便- 集成能力集成能力主要要求：数据库系统具有良好的开放性支持、异种数据库的互访等，具体内容包括：1 能够将原有数据库向本数据库无损失移植2 支持XA ODBC 3.0 X/OpenCLI JDBC XML 等标准3 支持分布式事务及两阶段提交功能4 对大型异种数据库的访问5 对文件数据和桌面数据库数据的访问- 网络能力支持主流的网络协议如TCP/IP IPX/SPX NETbios 及其他混合协议-

11、 内容管理1 高性能数据库引擎，丰富的数据类型等2 支持对多媒体数据及大数据量处理的技术需求- 适用平台支持主流厂商的硬件平台及操作系统平台- 国际化支持多种语言特别是中文汉字内码符合双字节编码3.2 中国人寿对数据库系统的特殊要求- 对大数据量和大数据表的支持作为全国最大的寿险服务供应商，中国人寿在集中模式下的数据量将是一个巨大的数字（根据数据中心的高端设计，总的业务处理系统的数据量将超过500TB），数据库系统必须能够支持超大规模的数据库和数据表存储，并且且能够在数据库设计和性能优化方面为此类大型数据表提供支持。- 数据复制根据中国人寿的应用架构，其数据将分布在核心保险应用、销售支持、财务

12、系统、精算系统等多个应用系统中，这些数据可能在逻辑上属于不同的数据库，但是可以由相同的DBMS 管理或驻留在相同的硬件平台上，以提供充分的数据集成和数据共享，另外，不同的数据模块间还要有一定的数据冗余，以提高本系统处理的性能，在这种要求下，冗余数据的同步主要通过数据复制来实现，当前我们考虑主要通过应用逻辑层（如企业应用集成EAI等）来控制和实现数据复制和同步以增强数据共享的灵活性和可控制性，但同时也会要求数据库产品也提供数据复制功能，以根据实际的解决方案要求选择最适当的技术手段来实现，提高总体系统架构的性能和灵活性。- 数据备份由于中国人寿的数据量极大，数据库系统必须能对数据备份的效率提供必要

13、的技术支持和保证，并提供诸如完整备份、增量备份、差分备份等多种备份方式，以保证系统备份能够在所需的时间窗（timeframe）内完成。4 产品等级评分系统针对中国人寿将来选择数据库平台的招标需要，我们提出一个等级评分系统，为将来的招标委员会提供一个候选产品的评价方法。候选产品分三个系列进行评分，共有十六个评价指标，每种产品的得分和它所比较的同类产品相关，也就是说，得分高低是相对的。 因此，即使一个产品在四项指标中的三项指标都领先，也不意味着这个产品的市场占有率是75%，以下是对这些分类评分的具体论述。4.1 适应中国人寿企业架构- 支持中国人寿标准：产品是否遵循中国人寿所采纳的各项IT标准？-

14、 应用整合能力：产品是否能和领先的ERP,Web, 和像Siebel这样的CRM应用进行整合？ - 运用现有基础架构的能力：产品是否可以和中国人寿目前的应用进行数据共享或交换？应用是否可以安装或配置在目前中国人寿的硬件设施上？- 关键技术和软件供应商解决方案的协同工作能力产品是否和其他推荐给中国人寿的应用或方案能够协同工作，并具有较高的效率？4.2 软件供应商的状况- 财务稳定性: 本部分包含了关于软件供应商财务状况问题的解答？企业是否有良好的财务稳定性的历史？企业未来的财务稳定性如何？- 公司远景/方向: 用于评价企业是否明确其未来发展远景，企业是否已经清楚地说明或论证了关于他所提供的解决方

15、案、产品和服务的战略性方向？- 市场地位: 企业是否被当作市场的领导者？它是否被当作创新者或是新产品的开发者？- 和其他厂商的伙伴关系/结盟: 企业是否能和其他厂商，尤其是保险行业应用系统供应商形成伙伴关系？过去是否有过成功的经验？4.3 产品功能性-关键属性- Product reliability产品可靠性: 与同领域其他产品相比较，产品的可靠性如何？- Product compatibility产品兼容性: 产品与中国人寿将会采用的其他软硬件兼容性如何？- Product scalability产品伸缩性: 产品伸缩性是指厂商采取恰当的整合解决方案后，可以满足日益增长多方面需求，如：用户

16、量，并发会话，附加硬件，和对其他解决方案地依赖。不用停机便可以增删硬件，同时又不影响网络其服务器，这也是所期望要达到的。 - Product feature set: 产品特性集合：产品是否具有一个涵盖实现中国人寿系统架构所需所有功能的特性集？- Performance: 性能：性能是一种相对概念，它基于和同领域其他厂商产品的比较结果。为了评判性能，我们必须获得同领域相关产品的性能基准报告，这份报告通常包括每秒交易量，反应时间，和其他相关参数。4.4 其他可以参考的评分指标在实际招标中，还要根据实际情况，对下产品评分表中列出的评价指标作出相应的增加和调整，例如：- 增加价格因素，这显然是很重要

17、的参考指标；- 增加在全国范围内的支持能力，这对于业务几乎覆盖全国的中国人寿现状也十分需要；- 增加服务承诺指标和今后若干年内的免费升级等因素；- 对于厂商所作出的个性化承诺，如大规模免费培训、各种免费授权等，也可以根据中国人寿的实际需要进行考虑；- 产品包或产品线中的其他工具或产品，如电子商务开发、联机分析引擎、数据分析和报表等工具，如果供应商能够提供业界领先的、适合人寿的、全套完整的解决方案，有助于提高未来系统的集成度，也有利于中国人寿利用采购规模优势来获取更好的价格。4.5 评分表实例下表列出了一个对功能相似的两个产品进行评价的示例，我们建议中国人寿在根据上述基本评价标准筛选之后，对最终

18、的两到三个候选者进行最终的评分，以确定最适合中国人寿需求的数据库平台。样例：产品评分表适应中国人寿的企业架构Weight权重产品1产品2Support for China Life Standards支持中国人寿的标准10Package Application Integration包应用整合3Ability to leverage existing infrastructure利用现有基础架构的能力3Interoperability with key technologies & vendor solutions与关键技术和软件供应商的协同工作能力4Criteria Total标准总和Ven

19、dor Status软件提供商状况WeightFinancial stability财务稳定性4Vision / direction for their company 公司远景和方向4Position in Marketplace市场地位4Partnerships/Alliances with other Vendors和其它软件供应商的伙伴关系/联合3Criteria Total标准总和Product Functionality - Key Attributes产品的功能性-关键属性WeightProduct reliability产品可靠性5Product compatibility产品

20、兼容性3Product scalability产品可伸缩性4Product feature set产品特点集合5Performance 性能5Criteria Total标准总和表 41通用产品评分表5 移植方向分析本章对现有Informix版本的替代产品的选择方向进行分析，以明确中国人寿最终对数据库平台产品的选择因素。5.1 评价对象本章分析的主要是关系型数据库管理系统产品，包括整个产品包所包含的数据库管理系统、指令语言、开发工具和管理工具等。目前，中国人寿可以选择的升级或替代方案共有两种：I. 将现有Informix平台升级到V9.4，并跟随着IBM对Informix的产品计划不断升级；I

21、I. 将现有Informix平台移植到新的数据库平台上，如DB2、ORACLE、Sybase、MS SQL SERVER等。以下对上述两个大方向进行深入的分析。5.2 升级到Informix V9.4下图（51）是IBM的Informix产品发展计划：该计划以2003年3月发布的Informix9.4为基础，在2006年下半年过渡到和DB2具有互操作性的V9.6。而随后的方向比较明确的是和DB2的互操作性。值得指出的是，该图仅仅是IBM的产品发展计划，而不是对最终用户的承诺，而且2006年以后Informix的发展方向，仍然没有被明确。图 51IBM对Informix的产品发展计划优点：- 时

22、间不紧迫，可以比较详细地进行计划- 可以充分利用现有技术储备，对应用系统的影响小- 短期内的投资可能是最低的- 对系统管理的影响较小缺点：- 未来发展方向不明确，可以预见，IBM不会长期同时支持两条数据库平台的产品线，所以Informix有可能最终还是要并入DB2数据库平台产品线- 可能需要跟随IBM的产品计划，进行多次升级- 核心应用系统的更新过程也是更换数据库平台的最佳时机，可以最大限度地降低对业务的影响，这样的话，如果将来真的需要将Informix移植到其他数据库，现在保持在Informix平台上就错过了这一时机。5.3 移植到新的数据库平台5.3.1 初步筛选首先，可以被排除在外的数据

23、库为sybase，因为Sybase在整个数据库市场中已经处于不断衰退的过程中，而且其数据库在大规模应用中的稳定性也值得怀疑。其次，对于MS SQL Server，由于其仅支持Windows平台，所以也限制了中国人寿对服务器的选择，基于MS SQL Server在小规模应用中低成本、简单易用的优势，我们建议在诸如网站、行政管理等小规模应用中，考虑采用MS SQL Server作为其数据库平台。5.3.2 优缺点分析优点：- 移植后，可以保持较长期的稳定- 可以充分利用数据整合和应用系统升级的时机- 相对于Informix，DB2和Oracle在总体上更加成熟和先进，- 其他相关产品供应商和应用开

24、发商的支持更多，有利于其他产品的选型和系统的集成- DB2和Oracle本身也提供诸如电子商务、商业智能甚至ERP等解决方案和产品缺点- 需要重新购买产品，短期投资大- 需要培训数据库管理和开发人员的技能- 应用系统需要全面移植5.3.3 DB2和Oracle的比较基于上述分析，候选产品中重点考虑Oracle和DB2的比较，这里我们运用上一章中的产品评分表来进行量化的比较分析。产品评分表评价标准权重ORACLEDB2说明适应中国人寿的企业架构权重支持中国人寿的标准10如所选择的UNIX开放平台产品包和应用整合3如产品能否实现和其他异种数据库平台的集成；产品自身是否提供相应的软件包利用现有基础架

25、构的能力3能否支持中国人寿现有的各种基础架构平台，如Windows, HP-UX, AIX等；主流的系统维护管理工具（如监控软件、备份软件等）的支持情况；与关键技术和软件供应商的协同工作能力4能否被主要的企业应用集成工具（如TIBCO）支持并具有较高效率标准总和20软件提供商状况权重财务稳定性4公司近3年来的财务报告公司远景和方向4公司未来5年内的发展计划，尤其是所提供产品的发展计划市场地位4公司所提供的产品在市场上的份额，以及近3年来的增幅和其它软件供应商的伙伴关系/联合3公司和中间件、主流应用系统（如BEA, Siebel, SAP等）的联盟关系，及这种合作解决方案在市场上所占的份额标准总

26、和15产品的功能性-关键属性权重Product reliability产品可靠性4Product compatibility产品兼容性3Product scalability产品可伸缩性4Product feature set产品特点集合4厂商自己提供的针对中国人寿的产品特点评价Performance 性能5第三方性能测试数据标准总和2055和中国人寿相关的评价标准：评价标准权重说明价格20全国支持能力10如能否提供一个专职的支持团队？多大规模？现场支持响应的时间？招募合格技术资源的难度5目前，在中国人力资源市场，掌握哪种技术资源的人材多一些？个性化承诺5产品供应商为中国人寿提供哪些特别的承诺

27、，如免费的培训、测试、移植指导等，；主要应用系统产品所基于的平台5是否为主要的保险应用所基于的平台？效率如何标准总和45100表 51和中国人寿相关的产品评价标准从表格（51）分析中可以看出，相对于中国人寿的需求来说，Oracle和DB2单就产品和供应商而言相差不多，而相对而言，Oracle具有以下一些优势：- TPC-C测试的结果显示，Oracle和其他诸如BEA产品的集成具有性能领先优势- Oracle在开放平台的市场份额占有绝对的优势- 由于oracle是独立软件开发商，因此相对于DB2，oracle拥有更多的合作伙伴，在市场上有更多的技术资源可利用- 除电子商务、商业智能外，Oracl

28、e还拥有ERP等业务应用系统可供中国人寿选择- TPCC测试结果显示，Oracle数据库的性能处于比较领先的地位- 目前看来，两种产品的价格都比较昂贵- 在国内的人力资源市场拥有更多的oracle技术资源- 如免费的培训、免费的技术资料转让或免费参与移植项目等- 虽然很多诸如Sibel，SAP等系统同样可以在DB2上运行，但是其最初的开发平台通常为Oracle综上所述，Oracle在市场占有率以及和其他合作伙伴的集成方面具有微弱的优势。而在从中国人寿产品采购、招标、以及未来使用的角度来看，Oracle同样略胜一筹，因此，根据上述分析，我们初步推荐中国人寿选择Oracle作为其未来的数据库平台。

29、另外，上述内容仅仅是对ORACLE和DB2这两个产品进行粗略的初步分析，在实际的招标过程中，还需要对上一章所阐述的价格、服务承诺等因素进行综合分析。另外，各项指标的权重也可以根据需要进行灵活地调整，以最终确定目标数据库平台产品。5.3.4 第三方评价独立研究机构Morgan Stanley公布的调查报告显示：51%的CIO们把Oracle作为首选的数据库供应商，而IBM和Informix加在一起的数字还不足22%，Morgan Stanley认为，在最了解当今数据库性能的CIO群体中，Oracle数据库继续雄居领先的地位。AMR Research在2001年11月提供的一项研究报告同样表明，在

30、所有计划改变其原有数据库的Informix用户中，有50%将转向Oracle。Evans Data研究报告也证实，Oracle是应用开发者首选数据库，Evans Data在研究报告中指出，大多数开发者在选择数据库时主要考虑可靠性、可伸缩性、完整性以及总拥有成本等因素，在这些方面，Oracle都获得了开发者的认同。5.4 比较和推荐升级到Informix9.4移植到DB2或Oracle优点- 时间不紧迫，可以比较详细地进行计划- 可以充分利用现有技术储备，对应用系统的影响小- 短期内的投资可能是最低的- 对系统管理的影响较小- 移植后，可以保持较长期的稳定- 可以充分利用数据整合和应用系统升级的

31、时机- 产品在总体上更加成熟和先进- 其他相关产品供应商和应用开发商的支持更多，有利于其他产品的选型和系统的集成- 新的产品的产品线更丰富和完整缺点- 未来发展方向不明确- 可能需要进行多次升级- 可能会错过核心应用系统的更新过程这一最佳移植时机- 需要重新购买产品，短期投资大- 需要培训数据库管理和开发人员的技能- 应用系统需要全面移植表 52升级和移植的方法比较基于上述分析（表52），我们建议，对于诸如保险核心系统、CRM等重要应用，可以在将来实施招标过程中结合具体的采购流程和评分体系，在Oracle和DB2的高版本之间作出选择。另外，我们认为在Oracle和DB2的选择种要综合考虑以下成

32、本因素：- 软件自身的购置成本，尤其是定价方式（按最终用户、按CPU数目和主频、企业买断式等）；- 扩展工具包（如数据集成、数据仓库技术、电子商务等）的购置成本；- 后续升级支持的成本；- 对基础架构平台的选择限制或影响（如某种数据库在某一平台上的性能明显远高于其他平台等）；- 培训成本等。6 数据库平台移植方案本章主要描述数据库平台移植实施的方案，包括移植项目的主要步骤、可能的技术和管理风险，以及针对这些风险的控制方案建议。6.1 移植时机选择根据新的应用系统架构，中国人寿需要在今后一段时间通过升级、开发或购买等方式建立新的核心保险应用系统，因此，作为该核心应用的数据平台，数据库系统的移植必

33、须和新的应用系统开发同步协调进行。在本项目的第三阶段，我们将从总体上对核心应用的开发及发布和数据库系统的移植进行综合规划，其主要指导原则是： 核心应用系统的要求应当作为数据库平台的选型的重要依据 数据库平台的选择应当在应用系统实施项目前确定 数据库平台的移植方案将作为应用系统开发和部署方案的重要组成部分 数据库平台的移植实施也将作为应用的测试推广工作的重要组成部分6.2 移植方法我们的建议基于HP系统移植方法，这套方法是HP在多年IT整合项目中系统移植实施的基础上总结而成。整个方法所建议的实施过程如下图所示，它从整体上表达了由可行性分析、设计到实施的全部过程。同时，它还建议对较为复杂的系统进行

34、先导项目的试验，以降低实施风险。HP的移植方法主要包括如下四个阶段： 系统移植规划- 确定数据库移植目标、范围和限制条件- 确定项目成功的条件和考量方法及尺度；- 确定项目的风险和具体的实施方法- 确定整合的具体内容和潜在的障碍 系统移植分析及概要设计- 调查和分析现有的IT环境，包括应用、基础架构、设施，以及IT管理、IT对业务的影响力，企业的IT系统特点等；- 初步确定整合的可选方案和概要的系统配置方案；- 评估移植和后续运营工作量和投入；- 建立实施团队，准备开始实施整合； 实施移植- 移植方案详细设计- 项目管理- 实现移植方案（如果有需要，还要首先建立一个原型验证系统）- 测试和考量

35、移植项目 后期评审、日常运营和改进6.3 移植的主要步骤在数据库平台选型完毕之后，移植工作的实施就成为过渡方案的重要环节，数据库平台的移植是一项庞大而复杂的系统工程，从过去的经验看，多数移植项目不能够100成功的原因是因为过于重视了移植的技术操作，而忽略了总体移植项目的实施过程和风险控制，因此，根据中国人寿的实际情况，我们建议中国人寿按照以下步骤来制定数据库平台移植方案。6.3.1 第一步：移植方案设计一个成功的数据库移植项目，一定要基于一个完善的移植方案，因此，在整个移植过程的第一步，就是要在数据库厂商和应用系统供应商的配合下，对数据库移植的实施过程进行充分的分析和研究，形成一套完整的技术和

36、实施方案。6.3.1.1 实施方案实施方案是指基于应用系统部署计划，所需的具体数据库移植操作过程，包括：- 移植对象和目标的确定- 主要移植数据指标的确定和量化- 移植时机的选择和关键里程碑设定- 移植环境和资源的准备清单- 相应的培训、沟通计划6.3.1.2 技术方案技术方案是指在Informix和新的数据库管理系统之间进行应用移植的技术实现方法，技术方案中主要包括：- 两个数据库平台间的功能覆盖程度和差异评估- 不同技术实现手段的转换- 新系统功能差距的替代方案- 数据移植方法设计- 移植测试方法6.3.2 第二步：数据移植工具开发基于移植的具体目标和数据指标要求，根据两个数据库平台的特点

37、，进行移植工具的开发，通常地，这些移植工具主要包括：- 数据校验：包括源系统数据校验（抽取前）和目标系统校验（加载后）- 数据抽取：包括全量抽取（不变量）和增量抽取（变量）；- 数据转换：源系统数据向目标系统数据的转换程序，包括缺陷数据的补充方案和临时替代方案；- 数据传输：如果存在不同物理存放位置间的数据移植，还要开发相应的数据传输程序，保证传输过程的自动化、可靠性和完整性；6.3.3 移植计划制定移植计划不仅仅包括基本的移植操作步骤，还应当根据对业务的影响制定完善的后备计划和应急计划，另外，还要考虑一旦移植操作发生意外，导致移植无法成功完成时的回滚计划，以保证对业务的最小间断和系统的平稳过

38、渡。6.3.3.1 移植操作计划基于实施方案和技术手段，利用移植工具制定的移植操作过程，主要包括：- 所需环境和资源检查清单；- 详细的移植操作步骤和命令集；- 所有相关的配置表；- 详细的任务清单和时间表；- 相关的操作人员、管理人员、用户的联络表和沟通计划6.3.3.2 移植期后备计划移植后备计划是考虑到移植过程中可能有紧急的业务需要执行，由业务部门配合制定的移植期间的业务操作替代方案，主要的替代方法有：- 预先的业务处理：提前完成一些业务操作，一旦有业务需要，这些操作的结果立即被应用；- 保留关键业务系统备份：这要求一定能够追踪到移植期间的增量，并在移植完成后能够在不影响业务一致性的前提

39、下进行数据补录；- 手工操作：利用手工操作处理业务，同样要保证完整的数据补录；6.3.3.3 移植应急计划应急计划是以防万一某个移植操作发生意外的后援计划，它也是整个移植计划的风险规避计划，该计划的制订过程，就是对移植操作计划和后备计划的详细的风险分析过程，通过该计划，充分考虑移植过程中的每一个步骤所存在的风险，并制定相应的风险规避手段和流程，保证移植过程的平稳执行。通常情况下，在制定应急计划的过程中，移植操作计划和后备计划可能也会相应地作出修改，以提高移植过程的强壮性和容错能力。另外，一些相应的技术保障手段也会被开发或采购，来共同保证移植过程的稳定性。6.3.3.4 移植回退计划尽管为数据库

40、移植制定了周密的计划，但在系统移植过程中，任何原因导致移植失败的可能性依然存在，如何保证在移植失败的情况下，中国人寿的系统和数据能够回退到移植开始前的状态，使得其业务系统仍然可以正常运行，是回退计划所要解决的重要问题。通常地，回退计划包括：- 系统备份计划：保证取得移植的起始状态点；- 决定回退的条件，在该条件被满足时，必须终止移植操作，对系统进行回退；- 决定回退的流程和被授权人，通常由移植项目经理和技术领导决定是否回退；- 进行回退的环境和资源要求；- 回退后的状态测试计划，以保证系统真正回退到了初始状态；6.3.3.5 移植后维护监控计划系统割接后，还需要一段时间的系统监控和调优，以保证

41、新的系统能够尽快进入到最佳运行状态，并按照技术指标要求，决定移植工作结束，系统正式交付到运维团队；- 随着新系统投入运行，也需要增加相应的人力资源，进行系统的维护和管理；- 移植过程中的所需的特殊资源也需要释放；- 相关的知识转移。6.3.4 移植计划测试移植计划测试的主要目的是验证移植计划的正确性和可行性，主要包括。- 移植环境准备- 对移植操作过程进行实施验证- 模拟突发事件，对后备计划和应急计划进行验证- 验证回退计划- 总结调整移植计划上述过程可能会重复多次，以达到最优的移植计划。6.3.5 移植演习和测试不同，移植演习完全按照实际割接（cut-over）的要求来实施移植计划，其主要目

42、标是保证所有参与人员对移植计划的熟练掌握，以使得移植操作可以平滑地进行，减少人为操作失误带来地风险。6.3.6 并发移植方案为加快整个移植工作的进度，考虑多个省的系统并行移植，即在一段时间内，同时将多个省的数据库平台进行移植，这对于缩短建设周期，节省成本非常重要。但是，另一方面，并发移植必须在单点移植方案很成熟的基础上，经过反复并发移植测试证明成功，才能够大规模实施。6.3.6.1 单点移植将某一个省的某一系统移植到新的数据库平台上：按照详细的移植计划和操作步骤，对单个省进行移植。6.3.6.2 多点并行移植多个省的某一旧系统并行地移植到新的数据库平台上，这需要：- 重新审视移植计划，发现其中

43、不可并发的操作步骤，稳妥的做法是找出其中可以并发执行的步骤，而将其他的都视作不可并发；- 根据不同源点的情况，确定综合的移植操作步骤；- 测试该并发步骤，得到最终的并行移植方案；- 进行多点并行移植演习- 大规模实施6.3.7 移植实施严格按照移植计划的要求，进行移植和割接操作，并对移植的操作过程不断进行总结和改进，并在多个并行点间共享移植经验，以得到最优的移植方案。6.3.8 后期监控和维护监控：对系统的运行进行监控，尤其是对某些关键业务的时间点（如月结月报等）或不经常发生的业务（如年报），要认真进行检测，保证所有的业务都平稳过渡到新的数据库平台上。调优：对系统的性能进行调整，由于不同的数据

44、库平台有不同的运行架构和调优方法，中国人寿需要在厂商技术专家的指导和帮助下，对系统配置参数进行调整，使系统的运行效率达到最优，并形成适合中国人寿业务处理特点的数据库管理系统运行模式。移植验收和交接：包括相关的验收报告签署、技术和实施文档、知识转移等，自此，数据库平台由移植项目团队移交到管理维护团队。6.4 风险和控制方案6.4.1 技术风险和规避计划 应用系统产品支持能力中国人寿所选择的应用系统是否能够很好地支持所选择的数据库平台，是整个移植方案实施的先决条件，这里需要指出的是：中国人寿应当将对数据库平台的广泛支持能力作为应用系统选择的一个重要参考指标，以保证对数据库平台选择的广泛性；反之同样，拥有广泛的应用系统支持也是对数据库平台选择的考查指标之一。 对旧系统的功能覆盖程度新的数据库平台所支持的功能对旧系统的覆盖程度，是系统能够在最小工作量的情况下顺利移植的重要保证，这些功能包括：数据库对象、支持的指令集、扩展应用等。中国人寿也应当将对Informix7.3功能的覆盖能力，作为新数据库平台考查的重要指标之一。 RDBMS性能和容量支持能力首先，我们要保证新的平台能够支撑大规模的数据处理和存储，另一方面，还要要求数据库平台具备良好的可伸缩性和可扩充性（如群集计算能力），以根据需要在不同的阶段