XXX数据迁移方案.docx

XXX数据迁移方案.docx

《XXX数据迁移方案.docx》由会员分享，可在线阅读，更多相关《XXX数据迁移方案.docx（20页珍藏版）》请在冰豆网上搜索。

XXX数据迁移方案

正本

招标　人：

XXXX

项目名称：

电信机房迁移项目

（数据库升级部分）

投

标

文

件

投标方全称：

XＸXX股份有限公司

2012年02月２０日

前言

首先，非常感谢各位领导及专家给予XXＸＸ参与“XＸXX数据库迁移项目”的机会，我们凭借自身综合实力及多年系统集成,提交本方案,望能采用。

ＸXXＸ集团（原青鸟软件股份有限公司）起源于北京大学，是一家专业从事软件与信息技术服务的大型企业集团（以下简称“ＸXXX”）,XXＸX集团以ＸXXX股份有限公司为核心企业，XXXＸ活跃在新经济下企业转型服务领域，并在咨询服务、软件开发、系统集成以及运维服务四个核心业务领域积累了世界领先的专业技术和服务经验，与50多家国际著名管理咨询公司和软硬件厂商结成战略合作联盟,与3００0多家国内集成商紧密合作,为数万家客户提供信息技术服务和应用软件解决方案及相关服务,在金融、能源、政府及企业领域建立起了卓越的声誉和品牌，是客户最佳的信息技术发展战略合作伙伴。

针对本项目,XXXＸ具有如下优势:

集成优势

XXXX作为一级系统集成商，对系统集成有着深刻的认识;同时设计和实施过在众多数据中心、大型业务系统的软硬件平台，有着丰富的建设经验；针对应用的高可用性和业务的连续性有着深入的研究,结合用户的具体需求,我们将提供全面、合理的解决方案。

产品优势

XＸXX是IBM、HＰ、SUN小型机;ORAＣＬE、SＹＢASE数据库;IBM、ORAＣＬE中间件及试测软件；EＭC、HＤS存储；ＣIＳCO、ＡVAYＡ网络设备；APC机房设备等高级别代理商，对各类产品有深入细致的了解，能为贵校提供最优的解决方案。

完善的质量保证体系

IＳO９001质量保证体系是质量管理标准和质量保证标准。

XXXX为了进一步提高公司的管理水平，确立了以客户为中心的质量体系,并将其定义到整个系统集成的设计/开发、供应、安装和服务领域。

本地化服务能力

上海XＸＸ员工逾2０0人，技术人员50余名,其中包括小型机、中型机、存储、数据库、智能化、软件、项目经理人及网络工程师若干名，具备较强的技术力量和集成能力。

公司特为此项目成立豪华项目小组,由公司销售总监担当项目组长,监控整个项目的实施过程,并组建1５人的技术服务团队（有厂商资格认证的工程师）配合厂商为用户提供全方位的技术服务。

优惠政策

公司根据本实验室的建设目标、主要任务和功能定位,特免费赠送对改实验室建设有帮助的一款系统软件数据统计软件,希望能够充分的帮助学校更好的建设此实验室。

科研合作

近期,国家加大了对“产学研”过程的扶持与引导力度,而ＸXXX也一直致力于出身高校（前北大系）服务于高校的准则,大力与高校进行校企合作。

充分利用高校的人力资源与科研能力,在金融、电力、能源、高教等领域共同开发出适合市场需求的产品，并树立良好的品牌。

因此，希望通过此次参与上海交通大学项目，能够有机会更进一步与贵校在内容安全领域有更多的科研合作，通过XＸXX现有的用户群来做市场推广。

　　本着与XXＸX建立全面、持久、稳定、良好的业务合作关系，我们郑重承诺：

以丰富的项目实施能力、雄厚的资金实力,以方便、快捷的本地化服务特点为保障，确保ＸＸXX数据库升级项目的顺利实施。

第一章技术方案

1项目方案

1.1生产中心硬件平台

1.1.1系统拓扑结构

XXＸＸ现有数据中心和新建设的数据中心服务器配置的简单拓扑图如下图所示:

现有生产中心数据库服务器硬件平台由两台Sｕnｖ8９0服务器构成，在Solaris10操作系统上运行OraｃleRAC数据库（1０gＲ2），数据文件存放在共享的HPEVＡ8400磁盘阵列上。

本次方案的主要目的是建设新的硬件平台,将数据库从现有平台平滑迁移至新的硬件平台。

本次方案根据招标文件中相关要求，参考当前系统运行状况，选择合适的硬件平台，支持核心数据库系统的稳定、高效运行。

根据本节硬件平台的选择结果，在第２节中我们将会给出相应的数据迁移的几种方案。

1.1.2服务器硬件平台选择

当前数据库服务器采用了Sunv８90服务器，我们的目标是根据现有的硬件配置推算出我们需要的新硬件平台服务器的处理器的配置需求。

衡量OLＴP类应用系统的处理器处理能力的指标有ＣPＵ２006，SPEＣｊbb2005,ＴPC-C等指标。

由于不同厂商的不同时期发布的产品在性能比较上不存在单一的标准,加上部分产品未参与某些指标的公开测试，所以在下面的讨论中我们选择同时发布了SPEＣjbb２０05和CPU200６指标的v890（UｌtrａＳPＡＲCIＶ＋2.1GHｚ处理器）服务器作为基准,作为其他服务器处理器比较的依据。

从httｐ:

//www．tpc.ｏｒg和http：

/／wwｗ.spec．ｏrg可以分别获得主流服务器平台的TPC-C和CＰU２006指标数据。

各个型号服务器的SPECｊbb20０5和ＣPU200６的数据和相应配置如下表所示:

CIＮT2０06

ＣFP2006

ＳPECjbb2005

Ｖ890（8chiｐ，１6corｅ,1.5ＧHｚ）

１１7９8６

V890（８chip，16coｒe，2.1GHz）

154

244846

M300０（１Chip，2Core,2．７GHz）

３３.5

29.5

Ｍ5００0（8Chip,3２Core，2.6GHz）

352

2７8

因为UltrａＳPARCIV+１50０MＨｚ的v890采用的是SPＥCjbb2005指标,我们只能从相关的参考指标来推算出当前Oracle在主流服务器中配置的SＰＡＲC6４芯片性能比较参数。

从上表中可以看出，单颗２.6ＧHz的SPAＲC64芯片性能大约是2.1GＨz　UltrａSPARCIV+芯片的2.3倍,单颗２.１ＧＨzUltraSPARCIV+处理器是同型号1．5GHz主频处理器的２倍。

因此2.6GＨz主频的SＰＡRＣ64处理器性能是UltrａSPＡRC１.５GHz处理器性能的5倍左右。

根据标书要求，服务器满配置需要至少32核心处理器和64GB内存。

根据这一要求,我们从主流的服务器厂商中选择了Oracle的M5０00服务器作为推荐型号，满足本次方案建设要求。

其性能参数如上表所示，可以看出，配置新型号的处理器，考虑到存储设备升级,I/O系统的优化,数据库参数和配置的调整及优化,有充分证据可以表明可以提升当前数据库系统的性能，使得系统的响应时间缩短5~１0倍，系统的吞吐量提高5～10倍左右。

从而系统总体性能上有了１0倍左右的提升。

1.1.3存储部分

OLTＰ是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,具有很高的并发性（大量的交互式用户）,并且是更新密集型的，SQL语句主要以插入、更新和删除为主，要求具有较快的响应时间，以银行系统,订票系统为代表。

由于ＯＬTP应用的业务特点,从性能角度出发，对磁盘子系统有一定的要求。

OLTP系统最容易出现瓶颈的地方除了CPU就是磁盘子系统。

磁盘子系统在OLTP环境中,它的承载能力一般取决于它每秒处理Ｉ／O的数量。

因为在OLＴP环境中，磁盘物理读一般都是dbfilｅ　seｑｕenｔiａｌreaｄ，也就是单块读，但是这个读的次数非常频繁。

如果频繁到磁盘子系统都不能承载其IOＰS的时候,就会出现大的性能问题。

另外磁盘子系统的控制器的Ｃache大小对I/O系统的性能也至关重要，Cache决定了很多事务不需要从物理磁盘存取数据,从而大大缩短了事务处理的时间。

根据标书要求，存储设备的选择需要同时支持FC和iＳCSI协议，IOＰＳ至少达到18０00,控制器缓存至少１6GＢ,可用磁盘容量达到10TB，配置容量需要达到2０ＴB左右。

针对Ｏrａcle数据库，可以按照如下的方式进行RAＩD的设置：

文件

需要容量

ＲＡID类型

控制文件

2０0M

RＡID0+1

Rｅｄｏ日志文件

300GB

RAID　０+1

系统表空间

50GB

RAＩD　０+1

核心生产数据表空间

1TB

ＲAID　0＋1

索引表空间

５0０GB

RＡID　０+1

归档日志空间

2０0GＢ

ＲＡＩＤ０+1

回滚表空间

200GB

RAＩD0+1

其他数据表空间

１TB

ＲAIＤ5

历史数据文件

1TB

RAIＤ5

本次方案我们根据标书要求选择HP　EＶA　8400存储设备作为推荐产品，满足本次建设要求。

HPＥVA8４00控制器最大支持2２GBCaｃhｅ。

支持ＦC、ＦＡTＡ和ＳSD磁盘。

为了满足随机IOPＳ　180０0的要求，我们按照单块1５0０0rpm的ＳAＳ磁盘可以提供300~400个IOPS计算,即我们至少需要配置5０块左右的磁盘。

按照容量计算，我们配置４8块转速15000rｐm、容量为４50GB的FＣ磁盘，以满足性能要求。

1.1.4存储交换机

主机和存储设备通过FＣ　ＳＡN进行互联，根据标书要求采用两台Broｃade300ESAＮ交换机实现主机和存储设备的互联,保证连接性能的同时消除链路层的单点故障。

每台交换机激活16端口,满足当前主机和存储链接需求。

1.2数据迁移方案

本次系统迁移的目标是在４小时停机维护时间内完成数据在两个数据中心RAC环境内的迁移,两地数据中心之间通过１000Mbｐｓ的以太网链路互联。

我们在本方案中建议以下三种方式实现Ｏｒａclｅ数据库的数据迁移：

●RMANBackｕｐ/Ｒestore

⏹通过全备份、增量备份实现数据迁移

⏹实现方式简单,迁移成本较低

⏹需要较长的停机维护时间

●OraclｅDataGuard迁移

⏹通过建立Ａctｉve-Stａndby的模式运行实现数据自动复制，通过swｉtｃhoｖeｒ的方式实现主备中心的切换,实现数据迁移

⏹需要主-备中心使用相同服务器硬件平台

●借助第三方工具（ＱｕｅstShareＰlex）迁移

⏹通过建立Acｔｉｖｅ-Stａndｂｙ的模式运行实现数据自动复制，通过ｓｗitcｈover的方式实现主备中心的切换,实现数据迁移

⏹支持异构平台

⏹需要第三方工具支持,成本较高

1.2.1RＭAN　Ｂａcｋup／Ｒesｔoｒe迁移

正式迁移前使用RMAN全备份源数据库，通过1０00Mｂps网络将备份数据传输至目标数据中心，通过RＭＡNrestore将数据库在目标端恢复。

每天增量备份数据库，将增量备份数据通过1000Mbps网络传输至目标数据中心，通过RMＡNRestoｒｅ将每天的增量数据恢复。

正式迁移开始时,中断源数据库的客户端访问连接，通过RMAN增量备份数据库,将增量备份数据通过1０00Mｂｐs网络传输至目标数据中心,将源数据库最后的增量部分在目标数据库恢复。

该方法恢复数据库实现方式简单,不需要对源数据库进行设置变更，不影响源数据库的正常运行；但该方式迁移数据库需要较长的迁移周期,同时需要安排一定的停机时间,以保证数据的完整迁移。

1.2.2Oracle　DatａGuaｒd迁移

ＤataＧuard方案是在新主机存储设备划分好、操作系统和数据库软件安装完毕之后，通过在新的磁盘阵列上创建与原有的数据库一样的卷组（VolumｅGroup,简称VG），接着再在各个VG内创建与原有数据库完全一致的逻辑卷　（LogicalVｏlulne，简称LV）,归档日志所在目录以及oｒacle的bdｕmp、cdump和ｕdumｐ必须和原有的数据库相应目录设置成一致。

然后在原有数据库上做全库的ＲMAN备份，再在新的磁盘阵列上利用RＭAN备份生成的文件做新的数据库的恢复,并且将新的数据库一直处于　mａnａgedrecｏvery状态,在此状态下,原有数据库上生成的归档日志，可以在新的数据库上应用,以保证新的