医院数据库迁移方案

医院数据库迁移方案
医院数据库迁移方案

XX医院数据库迁移方案

编制单位:XXX科技有限公司

医疗卫生事业部联系电话:189XXXXXXXX

2019年4月2日

文档创建及修改记录

版本号更改条款及内容作者日期

1.0 文档新建XX 2019年4月2日

目录

1引言 (3)

1.1编写目的 (3)

2数据库迁移方案目录 (4)

2.1第一阶段,现场调研硬件网络环境.............................. 错误!未定义书签。

2.2第二阶段,调研软件,存储,信息安全环境.............. 错误!未定义书签。

2.3 第三阶段,形成项目外围基本资料和文档 (3)

3数据迁移文档资料准备 (5)

3.1软硬件文档 (5)

3.2网络环境文档 (6)

3.3数据迁移需求文档 (6)

4数据迁移可行性方案研讨,确立 (7)

4.1确立二种以上的基本方案.............................................. 错误!未定义书签。

4.2项目组与院方专家组对方案进行研讨.......................... 错误!未定义书签。

4.3形成最终方案确立实施合同并签订.............................. 错误!未定义书签。

5 环境准备(硬件,软件,网络,信息安全系统) (7)

5.1对接院方专家组准备相关硬件软件 (7)

5.2对接院方专家组梳理网络环境...................................... 错误!未定义书签。

6 迁移前风险评估,预案设计及预案环境搭建 (7)

6.1对迁移过程中的外部环境风险进行评估 (7)

6.2对评估结果设计相关预案.............................................. 错误!未定义书签。

6.3预案所涉及的备用数据服务器搭建 (7)

7 迁移工作日程表,联络名单,DBA入场 (7)

7.1制作双方工作人员联系名单并建立项目组群 (7)

7.2制作迁移工作日程表...................................................... 错误!未定义书签。

7.3DBA入场进行所有环境评估 (7)

8 正式迁移,工作日志 (7)

8.1按日程表进行数据库迁移 (7)

8.2制作迁移工作日志.......................................................... 错误!未定义书签。

9 迁移完毕试运行,项目验收,DBA离场 (7)

9.1试运行后,项目联合验收,DBA实施完毕 (7)

9.2交接项目文档资料.......................................................... 错误!未定义书签。

10 本项目保障及服务协议订立 (7)

10.1呈报协议模版 (7)

11 本项目费用明细报价 (7)

11.1明细报价 (7)

1 引言

1.1 编写目的

本文档用于描述:XX县中医院医院信息管理系统(HIS)、电子病历信息管理系统(EMR)、检验科信息管理系统(LIS)、影像信息管理系统(PACS)、体检信息管理系统、健康档案信息管理系统、数据库整体迁移;已部署虚拟化环境增容(硬件方式)的说明文档,用以说明目前数据库情况,迁移涉及的内容以及迁移需求,需要硬件集成工程师,数据库管理工程师(DBA级)根据实际情况给出合理建议,并指导数据库迁移工作的实施。

本文档的预期送达者为:

监督单位:XX县中医院分管领导,信息科分管领导,项目现场负责人,后勤保障人员(能源方向)。

实施单位:XX科技总经理,项目技术经理,系统集成工作人员、数据库管理工程师,外围硬件环境,网络环境,信息安全环境保障人员。

为保障数据库迁移过程顺利平稳,本院业务持续有效,本文档预期送达者需要在接收文档之后3个工作日以邮件方式回复文档原作者,并提出修改意见用以参照完善文档并最终形成合同。

2 数据库迁移方案目录

2.1 现场调研网络环境

于2019年3月31日现场调研一次,具体由本院信息科进行填写。

硬件设备用途IP地址备注

2.2 软件,硬件(虚拟机),网络安全环境

于2019年3月31日现场调研一次,具体由本院信息科进行填写。

硬件设备用途IP地址备注

说明:

以局域网为基本架构,在windows server 2008R2 企业版64位基础上,以microsoft SQL server 2008 R2 企业版64位为数据库平台,2台IBM服务器单独运行并联接DELL存储设备作为文件存放,用VMWare Workstation 虚拟机软件进行集群管理的工作模式。

经确认:本院业务系统有如下数据库运行在此环境之中

HIS、EMR 医院业务基本模块、电子病历

LIS 检验科信息管理系统

PACS 影像信息管理系统

健康档案管理信息化系统居民健康档案平台

体检管理信息化系统本院体检管理系统

2.3 形成项目外围基本资料和文档

说明:

对目录中所涉及的外围环境软件和设备进行基本资料登记 并形成文档《项目外围基本资料》。含有如下信息:

服务器信息 用途,负载情况 San 存储访问情况 虚拟机信息 用途,负载平衡情况 San 存储访问情况 交换设备信息 连接点信息,边界关系 网关,路由,防火墙信息 口令(一次性使用) 操作系统信息 口令(一次性使用),基本安装信息

数据库信息 口令(一次性使用),基本安装信息 数据库基本信息及外部接

口信息

双方联络组信息 双方工作人员电话微信 建立群组

3 数据迁移文档准备

3.1 软硬件文档

硬件部分现场调研完成后集合文档,形成《项目准备硬件资料备案表》 软件部分现场调研完成后集合文档,形成《项目准备软件资料备案表》

集合

集合

现场调研资料1

现场调研资料2 备案表1

备案表2

3.2 网络环境文档

迁移同时所使用的临时IP段划分、备用服务器及IP段划分、项目验收时IP段上线划分、分配给客户端的各应用IP能够与正式数据库服务器连通访问;形成文档《网络环境使用文档备案表》

网络存储在迁移时的IP变化,及针对备用服务器的切换方案,迁移完成之后恢复IP变化及服务器访问恢复的解决方案;形成文档《存储网络环境使用访问文档备案表》

3.3 数据迁移需求文档

本院提出的数据库迁移方式及虚拟机增容相关处理方式:

1将新加华为和联想服务器并入虚拟机使用,达到合理分配服务器硬件资源,提高数据库效能,改善院内客户端使用体验,有效提升容灾备份机制的需求。按需求形成文档《数据库迁移需求文档备案》

2因业务持续化服务的刚性要求:需要在整体迁移过程中做到无缝切换,所有业务24小时不能中断并保持数据库在客户端的可连接性。并保证存储的快速切换。按需求形成《数据库迁移规则性文档备案》

3因是公立对社会服务性机构,对风险预警及评估有先兆性且刚性需求。按需求形成《数据库迁移风险评估及预案文档备案》

附表目录:

表3-3文档需求及附表

文档名涉及部门人员文档概述

数据库迁移需求文档备案双方主管领导及项目经理,技术人

员详细描述数据库迁移过程及使用的方法和所需的验收效果

数据库迁移规则性文档备

双方主管领导及项目经理详述政策法规,并规范切换过程风险评估及预案文档备案双方主管领导及项目经理出具评估报告设置相关预案

4 数据迁移可行性方案研讨,确立

4.1 确认二种以上的可行性方案

方案一

将新加华为和联想服务器并入虚拟机使用。需要首先对虚拟化软件进行换代,因本院使用的虚拟化软件版本比较早,现已无法对大容量存储和新

CPU及主板架构的服务器硬件进行管理(无法识别)。需要经审报后采购

虚拟化软件一套,用以管理原服务器(IBM2台)和新加服务器(联想1

华为1)作为集群来承载数据库和软件平台。此项目过程中做足风险评估

以及相关预案(备用服务器及数据库),降低切换过程带来的风险。

方案二

不再使用虚拟机来管理相关业务数据库,全部使用物理主机服务器,单独

运行各自提供1种业务支撑。此项目过程中做足风险评估以及相关预案(备

用服务器及数据库),降低切换过程带来的风险。

4.2 项目组与院方专家组研讨方案

研讨内容

阵述两种方案的利弊:方案一可以有效解决增容服务器提升总体效能的问

题,并保持原来虚拟化平台管理不变,业务支撑方式不变,有利于平稳过

渡,但原服务器(2台IBM)老旧的情况已属事实,在不增加成本的基础

上,将旧服务器并新服务器一同运行,且无双机热备的情况下,依然存在

隐患。旧服务器的故障率和硬件寿命对整个系统运行是一个不容忽视的致

命因素,而且因为媒介外备份也无法保障数据的时效性,所以即使是数据

库迁移成功,也只是一种暂时的替代方案。方案二也可以解决本院增容服

务器的需求,但是会因拆解虚拟机将原虚拟化平台管理的模式更改为单独

服务器管理模式,业务支撑方式也有所变化,不利于平稳过渡,而且在不

建立双机热备机制的情况下,单独服务器的切换过程风险更大,网络环境

依赖更强,不确定性因素比较多。有可能会造成迁移无法确保成功。

4.3 最终方案确立并签订合同

说明:方案确立之后,以方案内容及相关硬件和服务项目签订合同

5环境准备

5.1 对接院方专家组准备相关硬件软件

说明:对接院方检查相关硬件、软件准备情况,做好迁移前的测试工作,将迁移工作中的外围风险降低到最小程度,确保能够无缝切换和无忧切换。

5.2 对接院方专家组梳理网络环境

说明:对接院方检查相关网络环境硬件情况,做到入口出口边界全知晓,并对照《备案表》整理出网络拓普图,为迁移工作的实施和迁移完毕后的正常运行做好准备。

6 迁移前风险评估、预案设计、预案环境搭建

6.1 风险评估

说明:与院方沟通对迁移过程中的硬件风险,软件风险,网络环境风险和外部环境进行列举评估

涉及风险来源风险主体内容评估级别硬件2台IBM服务器老旧极高

软件软件注册方式不明,备用服务

器无法再次注册造成无法运

网络环境并行主要及备用服务器网络

承载量的大小

中低

外部环境软件方技术是否支持中高备用服务器业务需要24小时持续性低

6.2 预案设计

说明:经方案解决后再次评估风险,可有效规避相关风险带来的不良后果和影响,对仍无法避免的高风险项,在双方专家的指导下进行协商处理,并确定处理方法。

6.3 预案环境搭建

说明:使用临时服务器(效能等同或者略低于运行中服务器配置3台)分别支撑HIS 、EMR

以及LIS 、PACS 健康档案 体检系统,在局域网内重新划分IP 段 通过路由制作虚拟IP 地址随时备用。搭建完成后,与院方专家组同时测试备用服务器群组性能,达到预期效果并能有效负载业务之后,再进入下一阶段。

风险主体 解决方案

次级评估

2台IBM 服务器老旧

因成本问题,暂时无法解决,只能用虚拟机管理尽量合理划分负载及对业务合理偏向性支撑

软件注册方式不明,备用服务

器无法再次注册造成无法运行 与软件方进行有效沟通,或可

使用临时注册,完成虚拟化迁

移后,问题解决 中低

并行主要及备用服务器网络承

载量的大小 临时增大网络设备数量级,可单独使用内网交换机连接,保障业务持续

软件方技术是否支持

沟通软件方提供注册授权等支持

7 迁移工作日程表,联络名单,DBA入场

7.1迁移工作日程表

项目工作内容日程

迁移工作现场会,形成方案,风险评估4小时

软件,硬件,网络环境准备8小时

预案制定,备用服务器环境搭建48小时

重构虚拟化环境48小时

从备用服务器迁移数据回虚拟主机48小时

测试主服务器集群10小时

说明:项目进度及时间节点控制一览表

7.2 联络名单

院方人员联系方式责任所属实施方人员联系方式责任所属说明:提前建立项目群组,方便项目双方负责人,技术人员,保障人员的沟通与协调

7.3 DBA入场

说明:DBA Database Engineer数据库管理工程师。专职数据库工程师将在备用服务器环境与其他环境评测达标后2个工作日内进场实施数据库迁移,重构虚拟化,迁移回数据库等工作。并负责项目联合验收及评测工作。并制作《DBA数据库迁移工作计划》

8 正式迁移、工作日志

8.1 正式迁移

说明:DBA 按照《DBA数据库迁移工作计划》进行数据库迁移:

setp1按照院方要求拆解原虚拟化管理平台,同时启用并切换备用数据库服务器提供全院软件平台伺服。

Setp2重构虚拟化,将新加入的服务器(联想1台华为1台)加入虚拟机划分,按照院方要求对数据库承载负荷重新计算,得出最优方案。原则为轻量化健康档案服务器,体检服务器;着重于HIS+EMR服务器;确保LIS,PACS服务器在原有基础上对大容量存储的访问效能增强,速度有所提升。处理迁移过程中的外部环境对接工作以及各种突发状况。

Setp3将数据库迁移回已经重构的虚拟机服务器上,仍然以5个分别独立的虚拟机服务器进行管理,重新匹配存储访问,连接本院内网,恢复整个业务系统运行。

Setp4对迁移结果进行评估。

8.2 工作日志

说明:迁移过程中DBA制作《DBA数据库迁移工作日志》按照数据库迁移过程实施节点和流程表对硬件运行情况,网络环境运行情况,数据库运行情况,虚拟化软件运行情况,业务软件各平台运行情况进行详细记载并归集成日志报表。以备在验收及交接项目时形成档案。

-------------附日志模版8.2-------------

项目工作日志硬件运行情

网络环境运

行情况

数据库运行

情况

虚拟化软件

运行情况

医院业务系

统运行情况

时间节点1 良好峰值缓慢良好良好卡顿时间节点2

时间节点3

9 迁移完毕试运行、项目验收、DBA离场

说明:迁移完毕后,双方技术人员协同进行主群集服务器测试,包含物理服务器性能测试,数据流测试,索引能力测试,存储流测试,虚拟化独立服务器单压力测试,虚拟化群集服务器整体压力测试,最终形成迁移项目系统性能评估报告,呈报院方分管领导。同期保障运行10小时,及时发现和处理外部及内部易于发现的问题及数据库隐患,提供相关增值服务。项目验收在相关测试结束后,本项目将与院方技术人员进行技术交接。并于技术验收前移交相关技术文档及联络方式,保持长效沟通交流机制,给予持续技术支持。DBA离场在技术验收之后,DBA 与项目负责人将与院方领导进行项目总验收之后离场。

技术文档目录:

1.《首次现场调研参考备案资料》

2.《系统外围基本环境资料目录》

3.《数据迁移软,硬件文档》

4.《数据迁移网络环境文档》

5.《数据迁移需求文档》

6.《项目可行性方案研讨纪录(决议)》

7.《项目合同》正本1份,副本1份

8.《项目实施风险评估备案表》

9.《项目实施风险解决方案》

10.《预案相关备用服务器环境搭建配置明细》

11.《迁移工作日程表(流程)》

12.《项目实施双方联络表群组备案》

13.《DBA数据库迁移工作日志》

14.《项目技术验收报告》

15.《项目验收报告(呈报)》

10 本项目保障及服务协议订立

说明:本次迁移项目结束后,双方保持良好合作关系,将持续提供与该项目有关的技术支持直至2019年6月30日止,期间包括三次上门巡查服务,DBA远程支持服务三次,以期获得最佳的服务检验及更加完善的数据库知识体系,帮助院方建设更有保障的信息化服务平台。另外服务期终止后,仍可以以签订《DBA级数据库保障服务协议》的方式继续本服务内容直至再次终止。我公司承诺协议金额原则上不高于本次项目金额的25%。如果双方就相关意向达成统一意见之后,将呈报本协议模版。

11 项目费用明细报价

项目名称内容明细单价数量金额备注

Vmware workstation 15.0软件采购正版虚拟化

软件

160000元1套160000元

150客户端可

扩容

技术工程师现场支持技术服务,外

围环境保障

4000元5天20000元

预估以实际

为准

DBA工程师现场支持迁移数据库,

重构虚拟化,

技术服务

6000元3天18000元

预估以实际

为准

合计金额:198000元

说明:本费用明细报价不作标准合同之用,非含税报价,是对项目及工作量进行的预估算,实际工作量与迁移实施周期及相关流程表均以现场订立为准。

应用及数据迁移方案

1应用及数据迁移方案 1.1应用及数据迁移概述 本次的应用及数据迁移工作,新旧设备的数据迁移也将体现本次实施工作的水准。 原应用及数据迁移具有时间短、系统结构复杂、测试时间长、设备繁多昂贵、人员 多、层次复杂等特点。本项目迁移工作,应用不能中断,迁移准备工作要充 足,迁移时间在尽可能非工作时间完成,并在极短的时间内完成准备工作,并能够有超过时 间的倒退方案,所有新设备的应用系统稳定性也是一个考验。因此,必须协调好各单位人 员的关系,齐心协力才可能在预定时间内完成应用和数据的迁移工作。 本方案是以尽量不影响XXX信用社的日常工作或将影响降低到最低为前提的情况下制 定的,在小型机及存储设备到货后,先完成对小型机及存储的独立系统安装与调试工作, 第二步完成应用系统的安装与调试工作,整个新系统完成可独立运行后,选择在非工作时 间开始开始数据迁移工作,到工作时间以前完成整个服务器、存储设备的数据迁移及测试 工作。并且在正式上线运行以后,继续跟踪系统的运行情况,随时处理系统运行的异常情 况。当然,在XXX信用社各方面人员的充分协调及配合下才能完成本次应用及数据的迁移 任务。 我公司在上游厂商资源方面有较大优势,如在迁移工作中出现设备故障,除在备品备件中提供的备件外,还可协调各方资源以最快速度解决客户设备故障问题。 1.2迁移规划 1、实施流程: 流程主要根据迁移前的需要制定,主要详细了解当前系统设备情况,系统运行情况。针对所了解情况制定详细迁移方案以及应急方案。 2、专业工程师了解用户原有设备的现状以及迁移后的具体要求。充分考虑 在实施过程中可能出现的各种情况,定制详细可行性的迁移实施计划,将应用及数据迁移

数据迁移技术方案

数据迁移方案 N8000到AS13000 广东XX信息技术有限2015年7月

1. 系统拓扑图 成果数据存储系统拓扑图 千兆以太网光纤线路万兆以太网光纤线路 中间服务器 千兆以太网线路 2. 需求分析 新增设备:2台AS13000-NAS 、1台NAS 网关和1套DPS 备份系统通过光纤跳线连接万兆交换机,中间服务器和华赛N8000通过6类网线连接万兆交换机,最低达到千兆交换的物理基础架构。其中1台AS13000-NAS 作为成果数据存储,通过NAS 网关对外提供存储服务,另一台通过DPS 备份软件实现数据备份。 华赛N8000存储数据有40TB ,包括各种大小文件、压缩包,需安全迁移到AS13000,实现数据的备份和共享。数据迁移是敏感性动作,必须保证迁移数据的完整性、可用性,一致性。 华赛N8000已发生硬件故障,须尽快完成数据迁移工作。

3.数据迁移方案 本次数据迁移的目标是在最少存储中断服务时间内完成数据在两个存储设备之间快速有序迁移,并保证数据的完整性、可用性,一致性。 我们在本方案中建议以下2种方式实现存储设备之间的数据迁移: ●文件复制 ?通过全备份、增量备份实现数据迁移 ?实现方式简单,迁移成本较低 ?需要较长的存储中断服务时间 ●备份软件迁移 ?通过建立选择备份的模式运行实现数据自动复制,实现数据迁移 ?支持异构平台 ?需要第三方备份工具支持,成本较高 3.1.文件复制 该方法是通过中间服务器的指令在2个存储设备之间复制数据,数据迁移实现方式简单,不需要对源数据进行设置变更,不影响源数据的正常运行;但该方式迁移数据需要较长的迁移周期,同时需要安排一定的存储中断服务时间,以保证数据的完整迁移。 该方法不适用于增量数据迁移,增量数据需另配存储或在存储中临时划LUN替用,迁移完原数据后再迁移增量数据。 3.2.备份软件迁移 该方法通过安装的备份软件实现2个存储设备之间数据备份,向导指引你进行文件的备份与恢复,支持任务排程,进行备份时可以根据文件类型有选择的进行备份,备份文件可以压缩为ZIP文件进行存放,以节省空间,并且可以通过压缩密码保护您的文件。整个迁移过程都是可控的,原有存储环境保留,避免了迁移过程中的数据损失,保证了系统的平稳过渡。

数据迁移方案

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

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

服务器和应用系统迁移方案

服务器和应用系统迁移方案(此文档为word格式,下载后您可任意修改编辑!)

一、迁移方案总体思路 新旧系统的迁移是一个整体系统工程。迁移必须保证用户系统建设的相关要求,在迁移过程中,我们需要重点考虑几个问题: 1、数据迁移如何保障“业务中断停机时间”。业务中断对于用户无论是运行环境还是测试环境均存在较大的恢复风险,这样的风险特别是对于时间敏感型数据还是对于数据完整性业务都是不可以接受的。我们基于这样的要求,考虑到如何将停机时间最小,能否实现0停机的建设目标? i. 对于服务器操作系统而言,我们可以采用P2V的方式,利用操作系统的Volume Shadow Copy卷影副本复制服务作为基础,来实现在旧系统环境下的系统无修改,无停机的情况下,将数据和应用软件、操作系统环境、系统环境变量等全部以“快照”形式迁移到新服务器中。由此实现服务器环境的整体迁移。 ii. 对于应用IIS和其他应用服务器来说,我们可以基于应用服务器的动态业务扩展集群方式,来实现服务器不停机环境下的增加业务节点操作,这样可以实现应用服务器“热添加”到新环境中的故障转移/负载均衡集群系统中,在部分应用服务中我们可以使用session会话复制来实现旧系统的全局环境变量和会话请求状 态也迁移到新环境中来。考虑到会话复制和状态的快速实时,我们可以采用会话内存复制,考虑到会话复制和状态的安全性,我们可以采用会话数据库复制管理。 iii. 对于数据库而言,我们可以基于数据库本身自带的数据库镜像技术、数据库日志传递技术来实现各自的分库、迁移库的构建,数据库镜像技术可以让我们不但保证数据库迁移的不停机,而且还可以保证万一迁移中出现停机故障也不影响源数据库,而日志传递技术构建的迁移可以保证系统数据库迁移以异步方式进行,这样可以让我们的系统环境在网络出现故障的情况依然可以进行迁移任务窗口的正常工作。

数据库迁移实施方案

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

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

目录 第一章文档介绍 (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目标 针对某电厂实际业务需求,本次建议方案提供数据库的迁移,新采购设备选购、系统配置及业务上线测试到最终的迁移。

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数据库升级项目的顺利实施。

应用系统迁移方案

目录 1.1总述 (2) 1.2系统迁移需求分析 (2) 1.2.1中心系统迁移需求分析总体结论 (2) 1.3迁移方案总体思路 (2) 1.3.1保障业务中断停机时间最小化 (3) 1.3.2业务切割时间节点优化 (3) 1.3.3迁移后完整性测试 (4) 1.4服务器硬件环境迁移方案 (4) 1.4.1迁移评估 (4) 1.4.2迁移计划 (5) 1.4.3测试计划 (5) 1.4.4迁移测试 (6) 1.4.5迁移实施 (6) 1.5运营商接入链路(路由)迁移 (9) 1.6应用系统和数据库迁移方案 (9) 1.6.1应用服务器迁移 (9) 1.6.2数据库迁移实施 (10) 1.7系统迁移的具体组织实施方案 (11) 1.7.1搬迁规划 (11) 1.7.2详细实施方案 (12) 1.7.3应急处理 (13)

1.1总述 按照本期招标采购要求,中心在建成后要实现对迁移应用和新建业务平台的一体化集成。 考虑到需要迁移的指挥中心现有应用包含了分析管理平台、指挥平台,上述平台都是中心的核心、重要应用,因此我公司认为原系统的搬迁将是项目建设的重点和难点。 本方案设计以我公司与用户现系统承建公司的初步技术交流、用户现状分析为基础,给出搬迁方案设计。 1.2系统迁移需求分析 按照用户招标要求,本期系统迁移的具体需求分析如下。 中心原有应用系统将全部迁移至虚拟化服务平台,迁移期间必须保证工作不能中断,历史数据不能损失;迁移后的系统与多媒体融合通信指挥平台融合对接。 系统迁移的难点是系统切割时间节点的合理规划和确保电话接入路由的转换,历史数据的无损迁移也是系统搬迁的难点和重点。 1.2.1中心系统迁移需求分析总体结论 通过对中心现有上述应用迁移的需求分析,鉴于原系统建设单位并非我公司,迁移过程中还存在对原建设厂商协调的工程风险。我公司认为系统迁移的重点内容包括:涉及运营商的接入切割,原有数据的迁移,合理切割时间节点规划。 1.3迁移方案总体思路 中心系统迁移是一个整体系统工程。迁移必须保证用户系统建设的相关要求,在迁移方案设计中,我们重点考虑几个问题。

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

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

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

数据迁移整合方案

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.系统整合的目标: 保证直接关联的系统互动,保证业务的正常办理。例如公众服务系统与基本业务系统之间互动,基本业务与协同业务之间互动等等。

系统历史数据迁移方案

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

需要进行整合的系统 需要与保留系统整合的系统包括: 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数据库中。 上下级国工商局之间的异构数据的集成利用数据交换系统来完成,重点在于数据库存储标准、交换标准的制定和遵守,保证数据的共享,这部分工作由数据中心完成。 系统迁移和整合目标 一、系统切换的主要目标: . .

数据库迁移方案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

数据库软件升级及数据库迁移方案

数据库软件升级及数据库迁移方案 根据本次项目需求,此次项目实施除硬件设备安装调试外,还包括对已有管理系统所用Oracle数据库的升级和管理系统数据的迁移工作,实施方案如下: 一、数据库软件升级 1.1操作系统AIX安装 新购p550小机自带AIX6100操作系统,用启动光盘安装并打好相应补丁; 设置相应环境参数,如:语言环境为简体中文等; 挂载IBM 1814-20A存储,并设成开机自动加载。 1.2 Oracle 10G安装 在存储上安装10g系列中的稳定版本:10.2.0.1并补丁升级至 10.2.0.4; 配置两台小机上所装Oracle,满足数据库的高可用性,保证一台down 机的情况下,另一台能自动接管数据库服务。 二、数据库迁移 2.1迁移前期调研 1、迁移任务的目标 本次项目数据迁移的目的是:将现有ERP系统的二个子系统数据,从低版本到高版本、跨操作系统的方式进行迁移升级,将信息中心现有应用系统数据进行无差异迁移,升级后的目的数据库环境在继承现有数据库所有功能基础上,性能及稳定性需更为完善,从而更好的满足对兴发现有各系统各方面性能的支持。 2、新旧环境分析

2.2迁移各类资源准备 1、人员技术准备 甲方:业务系统管理员; 软件开发商:提供系统维护手册,以搭建模拟应用系统测试数据; 乙方:网络工程师、数据库维护工程师。 2、系统环境准备 正式环境:2台8204-E8A操作系统AIX6100及Oracle10.2.0.4安装 正常; 中转环境:服务器1台、高档PC机2台,数据迁移中转及应用系统 模拟部署及测试用。 3、安装和调测相关软件 操作系统:Windows(临时中转环境) 数据库:Oracle10.2.0.4; 中间件:无; 工具软件:PL/SQL、LoadRun等。 2.3数据迁移方案设计 1、时间安排 模拟环境测试: 模拟结果观察: 正式数据迁移: 2、迁移方案 经过综合分析众多数据迁移相关资料,结合项目经验,本次数据迁移总体方案如下: A、迁移过程直接向10.2.0.4升级 Oracle验证矩阵中无特别强调,可以直接升级为10.2.0.4。 B、采用传统的EXP/IMP方式迁移 本次迁移非本机环境升级,涉及到Windows到AIX操作系统的跨越,另外Oracle版本跨度大,采用Oracle公司提供的EXP/IMP工

新老系统迁移及整合方案

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

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

核心业务数据迁移方案

核心业务数据迁移方案 为了对系统集成核心技术拥有更多的自主控制能力, 为了解决数据库的线性扩展问题,为了尽量减少对软件数据的依赖,针对核心业务数据的迁移做如下方案分析. 一、可选用的数据迁移方式有: 1、数据库方式 1)使用RMAN 将数据全库导出导入。优点是数据不会有逻辑性错误,速度快;缺点是存在数据恢复风险,如果使用带库,必须保障磁带不出问题,如果使用磁盘,必须保障文件系统容量大于数据库 2)使用EXPDP 方式。优点是数据不会有逻辑性错误,导出导入后可提高数据访问性能;缺点是导出导入速度太慢,而且必须保障文件系统容量大于数据库 2、主机方式 1)使用DD。优点是速度快,可在物理上保障数据一致性;缺点是操作复杂,需要对每个要迁移的LV执行DD 操作 2)磁盘MIRROR 技术。优点是操作简单,可在物理上保障数据一致性;缺点是速度慢,一次只能做一个LV,而且稍有疏忽就可能把源数据毁 掉,风险较大 3. 存储方式 1)使用存储磁盘远程复制软件CA。在同一品牌、同一档次的存储器之间 可以使用磁盘远程复制软件,优点是不需要停业就可以进行数据迁移;缺 点是除需要相关软件许可以外,技术条件苛刻,要求源磁盘和目标磁盘的 格式和大小必须一样。 (2)存储内部复制软件BC。优点是不需要停业而且速度快;缺点是需要 对两台存储器进行虚拟化挂接,让一台管理另一台,而且要求源磁盘和目 标磁盘的格式和大小必须一样 二、迁移设计详细实施方案 根据西藏机房环境及数据转移最后选择了DD 方式1),RMAN 方式作为备 用 (1)通过对数据环境(包括主机、磁盘阵列和SAN交换机)的信息收集 分析,确定需要升级的软硬件系统(含微码) (2)确定方案具体细节。新增主机HBA 卡和SAN交换机,构成SAN网络 (3)制定详细操作步骤,确定操作人和复核人。 (4)分析可能出现的风险及采取的应对措施。 (5)由主机、存储、数据库、网络等各方面技术人员对方案进行最终评 审,确定最终方案。 三、迁移组织计划 (1)成立实施小组。由实施小组全面负责项目实施的技术方案、对外沟 通协调、人员组织调配、后勤服务保障等工作。 (2)确定实施日期及停机时间 (3)提前作好停机前的沟通协调工作。

数据迁移方案

数据迁移方案

数据迁移方案 N8000到AS13000 广东XX信息技术有限2015年7月

1. 系统拓扑图 AS13000 成果存储 备 成果数据存储系统拓扑图 NAS 网关 成果存储 主 万兆交换机1 千兆以太网光纤线路万兆以太网光纤线路 AS13000 核心交换机 DPS 万兆交换机2 文件服务 已有存储 华赛 N8000 千兆以太网线路

2.需求分析 新增设备:2台AS13000-NAS、1台NAS网关和1套DPS备份系统通过光纤跳线连接万兆交换机,中间服务器和华赛N8000通过6类网线连接万兆交换机,最低达到千兆交换的物理基础架构。其中1台AS13000-NAS作为成果数据存储,通过NAS网关对外提供存储服务,另一台通过DPS备份软件实现数据备份。 华赛N8000存储数据有40TB,包括各种大小文件、压缩包,需安全迁移到AS13000,实现数据的备份和共享。数据迁移是敏感性动作,必须保证迁移数据的完整性、可用性,一致性。 华赛N8000已发生硬件故障,须尽快完成数据迁移工作。 3.数据迁移方案 本次数据迁移的目标是在最少存储中断服务时间内完成数据在两个存储设备之间快速有序迁移,并保证数据的完整性、可用性,一致性。 我们在本方案中建议以下2种方式实现存储设备之间的数据迁移: ●文件复制 ?通过全备份、增量备份实现数据迁移 ?实现方式简单,迁移成本较低 ?需要较长的存储中断服务时间 ●备份软件迁移 ?通过建立选择备份的模式运行实现数据自动复制,实现数据迁移 ?支持异构平台 ?需要第三方备份工具支持,成本较高 3.1.文件复制 该方法是通过中间服务器的指令在2个存储设备之间复制数据,数据迁移

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,从而使操作过程速度变得极快。此外,数据泵可以提取特定的对象,如特定的存储过程或特定表空

相关文档
最新文档