XXX数据迁移方案.doc

1、XXXX 核心系统主机升级/存储升级/系统迁移项目0正本招 标 人：XXXX项目名称：电信机房迁移项目（数据库升级部分）投标文件投标方全称：XXXX 股份有限公司2012 年 02 月 20 日XXXX 核心系统主机升级/存储升级/系统迁移项目-1-前 言首先，非常感谢各位领导及专家给予 XXXX 参与“XXXX 数据库迁移项目”的机会，我们凭借自身综合实力及多年系统集成，提交本方案，望能采用。XXXX 集团（原青鸟软件股份有限公司）起源于北京大学，是一家专业从事软件与信息技术服务的大型企业集团（以下简称“XXXX” ） ，XXXX 集团以 XXXX 股份有限公司为核心企业， XXXX 活跃在

2、新经济下企业转型服务领域，并在咨询服务、软件开发、系统集成以及运维服务四个核心业务领域积累了世界领先的专业技术和服务经验，与 50 多家国际著名管理咨询公司和软硬件厂商结成战略合作联盟，与 3000 多家国内集成商紧密合作，为数万家客户提供信息技术服务和应用软件解决方案及相关服务，在金融、能源、政府及企业领域建立起了卓越的声誉和品牌，是客户最佳的信息技术发展战略合作伙伴。针对本项目，XXXX 具有如下优势：集成优势XXXX 作为一级系统集成商，对系统集成有着深刻的认识；同时设计和实施过在众多数据中心、大型业务系统的软硬件平台，有着丰富的建设经验；针对应用的高可用性和业务的连续性有着深入的研究，

3、结合用户的具体需求，我们将提供全面、合理的解决方案。产品优势XXXX 是 IBM、HP、SUN 小型机；ORACLE、SYBASE 数据库；IBM、ORACLE 中间件及试测软件；EMC、HDS 存储；CISCO、AVAYA 网络设备；APC 机房设备等高级别代理商，对各类产品有深入细致的了解，能为贵校提供最优的解决方案。完善的质量保证体系ISO9001 质量保证体系是质量管理标准和质量保证标准。XXXX 为了进一步提高公司的管理水平，确立了以客户为中心的质量体系，并将其定义到整个系统集成的设计/开发、供应、安装和服务领域。本地化服务能力上海 XXX 员工逾 200 人，技术人员 50 余名，

4、其中包括小型机、中型机、存储、数据库、智能化、软件、项目经理人及网络工程师若干名，具备较强的技术力量和集成能力。公司特为此项目成立豪华项目小组，由公司销售总监担当项目组长，监控整个项目的实施过程，并组建 15 人的技术服务团队（有厂商资格认证的工程师）配合厂商为用户提供全方位的技术服务。优惠政策公司根据本实验室的建设目标、主要任务和功能定位，特免费赠送对改实验室建设有帮助的一款系统软件数据统计软件，希望能够充分的帮助学校更好的建设此实验室。科研合作近期，国家加大了对“产学研”过程的扶持与引导力度，而 XXXX 也一直致力于出身高校（前北大系）服务于高校的准则，大力与高校进行校企合作。充分利用高

5、校的人力资源与科研能力，在金融、电力、能源、高教等领域共同开发出适合市场需求的产品，并树立良好的品牌。因此，希望通过此次参与上海交通大学项目，能够有机会更进一步与贵校在内容安全领域有更多的科研合作，通过 XXXX 现有的用户群来做市场推广。本着与 XXXX 建立全面、持久、稳定、良好的业务合作关系，我们郑重承诺：以丰富的项目实施能力、雄厚的资金实力，以方便、快捷的本地化服务特点为保障，确保 XXXX 数据库升级项目的顺利实施。XXXX 核心系统主机升级/存储升级/系统迁移项目-2-目 录第一章 技术方案 .21 项目方案 .21.1 生产中心硬件平台 .21.1.1 系统拓扑结构 .21.1.

6、2 服务器硬件平台选择 .31.1.3 存储部分 .41.1.4 存储交换机 .51.2 数据迁移方案 .71.2.1 RMAN Backup/Restore 迁移 .71.2.2 Oracle DataGuard 迁移 .81.2.3 借助第三方工具（ Quest SharePlex）迁移 .91.2.4 迁移方案对比 .121.2.5 迁移数据校验 .132 服务协议 .152.1 服务内容 .152.2 项目实施工作小组 .152.3 项目进度计划 .162.4 项目分工界面 .172.5 项目验收方案 .202.6 售后服务承诺 .22XXXX 核心系统主机升级/存储升级/系统迁移项目

7、-3-第一章 技术方案1 项目方案1.1 生产中心硬件平台1.1.1系统拓扑结构XXXX 现有数据中心和新建设的数据中心服务器配置的简单拓扑图如下图所示：现有生产中心数据库服务器硬件平台由两台 Sun v890 服务器构成，在 Solaris 10 操作系统上运行 Oracle RAC 数据库（10gR2 ） ，数据文件存放在共享的 HP EVA8400 磁盘阵列上。本次方案的主要目的是建设新的硬件平台，将数据库从现有平台平滑迁移至新的硬件平台。本次方案根据招标文件中相关要求，参考当前系统运行状况，选择合适的硬件平台，支持核心数据库系统的稳定、高效运行。根据本节硬件平台的选择结果，在第 2 节

8、中我们将会给出相应的数据迁移的几种方案。XXXX 核心系统主机升级/存储升级/系统迁移项目-4-1.1.2服务器硬件平台选择当前数据库服务器采用了 Sun v890 服务器，我们的目标是根据现有的硬件配置推算出我们需要的新硬件平台服务器的处理器的配置需求。衡量 OLTP 类应用系统的处理器处理能力的指标有CPU2006，SPECjbb2005，TPC-C 等指标。由于不同厂商的不同时期发布的产品在性能比较上不存在单一的标准，加上部分产品未参与某些指标的公开测试，所以在下面的讨论中我们选择同时发布了SPECjbb2005 和 CPU2006 指标的 v890（UltraSPARC IV+ 2.1

9、GHz 处理器） 服务器作为基准，作为其他服务器处理器比较的依据。从 http:/www.tpc.org 和 http:/www.spec.org 可以分别获得主流服务器平台的 TPC-C 和CPU2006 指标数据。各个型号服务器的 SPECjbb2005 和 CPU2006 的数据和相应配置如下表所示：CINT2006 CFP2006 SPECjbb2005V890(8chip，16core，1.5GHz) 117986V890(8chip，16core，2.1GHz) 154 244846M3000(1Chip，2Core，2.7GHz) 33.5 29.5M5000(8Chip，32C

10、ore，2.6GHz) 352 278因为 UltraSPARC IV+ 1500MHz 的 v890 采用的是 SPECjbb2005 指标，我们只能从相关的参考指标来推算出当前 Oracle 在主流服务器中配置的 SPARC64 芯片性能比较参数。从上表中可以看出，单颗 2.6GHz 的 SPARC64 芯片性能大约是 2.1GHz UltraSPARC IV+芯片的 2.3 倍，单颗 2.1GHz UltraSPARC IV+处理器是同型号 1.5GHz 主频处理器的 2 倍。因此 2.6GHz 主频的 SPARC64 处理器性能是 UltraSPARC 1.5GHz 处理器性能的 5

11、倍左右。根据标书要求，服务器满配置需要至少 32 核心处理器和 64GB 内存。根据这一要求，我们从主流的服务器厂商中选择了 Oracle 的 M5000 服务器作为推荐型号，满足本次方案建设要求。其性能参数如上表所示，可以看出，配置新型号的处理器，考虑到存储设备升级，I/O 系统的优化，数据库参数和配置的调整及优化，有充分证据可以表明可以提升当前数据库系统的性能，使得系统的响应时间缩短 510 倍，系统的吞吐量提高 510 倍左右。从而系统总体性能上有了 10 倍左右的提升。XXXX 核心系统主机升级/存储升级/系统迁移项目-5-1.1.3存储部分OLTP 是传统的关系型数据库的主要应用，主

12、要是基本的、日常的事务处理，具有很高的并发性（大量的交互式用户） ，并且是更新密集型的，SQL 语句主要以插入、更新和删除为主，要求具有较快的响应时间，以银行系统，订票系统为代表。由于 OLTP 应用的业务特点，从性能角度出发，对磁盘子系统有一定的要求。OLTP 系统最容易出现瓶颈的地方除了 CPU 就是磁盘子系统。磁盘子系统在 OLTP 环境中，它的承载能力一般取决于它每秒处理 I/O 的数量。因为在 OLTP 环境中，磁盘物理读一般都是 db file sequential read，也就是单块读，但是这个读的次数非常频繁。如果频繁到磁盘子系统都不能承载其 IOPS 的时候，就会出现大的性

13、能问题。另外磁盘子系统的控制器的 Cache 大小对 I/O 系统的性能也至关重要，Cache 决定了很多事务不需要从物理磁盘存取数据，从而大大缩短了事务处理的时间。根据标书要求，存储设备的选择需要同时支持 FC 和 iSCSI 协议，IOPS 至少达到 18000，控制器缓存至少 16GB，可用磁盘容量达到 10TB，配置容量需要达到 20TB 左右。针对 Oracle 数据库，可以按照如下的方式进行 RAID 的设置：文件 需要容量 RAID 类型控制文件 200M RAID 0+1Redo 日志文件 300GB RAID 0+1系统表空间 50GB RAID 0+1核心生产数据表空间 1

14、TB RAID 0+1索引表空间 500GB RAID 0+1归档日志空间 200GB RAID 0+1回滚表空间 200GB RAID 0+1其他数据表空间 1TB RAID 5历史数据文件 1TB RAID 5XXXX 核心系统主机升级/存储升级/系统迁移项目-6-本次方案我们根据标书要求选择 HP EVA 8400 存储设备作为推荐产品，满足本次建设要求。 HP EVA 8400 控制器最大支持 22GB Cache。支持 FC、FATA 和 SSD 磁盘。为了满足随机 IOPS 18000 的要求，我们按照单块 15000rpm 的 SAS 磁盘可以提供 300400 个IOPS 计算

15、，即我们至少需要配置 50 块左右的磁盘。按照容量计算，我们配置 48 块转速15000rpm、容量为 450GB 的 FC 磁盘，以满足性能要求。1.1.4存储交换机主机和存储设备通过 FC SAN 进行互联，根据标书要求采用两台 Brocade 300E SAN 交换机实现主机和存储设备的互联，保证连接性能的同时消除链路层的单点故障。每台交换机激活 16 端口，满足当前主机和存储链接需求。71.2 数据迁移方案本次系统迁移的目标是在 4 小时停机维护时间内完成数据在两个数据中心 RAC 环境内的迁移，两地数据中心之间通过 1000Mbps 的以太网链路互联。我们在本方案中建议以下三种方式实

16、现 Oracle 数据库的数据迁移： RMAN Backup/Restore 通过全备份、增量备份实现数据迁移 实现方式简单，迁移成本较低 需要较长的停机维护时间 Oracle DataGuard 迁移 通过建立 Active-Standby 的模式运行实现数据自动复制，通过 switchover 的方式实现主备中心的切换，实现数据迁移 需要主-备中心使用相同服务器硬件平台 借助第三方工具（Quest SharePlex）迁移 通过建立 Active-Standby 的模式运行实现数据自动复制，通过 switchover 的方式实现主备中心的切换，实现数据迁移 支持异构平台 需要第三方工具支持

17、，成本较高1.2.1RMAN Backup/Restore 迁移正式迁移前使用 RMAN 全备份源数据库，通过 1000Mbps 网络将备份数据传输至目标数据中心，通过 RMAN restore 将数据库在目标端恢复。每天增量备份数据库，将增量备份数据通过 1000Mbps 网络传输至目标数据中心，通过 RMAN Restore 将每天的增量数据恢复。正式迁移开始时，中断源数据库的客户端访问连接，通过 RMAN 增量备份数据库，将增量备8份数据通过 1000Mbps 网络传输至目标数据中心，将源数据库最后的增量部分在目标数据库恢复。该方法恢复数据库实现方式简单，不需要对源数据库进行设置变更，不

18、影响源数据库的正常运行；但该方式迁移数据库需要较长的迁移周期，同时需要安排一定的停机时间，以保证数据的完整迁移。1.2.2Oracle DataGuard 迁移DataGuard 方案是在新主机存储设备划分好、操作系统和数据库软件安装完毕之后，通过在新的磁盘阵列上创建与原有的数据库一样的卷组(VolumeGroup，简称 VG)，接着再在各个 VG 内创建与原有数据库完全一致的逻辑卷 (LogicalVolulne，简称 LV)，归档日志所在目录以及 oracle的 bdump、cdump 和 udump 必须和原有的数据库相应目录设置成一致。然后在原有数据库上做全库的 RMAN 备份，再在新

19、的磁盘阵列上利用 RMAN 备份生成的文件做新的数据库的恢复，并且将新的数据库一直处于 managed recovery 状态，在此状态下，原有数据库上生成的归档日志，可以在新的数据库上应用，以保证新的数据库与原有的数据库不断同步。在需要进行测试的时候，可以先将新的数据库做一次 RMAN 备份，然后将新的数据库至于 open 状态，新数据库就可以进行交易验证测试了。验证测试完成之后，将新的数据库再次恢复，此时恢复采用的文件为新数据库叩即前所做的 RMAN 备份的文件，然后再和迁移前的数据库通过应用归档日志保持不断同步。当执行数据库正式切换时，将迁移前的数据库所在的应用全部正常关闭，保证不再有新

20、的数据库记录产生，然后插入相应的验证数据，再连续切若干个归档日志，保证在线联机日志中不再保留任何数据，将生成的所有归档日志全部在新的磁盘阵列所在的数据库上进行应用，然后将新的数据库至于打开状态，这样新的数据库就能正常对外提供服务了。DataGuard 的迁移流程如下图所示。9DataGuard 方案所使用的软件、工具和命令均为安装了 Oracle 10g 企业版所自带，不再需要另行购买。流程的实施具有一定难度，尤其还要保证不影响现有的系统的正常运行。 DataGuard 整个实施流程中涉及到的所有命令的学习和掌握都需要一定的时间，生产数据库和新数据库之间的归档日志如何自动传输以及归档日志如何自动在新数据库上进行应用，都需要认真考虑解决方案。DataGuard 方案不能对现有的数据库做表空间大小的优化调整，它只能保持新数据库所有的数据文件和现有的数据库数据文件完全一致。但由于采用该方案，之前的数据库信息可以提前同步，在正式切换时，需要同步的数据比较少，因而导致停业的时间比较短。在 DataGuard 的三种模式中选择最大性能模式，可以尽可能地减少对现有生产数据库的性能影响。1.2.3借助第三方工具（Quest SharePlex）迁移此方式和 2.2 节 Oracle DataGuard 的方法和原理是一样的。下图所示为 SharePlex for Oracle 的基本结构：