数据迁移的八大步骤

数据迁移的八大步骤
数据迁移的八大步骤

数据迁移的八大步骤

-天互数据

根据IDC的统计数据显示,只有60%的迁移工作是按时完成的。而造成数据迁移延迟的最大原因之一便是托管服务提供商没有对企业客户现有的基础设施实施详细的分析,进而了解细微差别,并挖掘核心的问题。如果托管服务提供商们对于企业客户的架构的复杂性有了较强的了解,那么,他们就能够有针对性的对迁移过程中可能发生的任何暂时性的小问题进行规划。

您的企业是否需要实施迁移数据

在深入钻研如何完成一项成功的数据迁移的步骤之前,您应该首先确认的是您企业是否真的需要实施数据迁移。通常,数据迁移工作是在企业经历了显著的业绩增长和客户量增长的前提下进行的。相关业务量和客户数量的显著大幅增加会对企业现有的资源供应带来相当的压力,也就意味着您的公司可能需要通过将数据迁移到一个更大的服务器来扩大其托管功能。

而搞清楚贵公司当前业务的发展周期的阶段,以便保持领先,避免企业在成长过程中的麻烦是相当重要的。而如若未能成功做到这一点的话,您企业的客户可能会遭遇到带宽问题或在您企业的现有架构步伐满足业务的非线性增长的前提下发生停机。

如何选择一家托管服务提供商

当企业用户在选择一家托管服务提供商时,保持开放的沟通是至关重要的。在理想的情况下,您企业应该被潜在的服务供应商指定一个专门的接洽小团队,该团队将与您一起完成整个数据迁移过程。企业用户要尽量避免在该过程中被供应商向踢皮球一样在迁移过程中的每一步,都被转移到由服务供应商的不同团队接手,毕竟,就像厨房里有太多的厨师会增加不必要的复杂性一样,何况数据迁移工作的本身就已经够复杂的了。

当在评估托管服务提供商时,您应该明确托管服务公司的责任与他们期望您所做到的事情。如果没有对这一点的清晰的认识,您可能会认为某些事务将交由托管服务提供商来处理,而事实上,这应该是您企业应该自行完成的。您也应该把您的关注重点放在最初的关于供应商将如何为您公司的应用程序的各个部分实施解剖,并确认他们如何打算对这各个部分实施单独迁移的讨论方面。同时,不要害羞,大胆的询问他们在过去经手过哪些类似的迁移技术堆栈,并在这些迁移过程中获得了怎样的感悟,当初的迁移工作花了多长时间等。

如何成功地完成数据迁移

既然您已经确定您企业的确需要将数据迁移到一台更大的服务器,而且也已经选定了您的托管服务提供商,那么,您就应该遵循如下的步骤,来确保您企业的数据迁移工作获得成功了。

注意:如下每一个步骤均提供了一个估计的完成时限;但是,这一时间框架将随着每家企业数据迁移项目具体要求的不同而存在一定差异性。

步骤1:定制解决方案架构师

坚如磐石的托管架构是以每套解决方案的特定客户的具体需求实施定制化设计的。类似于建筑的设计师一样,其需要花费相当的时间来实施规划,并确定如何最好地构建一套完善的基础设施,而托管解决方案的架构师同样需要在规划阶段花费大量的时间。通过充分了解系统架构,托管解决方案架构师才可以创建出一套定制化的解决方案,以匹配您企业迁移工作的所有具体需求。

时限:1-2小时的Q&A。

步骤2:搭建,配置与前期预测试

一旦您的托管服务提供商根据您企业的具体需求在步骤1的基础上清晰设计好了您企业的新的自定义架构,您应该测试几次,确保所有必要的库文件,数据包和配套软件是否安装正确。这一步骤能够有助于您评估新架构的性能,冗余,故障转移,库和应用程序的安装,监控,预警和操作系统的要求。

时限:不到一个小时到几天,取决于解决方案的复杂性

步骤3:将您的数据迁移到新系统

一旦您企业新的架构已通过测试并获得批准,与您的托管服务提供商合作以确定任何数据必须进行同步,并确保所有必要的更新已被复制和抓获是非常重要的。由于数据对企业的至关重要性,您的团队应该负责完成数据和数据库实际迁移到新架构的工作。通过这种方式,可以确保迁移工作能够按照您的需要完成,并让您企业能够确定相关的数据已然被正确迁移,捕获和复制。

时限:取决于数据规模的不同,贯穿整个步骤1到步骤5的过程;并将继续贯穿至步骤8。

步骤4:同步您的数据库

当数据被迁移到新系统后,您应该验证数据库信息的配置和安全。所有以前存储在您企业托管环境中的结构化数据都应自动和立即复制到新的托管环境中,这样在迁移过程中不会发生停机时间,也就不会对客户体验造成任何影响。

时限:取决于数据规模的不同,贯穿整个步骤1到步骤5的过程;并将继续贯穿至步骤8。

步骤5:迁移您企业的

您的托管服务提供商应该重新定向您的公共网站的DNS记录,使其指向高可用负载平衡器,其将立即重定向连接回到您企业以前的基础设施。这种重定向应该向客户和应用程序完全透明,并确保在这个过程中对您的客户流量没有任何延迟或干扰。允许新的DNS信息传播一周的时间,以确保DNS传播延迟不会影响您的客户体验。

时限:贯穿步骤6和7,但通常持续至少一周。

步骤6:执行您的代码

现在,您需要在您迁移新的主机平台中执行并实现定制化的代码。在这一步中,客户也可以与托管服务提供商合作,以确保所有必要的库,数据包和配套软件被妥善安装。

时限:取决于客户的需求。

步骤7:利用现场数据测试您的代码

这一步骤是非常重要的。您将需要测试您真正的代码,用真实的数据,以确保应用程序的准确性和完整性。在此阶段,该数据库有实时信息以及本地数据量,已经收到包括复制的和用于活动站点的现有数据增量更新。鉴于您对于企业的应用程序,功能和特性的深入了解,托管服务提供商一般会依赖于您企业自身来完成测试数据的同步和复制数据库的完整性。

时限:取决于客户的需求。

步骤8:转换交换机

最后,由于数据库和数据量的不断迁移、更新,所有的数据都是实时的,并要准备好支持客户。您企业应该有一个预定的维护窗口,以方便托管服务提供商能够为客户流量“转换交换机”,直接从旧的服务器转换到新的、经过测试的数据托管环境。

时限:约一秒钟。

即使您严格遵循上述每一个步骤,您企业仍然可能需要采用某些额外的步骤来满足您所有的具体需要,进而实现一个完整的数据迁移。正如前面提到的,保持与服务供应商的紧密合作关系是至关重要的,并要求您的托管服务提供商必须提供详细的迁移计划,避免迁移过程中可能出现的麻烦。

数据迁移方案

数据迁移方案 作者:Han.Xue 信息系统数据迁移需要考虑的因素很多,比如操作系统类别、数据库类型、版本、数据结构、数据规模、最小允许宕机时间等等。 对于本项目,假定满足下列条件: 1、操作系统一致 2、数据库类型一致,均为Microsoft SQL Server 3、数据库版本均为SQL Server 2000 现存在两种数据迁移的考虑,第一种是新旧数据库系统采用相同数据结构存储,第二种是新旧数据库系统采用不同数据结构存储。下面分别详细说明。 一、不同数据结构的数据升迁 新系统建设完成后,需要对旧系统中数据进行升迁。对于从旧系统中升迁历史数据,需要首先建立旧系统历史数据与新系统数据结构的对应关系,并根据对应关系建立数据逻辑视图。然后使用导入导出工具将历史数据一次性导入到新系统中。数据升迁工作需要遵循以下原则: 1.数据项长度不一致的处理 对于新系统与旧系统的数据项长度不一致的,为了防止数据丢失,应以数据项较长的为准。 2.代码标准不一致的处理 对于新系统与旧系统的同一数据项,而代码标准不一致的,需要

建立代码对照表交由用户审定后再进行升迁。 3.数据采集方式不一致的处理 旧系统为代码输入项目,新系统为手工录入项目的,数据升迁时直接将含义升迁至新系统中。旧系统为手工录入项目,新系统为代码输入项目的,数据升迁时应将数据导入临时表中,由用户确认这些数据的新代码后再导入正式库。 4.增减数据项目的处理 新系统中新增的数据项目,如果为关键非空项,在数据升迁时需要由用户指定默认值或者数据生成算法。旧系统有而新系统已取消的数据项目,原则上升迁至该记录的备注字段。对于没有备注项目的,需要与用户协商是否需要继续保留。 5.历史数据归档的处理 这种数据交换模式为大量、批量、一次性执行的工作。此项工作要求需要支持异常终断后继续,并且在完成数据升迁后,需要出具数据升迁报告交由用户审核确认。如果数据升迁工作顺利完成,原有一期系统数据在备份并刻录光盘后,将不再保留。 6.完成此项工作提交的文档: 1)数据升迁报告 2)新旧系统代码项对照关系备忘录 3)新版系统中取消数据对象、数据项备忘录 4)新版系统由于历史数据升迁工作要求数据结构修订备忘录 5)历史数据清理工作备忘录

数据库迁移实施方案

数据库系统和网络存储系统项目数据库迁移实施方案

文档控制文档修订记录 审阅 分发

目录 第一章文档介绍 (4) 1.1背景 (4) 1.2目标 (5) 第二章系统硬件选型 (6) 2.1存储设备 (6) 2.1.1 设备选型 (6) 2.1.2 设备功能及实现 (6) 2.2服务器设备 (6) 2.1.1 数据库服务器 (6) 第三章系统安装 (9) 3.1主机系统安装 (9) 3.2配置SAN网络、磁盘阵列 (10) 3.3配置HACMP (11) 3.4安装数据库软件 (12) 第四章数据移植 (13) 4.1移植准备工作 (13) 4.2移植过程 (14) 4.3系统检查 (15) 数据库检查 (15) 导入后系统需要完成的工作 (15) 应用检查 (16) 4.4系统回退 (16) 第五章应用迁移 (17) 第六章新系统上线后的工作 (17) 第七章工作界面和工作内容 (17) 第八章实施计划 (19) 附件: (20) 1.设备、软件验收交付记录 (20) 2.操作系统安装 (21) 3.操作系统镜像 (26) 4.设备配置清单(需确认) (28) 4.1 IBM p570服务器 (28) 4.2 光纤交换机配置 (31)

第一章文档介绍 1.1背景 HP公司全面转向X86芯片,使用PA-RISC芯片的HP 9000服务器现已停产,虽然Oracle R12已经可以支持Itanium平台上的HP-UX,但某电厂应用系统目前是 VXX.X.XX,而某应用软件 VXX版本目前尚不能运行于Itanium平台,故准备将系统迁 移至新硬件平台(IBM power处理器)。 本次项目的主要目标是对包括如下几点: 1) 存储设备及小型机设备的选购 采购一台新磁盘阵列提供服务,替换过去的旧存储设备,磁盘按现有存储容量预期的1.3至1.5倍配置, (RAID10或RAID5提供冗余保护,热备盘提供磁盘 的在线替换),空间考虑为_T(为以后的扩容考虑需要,最大支持在_T),如可能涉 及到系统日后的扩容、容灾及测试空间需求,可对存储适当增加扩展柜来扩充容量。 2)系统硬件规划及配置 当前硬件系统按应用规划要求划分LPAR分区,并基于两台服务器分区之间实现集群配置。 3)数据库移植 包括移植准备、移植实施、移植检查及移植后最终上线,同时处理在移植过程中出现故障的回退恢复步骤。 4)应用迁移 1.2目标 针对某电厂实际业务需求,本次建议方案提供数据库的迁移,新采购设备选购、系统配置及业务上线测试到最终的迁移。

数据迁移

第六章数据迁移 数据迁移是数据系统整合中保证系统平滑升级和更新的关键部分。在信息化建设过程中,随着技术的发展,原有的信息系统不断被功能更强大的新系统所取代。从两层结构到三层结构,从Client/Server 到Browser/Server。在新旧系统的切换过程中,必然要面临一个数据迁移的问题。 6.1 数据迁移的概念 原有的旧系统从启用到被新系统取代,在其使用期间往往积累了大量珍贵的历史数据,其中许多历史数据都是新系统顺利启用所必须的。另外,这些历史数据也是进行决策分析的重要依据。数据迁移,就是将这些历史数据进行清洗、转换,并装载到新系统中的过程。数据迁移主要适用于一套旧系统切换到另一套新系统,或多套旧系统切换到同一套新系统时,需要将旧系统中的历史数据转换到新系统中的情况。银行、电信、税务、工商、保险以及销售等领域发生系统切换时,一般都需要进行数据迁移。对于多对一的情况,例如由于信息化建设的先后,造成有多个不同的系统同时运行,但相互间不能做到有效信息共享,所以就需要一套新系统包容几套旧系统的问题。 数据迁移对系统切换乃至新系统的运行有着十分重要的意义。数据迁移的质量不光是新系统成功上线的重要前提,同时也是新系统今后稳定运行的有力保障。如果数据迁移失败,新系统将不能正常启用;如果数据迁移的质量较差,没能屏蔽全部的垃圾数据,对新系统将会造成很大的隐患,新系统一旦访问这些垃圾数据,可能会由这些垃圾数据产生新的错误数据,严重时还会导致系统异常。 相反,成功的数据迁移可以有效地保障新系统的顺利运行,能够继承珍贵的历史数据。因为无论对于一个公司还是一个部门,历史数据无疑都是十分珍贵的一种资源。例如公司的客户信息、银行的存款记录、税务部门的纳税资料等。 6.2 数据迁移的特点 系统切换时的数据迁移不同于从生产系统OLTP (On-line Transaction Processing),到数据仓库DW(Data Warehouse)的数据抽取。后者主要将生产系统在上次抽取后所发生的数据变化同步到数据仓库,这种同步在每个抽取周期都进行,一般以天为单位。而数据迁移是将需要的历史数据一次或几次转换到新的生产系统,其最主要的特点是需要在短时间内完成大批量数据的抽取、清洗和装载。 数据迁移的内容是整个数据迁移的基础,需要从信息系统规划的角度统一考虑。划分内容时,可以从横向的时间和纵向的模块两个角度去考虑。 横向划分

数据迁移整合方案

1.历史数据的迁移整合 本次系统是在原有系统的基础上开发完成,因此,新旧系统间就存在着切换的问题。另外,新开发的系统还存在与其他一些应用系统,例如,企业信用联网应用系统、企业登记子网站、外资登记子网站等系统进行整合使之成为一个相互连通的系统。本章将针对新老系统迁移和整合提出解决方案。 1.1.新老系统迁移整合需求分析 系统迁移又称为系统切换,即新系统开发完成后将老系统切换到新系统上来。 系统切换得主要任务包括:数据资源整合、新旧系统迁移、新系统运行监控过程。数据资源整合包含两个步骤:数据整理与数据转换。数据整理就是将原系统数据整理为系统转换程序能够识别的数据;数据转换就是将整理完成后的数据按照一定的转换规则转换成新系统要求的数据格式,数据的整合是整合系统切换的关键;新旧系统迁移就是在数据正确转换的基础上,制定一个切实可行的计划,保证业务办理顺利、平稳过渡到新系统中进行;新系统运行监控就是在新系统正常运转后,还需要监控整个新系统运行的有效性和正确性,以便及时对数据转换过程中出现的问题进行纠正。 系统整合是针对新开发的系统与保留的老系统之间的整合,以保证新开发的系统能与保留的老系统互动,保证业务的顺利开展。主要的任务是接口的开发。1.2.需要进行迁移整合的系统 1.3.数据迁移整合分析 根据招标文件工商总局新建系统的数据库基于IBM DB2,而原有系统的数据库包括ORACLE,SQL Server,DB2。这种异构数据在总局主要存在于两个方面,

即部门内部的异构数据和上下级部门之间的异构数据。同时,系统的技术构件有.NET和J2EE两大类。 对于部门内部的异构数据的集成采用数据移植的方法,如:如果数据有基于DB2管理的,有ORACLE管理的,有SQL Server管理的,就根据新系统DB2的要求,把ORACLE的数据迁移到DB2数据库中,把SQL Server的数据迁移到DB2数据库中。 上下级国工商局之间的异构数据的集成利用数据交换系统来完成,重点在于数据库存储标准、交换标准的制定和遵守,保证数据的共享,这部分工作由数据中心完成。 1.4.系统迁移和整合目标 1.4.1.系统迁移的主要目标: 1.保证系统正常运行 在数据转换过程中,由于原有的系统数据的复杂性,给数据转换工作带来了很大的难度,为了在新系统启动后不影响原系统正常的业务,因此数据转换完成后,必须保证新系统的正常运行。 2.保证原有系统在新系统中的独立性 原有系统是独立运行的系统,数据在新系统中虽然是集中存放的,但是各个系统由于存在业务上的差别,数据在逻辑上应当保持一定的独立性。 1.4. 2.系统整合的目标: 保证直接关联的系统互动,保证业务的正常办理。例如公众服务系统与基本业务系统之间互动,基本业务与协同业务之间互动等等。

xx数据迁移方案

正本 招标人:XXXX 项目名称:电信机房迁移项目 (数据库升级部分) 投 标 文 件 投标方全称:XXXX股份有限公司 2012年02月20日

前言 首先,非常感谢各位领导及专家给予XXXX参与“XXXX数据库迁移项目”的机会,我们凭借自身综合实力及多年系统集成,提交本方案,望能采用。 XXXX集团(原青鸟软件股份有限公司)起源于北京大学,是一家专业从事软件与信息技术服务的大型企业集团(以下简称“XXXX”),XXXX集团以XXXX股份有限公司为核心企业, XXXX活跃在新经济下企业转型服务领域,并在咨询服务、软件开发、系统集成以及运维服务四个核心业务领域积累了世界领先的专业技术和服务经验,与50多家国际著名管理咨询公司和软硬件厂商结成战略合作联盟,与3000多家国内集成商紧密合作,为数万家客户提供信息技术服务和应用软件解决方案及相关服务,在金融、能源、政府及企业领域建立起了卓越的声誉和品牌,是客户最佳的信息技术发展战略合作伙伴。 针对本项目,XXXX具有如下优势: 集成优势 XXXX作为一级系统集成商,对系统集成有着深刻的认识;同时设计和实施过在众多数据中心、大型业务系统的软硬件平台,有着丰富的建设经验;针对应用的高可用性和业务的连续性有着深入的研究,结合用户的具体需求,我们将提供全面、合理的解决方案。 产品优势 XXXX是IBM、HP、SUN小型机;ORACLE、SYBASE数据库;IBM、ORACLE中间件及试测软件;EMC、HDS存储;CISCO、AVAYA网络设备;APC机房设备等高级别代理商,对各类产品有深入细致的了解,能为贵校提供最优的解决方案。 完善的质量保证体系 ISO9001质量保证体系是质量管理标准和质量保证标准。XXXX为了进一步提高公司的管理水平,确立了以客户为中心的质量体系,并将其定义到整个系统集成的设计/开发、供应、安装和服务领域。本地化服务能力 上海XXX员工逾200人,技术人员50余名,其中包括小型机、中型机、存储、数据库、智 能化、软件、项目经理人及网络工程师若干名,具备较强的技术力量和集成能力。 公司特为此项目成立豪华项目小组,由公司销售总监担当项目组长,监控整个项目的实施过程,并组建15人的技术服务团队(有厂商资格认证的工程师)配合厂商为用户提供全方位的技术服务。 优惠政策 公司根据本实验室的建设目标、主要任务和功能定位,特免费赠送对改实验室建设有帮助的一款系统软件数据统计软件,希望能够充分的帮助学校更好的建设此实验室。 科研合作 近期,国家加大了对“产学研”过程的扶持与引导力度,而XXXX也一直致力于出身高校(前北大系)服务于高校的准则,大力与高校进行校企合作。充分利用高校的人力资源与科研能力,在金融、电力、能源、高教等领域共同开发出适合市场需求的产品,并树立良好的品牌。因此,希望通过此次参与上海交通大学项目,能够有机会更进一步与贵校在内容安全领域有更多的科研合作,通过XXXX现有的用户群来做市场推广。 本着与XXXX建立全面、持久、稳定、良好的业务合作关系,我们郑重承诺: 以丰富的项目实施能力、雄厚的资金实力,以方便、快捷的本地化服务特点为保障,确保XXXX数据库升级项目的顺利实施。

大数据环境下的数据迁移技术研究_王刚

Microcomputer Applications Vol. 30, No.5, 2013 研究与设计 微型电脑应用 2013年第30卷第5期 ?1? 文章编号:1007-757X(2013)05-0001-03 大数据环境下的数据迁移技术研究 王 刚,王 冬,李 文,李光亚 摘 要:数据是信息系统运行的基础和核心,是机构稳定发展的宝贵资源。随着信息系统数据量成几何级数增加,特别是在当前大数据环境和信息技术快速发展情况下,海量数据迁移是企业解决存储空间不足、新老系统切换和信息系统升级改造等过程中必须面对的一个现实问题。如何在业务约束条件下,快速、正确、完整地实现海量数据迁移,保障数据的完整性、一致性和继承性,是一个关键研究课题。从海量数据管理的角度,阐述了海量数据迁移方法,比较了不同数据迁移的方案特点。 关键词:大数据;数据迁移;存储 中图分类号:TP391 文献标志码:A Data Migration Technology Research Based on Big Data Environment Wang Gang 1, Wang Dong 2, Li Wen 3, Li Guangya 2 (https://www.360docs.net/doc/af13177865.html,rmation Center of Shanghai Municipal Human Resources and Social Security, Shanghai200051, China; 2. Wonders Information Co., Ltd., Shanghai201112, China; 3. Shanghai Institute of Foreign Trade, Shanghai201600, China) Abstract: The data is the core resource of the information system, it is the basis of the enterprise, With the continuous of business, a geometric increase in the amount of data generated by the information system, especially in the case of current data environment and information technology. The massive data migration is a real problem. With the business constraints, the massive data migration is a key research topic, in this paper, from the point of view of the massive data management, elaborated a massive data migration me-thod, and compare the characteristics of different data migration program. Key words: Big Data; Data Migration; Storage 0 引言 数据一直是信息系统的基础和核心。一方面,随着企业业务的发展,信息系统覆盖面的扩大,管理和服务精细化层度的深入,集中式的管理信息系统正在不断应运而生,各行各业都先后出现了规模庞大的数据中心。这些数据中心经过一段时间的运行,其数据量正成几何级增长,有的甚至可以达到TB 级或PB 级。另一方面,新的技术架构和业务操作对性能指标提出了更高的要求,而这些要求往往需要通过软件升级或者硬件更新的方式来实现,因而在新老系统的切换或升级改造过程中,势必会面临一个现实问题――数据迁 移。吕帅[1] 等人从分级存储管理的角度提出了混合存储环境下的数据价值评估模型和迁移过程控制理论,提出了数据价 值的精确判定。徐燕[2] 等人利用编程基础实现了异构数据库系统间的数据迁移,提出了数据迁移的抽取、转换和载入3个过程。李喆[3]等从项目管理和方法论角度描述了企业级数据迁移的过程。张玺[4]针对数据从磁盘到磁带的数据迁移问题,提出了并行文件处理方式。丛慧刚[5]等人,从元数据角度,提出了数据迁移中元数据对映射模式体系,对采用源数据驱动ETL 引擎进行功能实现。这些研究都是根据具体工程中数据迁移这个关键问题进行了研究,但是随着信息技术 的发展,针对数据迁移整体管理缺少研究。本文结合某特大 型城市社会保险信息系统管理过程中大数据环境下,海量数据迁移问题进行整体分析,对可能需要大数据迁移的驱动因素和在数据迁移过程中需要关注的各类风险点进行了汇总分析,根据这些风险对数据迁移的各类方案进行分析、研究和论述,最后针对实际工作给出了实际应用。 1 数据迁移驱动分析 1) 新老系统切换需要:数据作为企业的核心资源,是 企业业务连续和发展的基础,因此当信息系统更新或者新老系统切换时,需要对老系统的数据进行整理,抽取,并按照新系统的业务逻辑和数据规则进行迁移,以保障业务的连续性。 2) 搬迁或数据中心合并需求:很多政府政策上的指导 引发了组织结构的变化以及数据分布的改变。一个非常有名的例子是美国的金融监管法案 (Ring-Fencing Senario),这个法案要求所有的银行把数据通过几个步骤和高危投资业务进行隔离。而这些步骤会涉及大量的结构性数据(数据库)和非结构性数据(金融交易的图像存档)的迁移。 3) 性能提升需求:由于业务的发展,企业规模的变大, —————————————— 基金项目:核高基重大专项课题(2009ZX01043-003-004-05);上海市教委科研创新项目(11YS205)和上海市高校“085工程”项目资助。 作者简介:王 刚(1974-)男,上海市,上海市人力资源和社会保障信息中心,工程师,本科,研究方向:计算机信息系统集成和安全管理,上海, 200051 王 冬(1972-)男,上海市,万达信息股份有限公司,工程师,硕士,研究方向:信息系统软件工程和数据挖掘,上海,200051 李 文(1972-)女,上海市,上海对外贸易学院,副教授,博士,研究方向:计量经济和数据挖掘,上海,200051 李光亚(1973-)男,上海市,万达信息股份有限公司,教授级高工,博士,研究方向:计算机软件、系统集成、信息安全、软件工程等,上海,200051

关于数据迁移的各种方法

关于数据迁移的各种方法 在项目中经常会遇到系统完全更换后的历史数据迁移问题,以示对客户历史工作的尊重,何况很多数据仍有保留的必要。 那怎么做历史数据迁移呢? 系统分析: 1、分析原有的业务系统 精确到大致的系统功能模块、大致的处理流程即可 2、分析现有的业务系统 精确到大致的系统功能模块、大致的处理流程即可 3、分析两者自己的区别和差异 大致分析一下两个业务系统之间的区别,有助于确定工作量和工作进

4、分析用户对旧有数据的需求 分析对旧有数据的需求,才不至于盲目的全部性的进行迁移 5、分析用户对旧有数据的处理规则 旧有数据的处理规则,一般分为以下几类: 1、基础数据,通常这一类容易迁移,数据格式简单,但是会影响所有的相关业务数据,关注点为数据的主键和唯一键的方式。 2、纯历史数据的导入,仅供参考用的,这一类数据导入容易 2.1 纯历史数据 这一类数据处理起来会比较容易,一次性导入即可,后续采用增量数据导入。 2.2 流程性数据 这一类数据只有在记录完全关闭后才能结束,需要进行增量导入和

数据更新,同时还要进行相关查询界面的开发,以保证旧有数据能够在新系统中查询的到。 3、新老系统表结构变化较大的历史数据 这一类数据的工作量是最重的,就需要仔细去研究新老业务系统的数据结构了。 1、尽量通过甲方单位来收集齐全相关原系统的相关设计文档,这一点对数据分析很有帮助,通过人的感觉和对数据的观察来分析毕竟不太靠谱。 2、在原系统上进行相关数据的观察,了解数据的变化和数据表数据的关系(对于比较难以理解的相关字段很有帮助) 3、比较新老系统数据的差异,如果实在很不靠谱的话,建议按2.2去处理。 系统设计: 1、做完系统分析之后,对相关数据进行归类,基础数据、纯历史数据、变化较大的历史数据

数据库迁移方案v1.0

文档版本:Ver 0.7 市区域卫生信息平台 数据迁移方案 编制单位:东软集团股份 2014年11月12日

文档修改记录

目录 1引言 (2) 1.1编写目的 (2) 2数据库环境概述 (3) 2.1正式数据库环境(旧版) (3) 2.2临时数据库环境(升级) (3) 3数据迁移需求 (3) 3.1软硬件需求 (3) 3.2网络需求 (4) 3.3数据迁移需求 (4) 4数据迁移方案 (5) 4.1正式数据库数据 (5) 4.2临时数据库数据 (6) 4.3数据迁移步骤 (6)

1 引言 1.1 编写目的 本文档用于描述市基于健康档案的区域卫生信息平台由于迎接卫计委标准符合性测评整体升级中数据库整体迁移的说明文档,用以说明目前数据库情况,迁移涉及的容以及迁移需求,需要硬件集成工程师根据实际情况给出合理建议,并指导数据库迁移工作的实施。 本文档的预期读者为: 建设单位:卫生局领导、技术人员、工作人员; 承建单位:硬件集成工作人员、东软平台实施人员。

2 数据库环境概述 2.1 正式数据库环境(旧版) 旧版数据库为正式数据库,做了RAC 集群,其用于2012年、2013年的项目实施采集,于2014年进行项目升级时暂停使用。 说明: 旧版数据库环境,交换库的数据完全无用,中心库的数据偶尔应对上级检查的集成浏览器调阅显示(由于新版浏览器集成未做好) ,且只应用于旧版浏览器的调阅使用。 2.2 临时数据库环境(升级) 说明: 临时数据库环境的数据为2014年升级后采集的数据,数据库均未做集群,平台所有新版应用、综合管理系统、新上线的服务均连接访问临时数据库28。 3 数据迁移需求 3.1 软硬件需求 ? 操作系统字符集为UTF-8; ? 两台小型机虚拟出独立的四台机器,两台作为交换数据库,两台作为中心 数据库,并支持RAC 集群,如下图:

数据库迁移方案

数据库迁移方案 XXXXX公司 XXXX年XX月

文档控制 此文档仅供最终用户审阅,不得向与此无关的个人或机构传阅或复制。修改记录 分发者 审阅记录

1.概述 年前完成XXXXX系统的数据库迁移工作,同时对源库进行小版本升级,有11.2.0.3升级到11.2.0.4版本。 2.迁移前准备工作 3.源库备份 4.目标库恢复 4.1.传输备份文件 从源端拷贝备份文件到目标端指定目录

4.2.还原spfile到pfile RMAN>startup nomount --rman自启动一个实例 RMAN>restore spfile to pfile ‘/u01/initdba.ora’ from ‘/u01/bakup/xxx’; 注意:修改磁盘组名称,归档路径、控制文件路径,日志路径,trace文件路径、remote_listener 4.3.还原控制文件 在其中一个节点上执行。 4.3.1.用pfile启动到nomount状态 RMAN>startup nomunt pfile=’/u01/app/xx/initdba.ora’; 4.3.2.rman执行对控制文件的恢复 RMAN> restore controlfile from '/HS5220/c-2006462633-20170123-03'; Starting restore at 2017-02-04 12:16:56 using channel ORA_DISK_1 channel ORA_DISK_1: restoring control file RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of restore command at 02/04/2017 12:16:57 ORA-19870: error while restoring backup piece /HS5220/c-2006462633-20170123-03 ORA-19504: failed to create file "+DG_DATA" ORA-17502: ksfdcre:4 Failed to create file +DG_DATA ORA-15001: diskgroup "DG_DATA" does not exist or is not mounted ORA-15040: diskgroup is incomplete ORA-15040: diskgroup is incomplete ORA-15040: diskgroup is incomplete ORA-15040: diskgroup is incomplete ORA-15040: diskgroup is incomplete ORA-15040: diskgroup is incomplete [oracle@ora8db1 ~]$ ls -l $ORACLE_HOME/bin/oracle -rwsr-s--x 1 oracle oinstall 239840968 3月15 12:32 /u01/app/oracle/product/11.2.0/db_1/bin/oracle [oracle@ora8db1 ~]$ exit logout [root@ora8db1 ~]# su - grid [grid@ora8db1 ~]$ cd $ORACLE_HOME/bin/ [grid@ora8db1 bin]$ setasmgid setasmgid setasmgid0 setasmgidwrap

完整版新老系统迁移及整合方案

1 新老系统迁移及整合方案 本次总局综合业务系统是在原有系统的基础上开发完成,因此,新旧系统间就存在着切换的问题。另外,新开发的系统还存在与其他一些应用系统,例如,企业信用联网应用系统、企业登记子网站、外资登记子网站等系统进行整合使之成为一个相互连通的系统。本章将针对新老系统迁移和整合提出解决方案。 1.1 新老系统迁移及整合需求分析 系统迁移又称为系统切换,即新系统开发完成后将老系统切换到新系统上来。 系统切换得主要任务包括:数据资源整合、新旧系统迁移、新系统运行监控过程。数据资源整合包含两个步骤:数据整理与数据转换。数据整理就是将原系统数据整理为系统转换程序能够识别的数据;数据转换就是将整理完成后的数据按照一定的转换规则转换成新系统要求的数据格式,数据的整合是整合系统切换的关键;新旧系统迁移就是在数据正确转换的基础上,制定一个切实可行的计划,保证业务办理顺利、平稳过渡到新系统中进行;新系统运行监控就是在新系统正常运转后,还需要监控整个新系统运行的有效性和正确性,以便及时对数据转换过程中出现的问题进行纠正。 系统整合是针对新开发的系统与保留的老系统之间的整合,以保证新开发的系统能与保留的老系统互动,保证业务的顺利开展。主要的任务是接口的开发。 1.1.1 需要进行迁移的系统 1.1.2 需要进行整合的系统 需要与保留系统整合的系统包括: 1、企业登记管理(含信用分类),全国企业信用联网统计分析,不冠行政区划企业名称核准,大屏幕触摸屏系统与企业信用联网应用,企业登记子网站,属地监管传输,网上业务受理之间的整合; 2、外资企业登记管理(含信用分类),全国外资企业监测分析与属地监管传输,外资登记子网站,网上业务受理,大屏幕触摸屏系统之间的整合;

数据迁移的八大步骤

数据迁移的八大步骤 -天互数据 根据IDC的统计数据显示,只有60%的迁移工作是按时完成的。而造成数据迁移延迟的最大原因之一便是托管服务提供商没有对企业客户现有的基础设施实施详细的分析,进而了解细微差别,并挖掘核心的问题。如果托管服务提供商们对于企业客户的架构的复杂性有了较强的了解,那么,他们就能够有针对性的对迁移过程中可能发生的任何暂时性的小问题进行规划。 您的企业是否需要实施迁移数据 在深入钻研如何完成一项成功的数据迁移的步骤之前,您应该首先确认的是您企业是否真的需要实施数据迁移。通常,数据迁移工作是在企业经历了显著的业绩增长和客户量增长的前提下进行的。相关业务量和客户数量的显著大幅增加会对企业现有的资源供应带来相当的压力,也就意味着您的公司可能需要通过将数据迁移到一个更大的服务器来扩大其托管功能。 而搞清楚贵公司当前业务的发展周期的阶段,以便保持领先,避免企业在成长过程中的麻烦是相当重要的。而如若未能成功做到这一点的话,您企业的客户可能会遭遇到带宽问题或在您企业的现有架构步伐满足业务的非线性增长的前提下发生停机。 如何选择一家托管服务提供商 当企业用户在选择一家托管服务提供商时,保持开放的沟通是至关重要的。在理想的情况下,您企业应该被潜在的服务供应商指定一个专门的接洽小团队,该团队将与您一起完成整个数据迁移过程。企业用户要尽量避免在该过程中被供应商向踢皮球一样在迁移过程中的每一步,都被转移到由服务供应商的不同团队接手,毕竟,就像厨房里有太多的厨师会增加不必要的复杂性一样,何况数据迁移工作的本身就已经够复杂的了。 当在评估托管服务提供商时,您应该明确托管服务公司的责任与他们期望您所做到的事情。如果没有对这一点的清晰的认识,您可能会认为某些事务将交由托管服务提供商来处理,而事实上,这应该是您企业应该自行完成的。您也应该把您的关注重点放在最初的关于供应商将如何为您公司的应用程序的各个部分实施解剖,并确认他们如何打算对这各个部分实施单独迁移的讨论方面。同时,不要害羞,大胆的询问他们在过去经手过哪些类似的迁移技术堆栈,并在这些迁移过程中获得了怎样的感悟,当初的迁移工作花了多长时间等。 如何成功地完成数据迁移 既然您已经确定您企业的确需要将数据迁移到一台更大的服务器,而且也已经选定了您的托管服务提供商,那么,您就应该遵循如下的步骤,来确保您企业的数据迁移工作获得成功了。 注意:如下每一个步骤均提供了一个估计的完成时限;但是,这一时间框架将随着每家企业数据迁移项目具体要求的不同而存在一定差异性。 步骤1:定制解决方案架构师

(完整)应用和数据迁移方案

(完整)应用和数据迁移方案 编辑整理: 尊敬的读者朋友们: 这里是精品文档编辑中心,本文档内容是由我和我的同事精心编辑整理后发布的,发布之前我们对文中内容进行仔细校对,但是难免会有疏漏的地方,但是任然希望((完整)应用和数据迁移方案)的内容能够给您的工作和学习带来便利。同时也真诚的希望收到您的建议和反馈,这将是我们进步的源泉,前进的动力。 本文可编辑可修改,如果觉得对您有帮助请收藏以便随时查阅,最后祝您生活愉快业绩进步,以下为(完整)应用和数据迁移方案的全部内容。

第一章. 应用和数据迁移方案 由于xxx生产作业是24小时不间断运作的,因此要求系统能连续运行,并具有很高的安全可靠性,用户希望在以最小的系统停机时间完成生产系统迁移工作。本次系统迁移工作的最大的风险点和难点在于在有限的停机时间内完成数据库的迁移工作。 1.1 数据库迁移的解决思路 xxx数据库系统数据量较大,并且应用系统的可用性要求极高,所以此次升级要求在有限的停机时间内,最大限度的降低风险、数据库业务在新的主机和存储系统上能够正常运行。为了尽可能减少业务系统的停机时间,保证数据库迁移工作的顺利完成,我们基于以往实施的数据库迁移成功案例(1。1T的数据量,迁移时间不超过15分),经过严格的数据库迁移测试,提出了采用数据库Dataguard技术的数据迁移。 采用数据库Dataguard技术的数据迁移的特点: ●对业务的影响小,switchover到新主机的时间小于10分钟 ●一旦新数据库出现问题能够方便的回切到原来的数据库,不丢失差异数据 采用数据库Dataguard技术的数据迁移的主要步骤如下: 1) 在新主机上安装Oracle9i 数据库软件 2) 在新主机上配置Dataguard 数据库(物理standby ) 3) 利用DataGuard技术,主数据库不断的将新产生的数据库归档日志传输到 新主机并将这些归档日志应用到standby数据库,实现主备数据库之间的 数据同步 4) 系统割接期间只需将新主机上的standby数据库切换为主数据库即可 (switchover的时间小于10分钟) 5) 一旦新系统上数据库运行出现问题只需将数据库切换回原来主机上即可, 不会丢失任何数据

系统历史数据迁移方案

新老系统迁移及整合方案 本次总局综合业务系统是在原有系统的基础上开发完成,因此,新旧系统间就存在着切换的问题。另外,新开发的系统还存在与其他一些应用系统,例如,企业信用联网应用系统、企业登记子网站、外资登记子网站等系统进行整合使之成为一个相互连通的系统。本章将针对新老系统迁移和整合提出解决方案。 新老系统迁移及整合需求分析 系统迁移又称为系统切换,即新系统开发完成后将老系统切换到新系统上来。 系统切换得主要任务包括:数据资源整合、新旧系统迁移、新系统运行监控过程。数据资源整合包含两个步骤:数据整理与数据转换。数据整理就是将原系统数据整理为系统转换程序能够识别的数据;数据转换就是将整理完成后的数据按照一定的转换规则转换成新系统要求的数据格式,数据的整合是整合系统切换的关键;新旧系统迁移就是在数据正确转换的基础上,制定一个切实可行的计划,保证业务办理顺利、平稳过渡到新系统中进行;新系统运行监控就是在新系统正常运转后,还需要监控整个新系统运行的有效性和正确性,以便及时对数据转换过程中出现的问题进行纠正。 系统整合是针对新开发的系统与保留的老系统之间的整合,以保证新开发的系统能与保留的老系统互动,保证业务的顺利开展。主要的任务是接口的开发。 需要进行迁移的系统 需要进行整合的系统 需要与保留系统整合的系统包括: 1、企业登记管理(含信用分类),全国企业信用联网统计分析,不冠行政区划企业名称核准,大屏幕触摸屏系统与企业信用联网应用,企业登记子网站,属

地监管传输,网上业务受理之间的整合; 2、外资企业登记管理(含信用分类),全国外资企业监测分析与属地监管传输,外资登记子网站,网上业务受理,大屏幕触摸屏系统之间的整合; 3、广告监管系统与广告监管子网站之间的整合; 4、12315数据统计分析与12315子网站之间的整合; 5、通用信息查询、统计系统与数据采集转换之间的整合; 数据迁移和转换分析 根据招标文件工商总局新建系统的数据库基于IBM DB2,而原有系统的数据库包括ORACLE,SQL Server,DB2。这种异构数据在总局主要存在于两个方面,即部门内部的异构数据和上下级部门之间的异构数据。同时,系统的技术构件有.NET和J2EE两大类。 对于部门内部的异构数据的集成采用数据移植的方法,如:如果数据有基于DB2管理的,有ORACLE管理的,有SQL Server管理的,就根据新系统DB2的要求,把ORACLE的数据迁移到DB2数据库中,把SQL Server的数据迁移到DB2数据库中。 上下级国工商局之间的异构数据的集成利用数据交换系统来完成,重点在于数据库存储标准、交换标准的制定和遵守,保证数据的共享,这部分工作由数据中心完成。 系统迁移和整合目标 一、系统切换的主要目标: ●保证系统正常运行 在数据转换过程中,由于原有的系统数据的复杂性,给数据转换工作带来了很大的难度,为了在新系统启动后不影响原系统正常的业务,因此数据转换完成后,必须保证新系统的正常运行。 ●保证原有系统在新系统中的独立性 原有系统是独立运行的系统,数据在新系统中虽然是集中存放的,但是各个系统由于存在业务上的差别,数据在逻辑上应当保持一定的独立性。

Oracle10g的数据迁移方案(好文章要转)

Oracle10g的数据迁移方案(好文章要转) 2008-07-07 11:31 网上看到一个不错的文章,转帖给大家,包括传输表空间解决跨平台及endian-ness问题的处理方法 找到将数据从仓库迁移到集市的最快方法。 Lora 是Acme银行的数据库管理员,她现在在该银行高层管理团队高级会议上成了大家最关注的核心人物。这次会议的目的是确定一些方法,来使最终用户能够详细分析公司主数据仓库中的数据。会上提出的一种想法是创建几个小型数据集市--每个集市根据一个特定的职能范围存储数据--这样每个数据集市就可以由专门的团队来使用。 为了有效地实现数据集市的方法,数据专家必须能将数据快速、有效地放入数据集市中。该团队面临的挑战就是解决如何用数据仓库中的数据快速刷新数据集市中的数据,而这些数据集市又运行在各个结构不同的平台上。这就是Lora为什么出席会议的原因。她会为移动数据提出哪些可供选择的方法呢? 作为一名经验丰富、知识渊博的数据库管理员,Lora向与会者提供了三种可能的方法,分别是: 使用可移动表空间 使用数据泵(导入和导出) 拖出表空间 本文介绍Lora对这三种可选方法的解释,包括它们的实施细节和优缺点。 可移动表空间 Lora 从可移动表空方法开始介绍。把整个表空间移动到目标系统的最快速方法是用FTP(文件传输协议)或rcp(远程复制)来简单地转移表空间的基本文件。但是,仅仅复制Oracle数据文件还不够,目标数据库必须识别出并导入文件以及相应的表空间,最终用户才能使用表空间数据。使用可移动表空间包括复制表空间文件和使它们中的数据在目标数据库中可用。 在考虑该方法之前必须进行一些审查。首先,对于要转移到目标系统的表空间TS1,它必须是自含式的(self-contained)。也就是说,在该表空间中表的所有索引、分区及其他从属于该表的各数据段都必须在该表空间内部。Lora解释说,如果一个表空间集合包含所有从属的数据段,那么就认为这个集合是自含式的。例如,如果表空间TS1和TS2要作为一个集合进行转移,TS1中的一个表在TS2中有一个索引,则这个表空间集合就是自含式的。但是,如果TS1中的一个表另一个索引在表空间TS3中,则该表空间集合(TS1, TS2)就不是自含式的。 要移动表空间,Lora提议使用Oracle数据库10g中的数据泵导出(Data Pump Export)工具。数据泵是Oracle的新一代数据转移工具,它替换了早期的Oracle Export (EXP)和Import (IMP)工具。这些老的工具使用正则SQL来提取和插入数据,而数据泵则与它们不同,它使用能绕过SQL缓冲区的专用API,从而使操作过程速度变得极快。此外,数据泵可以提取特定的对象,如特定的存储过程或特定表空

应用和数据迁移方案修订稿

应用和数据迁移方案 Document number【AA80KGB-AA98YT-AAT8CB-2A6UT-A18GG】

应用和数据迁移方案由于xxx生产作业是24小时不间断运作的,因此要求系统能连续运行,并具有很高的安全可靠性,用户希望在以最小的系统停机时间完成生产系统迁移工作。本次系统迁移工作的最大的风险点和难点在于在有限的停机时间内完成数据库的迁移工作。 1.1数据库迁移的解决思路 xxx数据库系统数据量较大,并且应用系统的可用性要求极高,所以此次升级要求在有限的停机时间内,最大限度的降低风险、数据库业务在新的主机和存储系统上能够正常运行。为了尽可能减少业务系统的停机时间,保证数据库迁移工作的顺利完成,我们基于以往实施的数据库迁移成功案例(1.1T的数据量,迁移时间不超过15分),经过严格的数据库迁移测试,提出了采用数据库Dataguard技术的数据迁移。 采用数据库Dataguard技术的数据迁移的特点: 对业务的影响小,switchover到新主机的时间小于10分钟 一旦新数据库出现问题能够方便的回切到原来的数据库,不丢失差异 数据 采用数据库Dataguard技术的数据迁移的主要步骤如下: 1)在新主机上安装Oracle9i 数据库软件 2)在新主机上配置Dataguard 数据库(物理standby ) 3)利用DataGuard技术,主数据库不断的将新产生的数据库归档日志 传输到新主机并将这些归档日志应用到standby数据库,实现主备 数据库之间的数据同步 4)系统割接期间只需将新主机上的standby数据库切换为主数据库即 可(switchover的时间小于10分钟) 5)一旦新系统上数据库运行出现问题只需将数据库切换回原来主机上 即可,不会丢失任何数据

Oracle数据库迁移方法

Oracle 数据库迁移 1. 背景: 据项目实施人员反映,部署系统的过程中,有一个最大的问题,那就是平台数据库的迁移。经常会遇到表空间导出导入失败,或是导入过程中数据表丢失或是数据表虽然能导入,但表字段丢失等现象。针对这种情况,我仔细分析了一下:主要原因出在目前的exp/imp 这种数据导入导出工具存在比较大的缺陷,这种缺陷将在后面提到。相比目前这种方式,我这里提供一种比较方便稳定的数据库迁移方案。以下提到的方案,我也多次尝试验证了,并且还很实 在。 2. 数据库迁移方案: 实用环境:Oracle10g 或是以上版本。 原理:利用Oracle10g 提供的数据泵,快速加载以及卸载数据。优点:导入导出数据库快速比较快,且完整,性能稳定。缺点:这种方式只能在装有Oracle 服务器端的软件的机器上应用。完整方案: 这里模拟二个场景: 场景1:实现不同库下不同用户之间表空间的迁移。 假设通过Oracle 数据泵, A 用户UserA 将表空间TA 提取到 A.dmp,而后B用户UserB将A.dmp装载到表空间TB。 第一步:首先在源库(A) 上建一个目录,这个目录用于转储导入导出过程中的数据文件及日志文件。 create directory dumpdir as 'E:\dump'; 注:dumpdir为目录名,它是数据库中的目录对象名, “cdump':为对应的磁盘物理路径。 第二步:给用户授予目录的读写权限。(因为要写日志,这一步是必须的) grant read, write on directory dumpdir to UserA;

第三步:导岀用户UserA下的所有对象: expdp UserA/Password@orcl schemas=UserA dumpfile=expa.dmp DIRECTORY= dumpdir 注: 1、orcl为配置的用于从客户端连接Oracle的连接名。 2、dumpfile 中不能再包含路径 以上三步为数据导岀过程,下面几步为数据导入过程。 第四步:在目标库(B)上创建一表空间(TB)(如果不存),已存则直接到下一步。 CREATE TABLESPACE TB LOGGING DATAFILE 'F:\oracle\product\1020\oradata\orclDB\sde.dbf' SIZE 32M AUTOEXTEND ON NEXT 32M MAXSIZE 2048M EXTENT MANAGEMENT LOCAL; 以上是我本机测试代码 第五步:在目标库上创建用户UserB CREATE USER UserB IDENTIFIED BY "sagis" DEFAULT TABLESPACE TB; GRANT DBA TO UserB; 第六步:在目标库(B)上,创建一个目录对象,如果A、B位于同一个Oracle服务器上,则可以不创建,可以用第一步创建的dumpdir 对象。如果A、B位于不同Oracle服务器,则 需另外创建。 create directory dumpdir as 'c:\dump'; 以不同服务器上Oracle迁移为例,则此时要将第三步创建的expa.dmp 数据文件拷到B服务 器的c:\dump 目录下。 第七步:给用户授予目录对象的读写权限,同第二步。 grant read, write on directory dumpdir to UserB; 第八步:导入数据到B库上用户UserB的表空间TB下 impdp UserB/sagis@sgs directory=dumpdir dumpfile=expa.dmp remap_schema=UserA:UserB remap_tablespace=TA:TB,TC:TD

相关文档
最新文档