当前位置:文档之家› 数据库升级迁移项目实施方案

数据库升级迁移项目实施方案

数据库升级迁移项目实施方案
数据库升级迁移项目实施方案

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

文件状态:[√] 草稿[ ] 正式发布[ ] 正在修改文件编号:

当前版本:

作者:XXX 审核人:

单位:

部门:

完成日期:

文档控制

文档修订记录

版本编号变化状态简要说明日期变更人批准日期批准人

V1.0 A 创建文档2010/05 XXX

V1.1 M 修改2010/05/18 XXX

审阅

序号姓名职位

分发

序号.姓名地点

2

目录

第一章文档介绍 (5)

1.1背景 (5)

1.2目标 (6)

第二章系统硬件选型 (7)

2.1存储设备 (7)

2.1.1 设备选型 (7)

2.1.2 设备功能及实现 (7)

2.2服务器设备 (7)

2.1.1 数据库服务器 (7)

第三章系统安装 (10)

3.1主机系统安装 (10)

3.2配臵SAN网络、磁盘阵列 (11)

3.3配臵HACMP (12)

3.4安装数据库软件 (13)

第四章数据移植 (14)

4.1移植准备工作 (14)

4.2移植过程 (15)

4.3系统检查 (16)

数据库检查 (16)

导入后系统需要完成的工作 (16)

应用检查 (17)

4.4系统回退 (17)

第五章应用迁移 (18)

第六章新系统上线后的工作 (18)

第七章工作界面和工作内容 (18)

第八章实施计划 (19)

附件: ............................................................................. 错误!未定义书签。

1.设备、软件验收交付记录.................................................. 错误!未定义书签。

3

2.操作系统安装 ................................................................. 错误!未定义书签。

3.操作系统镜像 ................................................................. 错误!未定义书签。

4.设备配臵清单(需确认) ...................................................... 错误!未定义书签。

4.1 IBM p570服务器..................................................... 错误!未定义书签。

4.2 光纤交换机配臵 ........................................................ 错误!未定义书签。

4

第一章文档介绍

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)应用迁移

5

1.2目标

针对某电厂实际业务需求,本次建议方案提供数据库的迁移,新采购设备选购、系统配臵及业务上线测试到最终的迁移。

6

第二章系统硬件选型

2.1存储设备

2.1.1 设备选型

DS4700

2.1.2 设备功能及实现

按当前要求配臵一台IBM DS4700磁盘存储阵列,阵列本身通过业务需求划分空间,可通过设臵RAID级别提供不同业务的存储要求。如购买了flashcopy及

volumecopy高级功能,可实现存储级别的数据复制,通过备份软件实现生产数据的

备份,并可用于相应的应用前期的开发测试。

当前空间需求可以按照存储预期的存储空间的1.3~1.5倍进行配臵,如涉及到日后的容灾考虑,则需按2.5倍空间进行考虑。空间考虑为_T(为以后的扩容考虑

需要,最大支持在_T)。

2.2服务器设备

2.1.1 数据库服务器

2.1.1.1数据库设备选型 (详见设备清单)

IBM system p6 570

2.1.1.2设备功能

适用于中到大型事务处理应用程序,如中到大型数据库服务,缩短了客户响应时间,减少了服务器数量并降低了软件成本,从而节省基础架构成本,通过将多种工作

7

负载整合到更少的系统上,提高了运行效率。且针对当前的需求可以通过扩展实现快速的升级。

标准配置每个构建模块570(最大)

处理器内核第一个构建模块包含两颗或四颗

3.5、

4.2 或 4.7 GHz 的 POWER6 处

理器内核;其他所有模块均包含四颗

内核,或者第一个构建模块包含四个

或八个 4.2 GHz 的 POWER6 处理器

内核;其他所有模块均包含八个相同

的内核

16 个 3.5、4.2 或 4.7 GHz

POWER6 处理器内核,或者 32

个 4.2 GHz POWER6 处理器内核

缓存每颗内核 4 MB 二级缓存

每两颗内核共享 32 MB 三级缓存

每个系统 64 MB 二级缓存

每个系统 256 MB 三级缓存,或

者每个系统 128 MB 二级缓存

每个系统 512 MB 三级缓存

RAM(内存)2? 4 GB 到 48 GB 的 667 MHz

DDR2 内存;或

?16 GB 到 96 GB 的 533

MHz DDR2 内存;或

?32 GB 到 192 GB 的 400

MHz DDR2 内存

?192 GB 的 667 MHz

DDR2 或

?384 GB 的 533 MHz

DDR2 或

?768 GB 的 400 MHz

DDR2

内部磁盘驱动器

(CEC)

一到六个 SAS24 SAS

介质托架(CEC)一个热插拔 Slimline 4 个热插拔 Slimline

PCI 适配器插槽(CEC)四个 PCI Express 8x 插槽;

两个 266 MHz 的 PCI-X DDR 内存。

16 个 PCI Express 8x 插槽;8 个

266 MHz 的 PCI-X DDR 内存。

标准 I/O 适配器

以太网(CEC,不包括 PCI 插槽)?标配:

o一个双端口千兆

以太网,或

?可选:

o一个四端口千兆

以太网,或

o一个双端口 10

Gb 以太网

?标配:

o四个双端口千兆以太

网,或

?可选:

o四个四端口千兆以太

网,或

o四个双端口 10 Gb 以

太网

集成磁盘

(CEC)

一个 SAS 控制器四个 SAS 控制器

其他端口

(CEC)

2 个 USB;2 个 HMC;2 个 SPCN八个 USB;两个 HMC;八个 SPCN

扩展功能(可选)

I/O 扩展多达 12 个 I/O 抽屉48 个 I/O 抽屉

高性能连接 4 Gb 光纤通道,10 Gb 以太网

GX 插槽(I/O 两个(第二个插槽与八个(四个插槽与四个 PCI Express 8x 插槽共享空间)

8

环路)一个 PCI Express 8x

插槽共享)

PowerVM 虚拟化技术POWER

Hypervisor?

动态 LPAR;虚拟 LAN(内存到内存分区间通讯)1

PowerVM 标准版1(可

选)微分区,每个处理器最多 10 个微分区;多个共享处理器池;虚拟 I/O 服务器;共享专用容量;PowerVM Lx86

PowerVM 企

业版3(可

选)

PowerVM 标准版加上实时分区迁移功能和 Active Memory Sharing

随需扩容功能(可选)处理器和/或内存 CUoD

开启/关闭处理器和/或内存 CoD 试用处理器和/或内存 CoD

实用程序 CoD

操作系统AIX V5.3 或更高版本

IBM i 5.4 或更高版本

SUSE Linux Enterprise Server 10 for POWER (SLES10 SP1)或更高版本Red Hat Enterprise Linux 4.5 for POWER (RHEL4.5)或更高版本

RHEL5.1 或更高版本

高可用性IBM PowerHA? 系列

2.1.1.3设备规划使用

按当前项目规划,采购两台IBM p6 570服务器,每台服务器划分两个LPAR 分区,每台服务器的一个LPAR和对端服务器的LPAR配臵集群。每个LPAR分区按应用所需迁移要求设臵相应系统参数,并按实际情况规划cpu及内存的分配。通过系统级集群(HACMP)配臵,提供Oracle 存储及网络安装配臵环境。

9

第三章系统安装1

3.1主机系统安装

●机房环境(空间、电源)准备就绪,符合设备上架要求。机柜电源满足服务

器及存储设备功率要求,配臵冗余PDU及UPS.检测所有待安装硬件的电源

是否符合要求(包括图形终端、主机、交换机、存储),并连接正确。在做完

安装前必要的准备工作之后,正式开始安装操作系统。

●确保硬件,包括所有的外接设备的安装都已完成,如:kvm设备(图形终

端、键盘、鼠标)、光驱、本地硬盘、光纤交换机、磁盘阵列等硬件设备。联

系网络管理员,获得系统安装所需的网络接口(Ethernet)、IP地址、主

机名、缺省路由。

●安装规划数据库服务器,

包括设备上架加电测试,与电厂和负责应用迁移的人员共同研究设备的硬件

规划要求,包括CPU和内存的具体分配策略.

●确认网络需求

由于IP地址在迁移前配臵为当前应用的实际地址,因此需要先在隔离环境中

配臵 (可采用一台独立的网络交换机提供设备配臵期间的网络配臵操作),待

后期正式切换测试时,断开原有网络,实现迁移,以此避免IP地址后期的更

改造成的系统及应用的大的修改。

两服务器数据库分区各需3个不同网段的IP(oracle专用心跳未算在内)

IP用途IP 子网掩码网关

A机Service IP

A机Boot IP1

A机Boot IP2

B机Service IP

B机Boot IP1

1所有的系统安装的工作应在数据库正式移植前完成,以减少系统的停机时间。

10

B机Boot IP2

●服务器系统安装

见附件操作系统安装

●补丁安装

按应用及数据库规划要求在两个分区上安装相应的操作系统补丁,并完成扩

展软件包和HACMP软件的安装。

●本地存储空间镜像,提供主机级别的操作系统保护

见附件镜像安装

●本地文件系统划分

扩展相应系统空间(按安装规划要求,包括page space等要求)。除系统特定

的文件系统外,安装oracle的文件系统每机预留15G,剩余空间划分为归档

日志文件系统供存贮归档日志及备份使用。

●操作系统参数调整

包括主机名,系统时区,系统时间的修改(如当前环境中有NTP服务器,可以

配臵使用),添加用户的环境变量,打开异步IO,设臵最大进程数,调整系统

使用的I/O步调及增大syncd的运行频率。

3.2配置SAN网络、磁盘阵列

●存储设备安装:使用磁盘阵列管理软件(storage manager),按RAID级别,

划分至少4个LUN,影射到对应服务器WWN。

●两台服务器上连接共享存储的分区首先识别新存储,为下面创建共享逻辑组

做准备。

Vg名称用途大小

Vgdata Rac数据库(并发)EAM数据库大小40G,预留

30%

●光纤交换机划分zone

考虑到存储以后可能的扩容及提供部分存储给其他业务需求的可能,避免非

相关的服务器上识别到当前设备的存储空间,加快系统启动速度,对光纤交

换机按端口或按照终端设备的pwwn号划分zone。

11

12

3.3 配置HACMP

● 设臵ip 地址(按原有系统) ● 确认网卡设备

每分区上有3个IP ,其中两个boot IP ,一个服务地址。其中,服务地址绑定在第一块网卡上,oracle 心跳网卡在ent3上。

注意:这里使用的boot 网卡是系统的两块集成网卡,oracle 心跳网卡是一个独立的光纤网卡。使用#lscfg -vp|grep ent 命令可以查看网卡的位臵信息。

● 修改hosts 文件 ● 检查网络的通信状态

网络配臵完成后,使用ping 命令ping 网关和另外一台服务器,确认网络的通信正常。如果网络不通,检查网络配臵是否正确,检查网口是否插错,检查网线是否是好的,检查交换机端口是否正常,使用排除法等方法排除错误。 ● HACMP 配臵

两台数据库服务器通过光纤交换机与存储设备相连接。连接时应考虑设备的

容错能力,即一块光纤卡或者一块光纤交换机坏了,应用仍可正常工作。具

体连接方式如下:

(1)数据库服务器,由两台IBM p6 570的lpar构成。一台作为数据服务器A,一台作为数据库服务器B,两台机器组成ORACLE RAC高可用

性系统。

(2)接入IBM DS4700存储设备,2005B32光纤交换机。

(3)数据库服务器A和B各通过两个千兆网卡,接入系统局域网络。

(4)由于Oracle9i服务器地址不参与漂移,可配臵三个资源组,其中两个资源组服务维护两个分区上的IP,参与节点为两个分别得节点,第三个资

源组管理共享存储,以此提供给Oracle应用。

HACMP验证

现阶段可验证系统集群是否符合Oracle安装要求,提供共享存储及网络服

务。

3.4安装数据库软件

安装Oracle rac for aix,安装数据库软件。因为本数据库需要配合成熟的应用程序,因此数据库版本需要应用厂商确认数据库具体的版本号。初步计划将安装oracle XXXX。

根据原有的数据库配臵,创建新的数据库。根据原有的表空间设臵新数据库的表空间。如果原有系统的表空间以及数据文件配臵不规范,可以在此步骤加以修改规范。

配臵数据库初始化参数以适应数据库导入的要求。

13

第四章数据移植

4.1移植准备工作

在数据移植前,我们应该记录、统计原有数据库的完整信息,方便在移植完成后做对应的检查工作。记录的信息主要有:

需要移植的数据范围:全库或按照用户(记录具体的用户名称)

●记录数据文件、表空间状态

如果系统中部分表空间或数据文件存在OFFLINE的状态,应确认该部分表空间以及数据文件中的数据是否需要移植。

目前系统的运行情况,按照用户纪录:

●纪录目前系统中的对象数量以及状态

如果该查询结果中存在INVALID状态的对象,必须纪录对象的名称、类型并在移植工作正式开始前确认这部分对象应该的实际状态。

●纪录目前系统中的索引数量以及状态

如果该查询结果中存在INVALID状态的索引,必须纪录索引的名称、类型并在移植工作正式开始前确认这部分索引应该的实际状态。

●纪录目前系统使用的优化方式

如果系统使用基于代价的优化算法,则在数据移植后,执行分析程序收集数据库信息。如果系统使用的是choose方式,则需要检查目前系统中的数据是否是否进行了分

析,以确定在数据移植完成后是否需要收集数据库运行信息。

●纪录系统中的用户、角色权限。

●纪录系统中所有的public对象,如public同义词,public dblink。

检查项目原系统内容新系统内容

数据文件、表空间状态

对象数量以及状态

索引数量以及状态

14

优化方式

用户、角色权限

dblink

4.2移植过程

因为本次数据移植跨平台。因此采用oracle的exp和imp工具来完成数据移植工作。

从本步骤开始直到系统正式移植完成期间,必须停止数据库运行,移植工作一次性完成。如果因为某种原因导致移植无法一次完成,无论本次工作进行到了哪一步,下一次移植必须从本步骤重新开始。

移植步骤如下:

1、停止所有的应用,停止所有对数据库服务器的连接。

为了确保在移植过程中,没有任何新的数据库修改,在开始导出数据前,我们建议停止所有的应用程序。关闭数据库,关闭监听。然后重新打开数据库,以确保所有应用无法连接到本数据库。

2、使用exp用户导出数据

在使用该工具时,因注意以下参数:

●字符集:应确认数据库字符集与服务器配臵的字符集完全一致,以确保汉字

没有任何乱码。

●CONSISTENT:该参数应该设臵为Y,以确保交叉表的一致性。

●Log: exp过程应该记录在日志文件中以方便检查导出过程。

将导出的数据拷贝到新的数据库服务器上。

3、在新的数据库服务器上导入数据

导入使用oracle提供的imp工具。在使用该工具时,因特别注意以下参数:

●字符集:应确认数据库字符集与服务器配臵的字符集完全一致,以确保汉字

15

没有任何乱码。

●Log: imp过程应该记录在日志文件中以方便检查导入过程。

4.3系统检查

在数据移植完成后,因进行全方位的检查工作,以确保数据移植的完整准确。

数据库检查

●检查导入日志,确保导入过程准确。

●检查导入字符集与原系统一致。

●检查导入数据完整。

●检查表空间、数据文件状态正确。

●检查导入对象数量、状态正确。

●检查导入对象所在的用户、表空间正确

●检查导入索引数量、状态正确。

●检查dblink正常,可访问

●检查修改用户角色权限,保持与原有系统一致。

导入后系统需要完成的工作

在数据检查确认正确后,我们需要完成以下工作:

1、如果原系统是基于代价的优化算法,执行分析程序,分析移植后的数据。

2、修改内容包括:操作系统IP地址、主机映射、hacmp软件配臵、数据库监听等

配臵。

3、修改所有的中间件、客户端程序需要重新配臵与数据库服务器的连接(使用到

oracle rac的特性)。在修改中间件、客户端配臵之前,相关厂商、人员应做好相应的备份工作,以确保系统可以回退。

4、调整数据库参数,适应应用运行以及新的主机环境。

16

应用检查

在数据库检查完成后,将通过程序连接来检查数据移植的完整性。最终用户通过试运行程序来检查数据移植工作。

4.4系统回退

本次数据库移植,使用了全新的硬件系统。全新的数据库服务器、磁盘阵列。因此,不需要在原有数据库平台上执行任何需要修改的操作。这大大降低了我们在移植过程中的备份工作以及时间。如果在移植过程中,因为种种原因导致无法成功,仅需要启动原有系统,继续提供服务即可。

1、关闭或断开新服务器

2、启动旧系统

3、重新启动应用程序

在系统移植完成,新系统正式上线投入使用后,因为新的数据已经进入到了新的系统。如果此时发现重大问题导致系统无法使用,我们需要将新数据重新导出再导入旧系统。

1、导出新系统数据并通过中间机器

2、关闭或断开新服务器

3、启动或连接上旧服务器并重中间机器获取新的dmp文件

4、利用备份系统备份旧数据库。

5、删除旧系统的用户和数据

6、重新导入新数据

7、重新启动应用程序

17

第五章应用迁移

第六章新系统上线后的工作

在最终用户检查确认无误后,本次移植工作基本完成。系统可以上线,为用户提供服务。为了尽量减少系统的停机时间,部分工作可以在系统运行后再执行。

1、原有的备份系统需要指向新的数据库备份。安装配臵相应的agent,调整备份的脚本等。

2、在新系统上线后为确保系统安全,建议将原有系统保留至少1月以上。

第七章工作界面和工作内容

系统迁移是一个复杂的工程,牵涉的面较多,因此良好的分工协作是项目成功的关键。本项目的核心工作是数据库系统迁移和外围环境的集成。为了更好地完成项目任务,我们这里把项目相关的工作进行分类,同时明确各自的工作范围和界面,进而保证项目有序、高效和高质。

本项目涉及的机构包括:某发电公司、项目实施公司和其他系统建设方。某发电公司主要提供场地环境,对系统实施方案进行审核,对重要项目问题给予指导和决策,协调相关厂家,监督项目实施和项目验收;项目实施公司主要完成本次采购设备的安装、数据库迁移、外围系统集成、项目验收和技术服务,并协助和配合其他建设厂家调整系统;其他厂商完成相关本项目的其他厂家实施的项目或系统的调整、优化和重新部署,项目实施公司给予协助。

项目实施公司负责本项目的总集成。

●项目实施公司负责

?负责SAN网络以及磁盘阵列的划分。

?IBM小型机安装调试

?数据库服务器安装调试

?数据移植

18

?检查确认数据移植的正确性、完整性。

●应用厂商需要配合的内容有:

?提出数据库安装的具体版本

?提出基于应用特有的数据库参数要求

?应用启动停止

?如果数据库服务器修改了IP地址,相关应用的修改。以及修改前应用的备份等工

作。

?协助检查数据库移植工作的完整性。

●网络工程师负责

?新增加的服务器加入现有系统的网络配臵工作

●数据备份工程师负责

?修改备份软件脚本,备份新上线的数据库

第八章实施计划

时间硬件工作软件工作

1 按实施阶段时间安排到货验收,机器上架到货验收

19

2按实施阶段时间安排系统安装原系统情况记录,存储要求整

3按实施阶段时间安排HACMP安装,存储安装新库运行脚本整理

4按实施阶段时间安排数据库安装

系统测试系统测试、导入导出迁移

5 (测试晚后,备份实施)

按实施阶段时间安排

6按实施阶段时间安排应用试运行

7按实施阶段时间安排

8按实施阶段时间安排保障,验收

9按实施阶段时间安排

20

应用及数据迁移方案

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

应用及数据迁移方案精品范本

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

行情况。针对所了解情况制定详细迁移方案以及应急方案。 2、专业工程师了解用户原有设备的现状以及迁移后的具体要求。充分考虑在实施过程中可能出现的各种情况,定制详细可行性的迁移实施计划,将应用及数据迁移工作对用户的影响降至最小。 3、编制迁移前及迁移后的服务器及存储布置表、连接表、线缆号表,设备实施计划表。可根据用户情况分为多个系统进行分类。 4、在迁移过程中需要XXX信用社技术人员密切配合。 5、为保证迁移工作顺利、有序、安全的进行将制定详细的迁移流程,进行细致的分工,具体工作安排到人,责任到人。 6、迁移工作中的工作原则最少安排3人以上,以保证工作的准确性。 1.3 详细实施方案 本次设备安装实施时间为20天。我们将尽量细化任务安排保证工作顺利进行。 为了迁移能按时顺利进行,并且在迁移后能够保证设备及应用正常运行,我们制定了一系列简单明了的工作表,帮助工程实施人员确定各种迁移工作中要执行的工作是否完成。避免工作失误,避免造成迁移工作的延误。 实施流程: 环境的要求: 需要在迁移前检查环境及设备设施是否符合要求,本工作表是保证迁移后设备能否稳定正常运行的先决条件,在迁移前由迁移负责人同相关人员填写确认。 目的环境检查表

数据库迁移实施方案

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

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

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

数据迁移方案

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

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

视频会议系统升级改造项目

视频会议系统升级改造项目(浙江省防指办) 本次项目中的设备采购数量为计划数量,最终实际采购数量以合同签订数为准,但浮动比率不超过合同总价的10%。 如有远程视频会议系统项目建设经验,请提供合同及验收报告复印件,原件开标现场备查。 一、防汛远程会商系统概况及现状 防汛远程会商系统是省委、省政府实施防汛防台抗旱工作的重要决策指挥平台。该平台初建于2002年,经多年运行,由于早期视频会议技术相对落后,随着系统规模扩大、设备老化等原因,逐渐暴露出图像质量不高、稳定性下降以及会议调度管理困难等情况,为改善会商系统性能,决定对系统进行升级改造。主要内容包括:升级改造省、市视频会议MCU和终端设备;将原系统改造成为应急备份系统,增强应急保障水平;完善后台调度管理系统等。 1、网络结构 目前省、市、县、乡四级视频会议系统为树状网络结构,在各层的网络会议结点各放置一台MCU,各区域的终端就近连接到各地的MCU,然后通过MCU级联,构成全省防汛远程视频会议系统。逻辑结构图如下:

全省视频会议系统以一级MCU为汇接中心,以辐射方式与二级MCU、三级MCU相连接,每一级的MCU同时与本区内的分会场相连接。各级MCU对本区各分会场的图像、语音、数据进行选择切换,将图像、语音数据送至上一级的MCU,切换后的图像、语音、数据经各级的分配设备传送到全网各个分会场。 目前,省~市网络采用电信公司的6M MSTP线路;市~县网络线路各地分别采用2M SDH、MSTP等。 2、系统组成 依托省~市~县三级计算机通讯网络,以MCU和视频终端为核心设备,构建成省、市、县三级防汛远程视频视频会议系统,系统拓朴图如下:

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 项目背景及现状 (3) 1.1 系统设备现状和利用率 (3) 1.2 系统数据交互 (3) 1.3 数据库现状 (4) 1.4 存储现状 (4) 1.5 迁移后的设备利旧 (4) 1.6 网站升级必要性 (4) 2 建设目标和实施内容 (6) 3 总体技术架构 (7) 3.1 总体架构 (7) 3.2 云服务架构 (9) 4 业务应用系统功能要求及云服务需求测算 (10) 4.1 内容管理系统新增功能要求 (10) 4.1.1 站群管理 (10) 4.1.2 信息采编功能优化 (10) 4.1.3 资源库 (11) 4.1.4 组件式的扩展接口 (11) 4.1.5 统计分析 (11) 4.1.6 系统日志 (12) 4.1.7 信息共享方式修改 (12) 4.2 政民互动系统新增功能要求 (13) 4.2.1 主要功能要求 (13) 4.3 全文检索系统功能完善要求 (14) 4.3.1 增加智能搜索技术 (14) 4.3.2 多格式支持 (15) 4.3.3 海量检索支持 (15) 4.4 网站系统同政务微博、微信绑定发布功能 (16) 4.4.1 终端页面 (16) 4.4.2 微信微博 (17) 4.4.3 全文检索 (19) 4.4.4 场景式服务 (19) 4.4.5 统一标准接口 (20) 4.5 网站无障碍浏览系统功能要求 (20) 4.5.1 系统架构 (20) 4.5.2 功能结构 (22) 4.5.3 部署方案 (22) 4.5.4 系统要求 (24)

4.6 数据迁移 (25) 4.6.1 数据库迁移步骤 (26) 4.6.2 数据备份 (27) 4.6.3 数据校验 (27) 4.6.4 系统切换 (27) 4.7 云服务需求测算 (28) 4.7.1 网站数据库服务器估算 (28) 4.7.2 应用服务器估算 (28) 4.7.3 网站服务器估算 (29) 4.7.4 网站无障碍浏览服务器估算 (29) 4.7.5 互联网网络资源需求 (30) 4.7.6 互联网存储资源需求 (30) 4.7.7 支撑软件 (31) 4.7.8 网站系统需求资源汇总 (31) 4.8 系统拓扑图 (32) 5 标准规范 (33) 6 项目实施管理 (34) 6.1 项目实施组织 (34) 6.1.1 管理机构 (34) 6.1.2 实施机构 (35) 6.2 项目进度安排 (35) 6.3 安全管理制度 (36) 6.3.1 网络安全 (36) 6.3.2 数据安全 (37) 6.3.3 应用安全 (37) 6.4 人员培训 (38) 6.4.1 培训目标 (38) 6.4.2 培训方式 (38) 6.4.3 培训内容 (38) 6.5 系统风险评估 (39) 7 系统保障及应急预案 (41) 7.1 保障措施 (41) 7.2 故障处理 (42) 8 项目投资 (43) 8.1 项目资金预算 (43) 8.1.1 云服务及其他需说明的资金支出 (43) 8.1.2 信息系统开发费用 (43) 8.2 项目资金筹措方式和进度计划 (43) 8.2.1 项目资金筹措方式 (43) 8.2.2 项目进度计划 (43) 附件1:云服务清单 (45) 附件2:信息系统开发费用 (47)

数据迁移技术方案

数据迁移方案 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文件进行存放,以节省空间,并且可以通过压缩密码保护您的文件。整个迁移过程都是可控的,原有存储环境保留,避免了迁移过程中的数据损失,保证了系统的平稳过渡。

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

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 系统迁移和整合目标 一、系统切换的主要目标: ●保证系统正常运行 在数据转换过程中,由于原有的系统数据的复杂性,给数据转换工作带来了很大的难度,为了在新系统启动后不影响原系统正常的业务,因此数据转换完成后,必须保证新系统的正常运行。 ●保证原有系统在新系统中的独立性 原有系统是独立运行的系统,数据在新系统中虽然是集中存放的,但是各个

整村提升改造实施方案

整村提升改造项目实施方案 村容整洁是建设社会主义新农村的重要任务之一,良好的村容村貌不仅体现着一个村庄及其村民的精神风貌,而且有利于提升农民群众的居住环境和生活质量,是统筹城乡发展,构建 社会主义和谐社会的具体体现。近期,新农办通过实地调查和发放调查问卷等形式,对全县 村容村貌现状进行了专题调研。 一、基本情况 目前,我县共有335个行政村,其中超过2000人的村48个、超过3000人的村14个、超过 5000人的村2个。通过整理汇总调查问卷,得出下列数据: 从村庄建设规划方面看,有246个村完成了村庄建设规划,占全县村庄总数的73.4%;已建 或在建农民公寓楼的村50个,占总数的14.9%。 从村庄基础设施方面看,村内主干道实现硬化的村325个,占总数的97%;主干道两侧安 装路灯并定时照明的村192个,占总数的53.4%;建有排污排水管道的村100个,占总数的 29.9%。

从村民卫生习惯方面看,村民自觉并习惯将垃圾定点投放的村192个,占总数的57.3%,其 中建有固定垃圾投放点的村148个,占总数的44.2%;建立保洁队伍及配备清运车辆的村106 个,占总数的31.6%;垃圾实现集中处理的村79个,占总数的23.6%;制定环境卫生考核 办法的村138个,占总数的41.2%。 从村庄绿化美化方面看,建有公共休闲绿地的村59个,占总数的17.6%;干道两侧实现统 一绿化的村121个,占总数的36.1%;干道两侧墙面统一粉刷的村100个,占总数的29.9%; 干道两侧无“三堆”现象的村163个,占总数的48.7%。 二、基本经验 在改善村容村貌方面,一些有条件的村进行了积极探索和实践,取得了一些好的经验: (一)结合旧村改造,建设村民公寓。随着经济的快速发展,农民群众对居住环境提出了新 的要求。近年来,不少镇村结合改善村容村貌,科学合理地编制建设规划,实施旧村改造工 程。马桥镇从2002年开始停止农村宅基地审批,启动“合村并点”工程,规划农民生活区, 建设农民公寓楼,逐步实现人口向镇驻地集中,居住向

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

服务器和应用系统迁移 方案 TYYGROUP system office room 【TYYUA16H-TYY-TYYYUA8Q8-

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

关于数据迁移的各种方法

关于数据迁移的各种方法 在项目中经常会遇到系统完全更换后的历史数据迁移问题,以示对客户历史工作的尊重,何况很多数据仍有保留的必要。 那怎么做历史数据迁移呢? 系统分析: 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 集群,如下图:

线路改造项目实施方案00

线路改造项目实施方案 一、调研情况概述 1.初中教学楼始建于1993年左右,属于砖混建筑结构,地上三层(每层19间),现共有教学班18个(54间),办公室2间,近几年在国家对农村学校的大力投资下,学校的教学设施及办学条件在不断的改变。大功率用电器越来越多(主要是空调、多媒体设备等),原来改造的线路已不堪重负,再加上电线使用多年,线路凌乱、老化现象严重,插座和照明灯具也是故障频发,给教学楼及师生人身安全带来不安全因素,为保障空调及多媒体设备用电安全,需要对该楼进行电器线路改造升级。 2.教工宿办楼和学生宿舍楼建成后由于原来的线路在外墙上拉起室外线,近两年风刮日晒线皮老化。为了师生人身安全现需要将原线路进行改造更换。 3.电教楼始建于70年代,属于砖混建筑结构,地上二层(每层12间),原来改造的线路已不堪重负,再加上电线使用多年,线路凌乱、老化现象严重,插座和照明灯具也是故障频发,给电教楼及师生人身安全带来不安全因素,为保障用电安全,需要对该楼进行电器线路改造升级。 4.2015年春季开学,我校启用了新食堂。新建的食堂要将原进户线改成地埋线加大线号,及室内电路设计不能供应食堂电器设备的使用。为了不影响食堂正常使用,需要重新设计安装线路。

5.新建学生厕所即将交工使用,无外接线路,现需要架接照明线路。原厕所线路老化,现需要改造。 6.原校园内路灯较少,现需要重新布点安装路灯。 经过我校询价小组市场调研、电话查询,由于该项目技术难度不大,特确定线材、开关和插座等要求施工方提供符合国家标准规范的合格产品就可以。 二、采购方式 在正规的经营商铺采购符合国家标准规范的合格产品,拟采用招标或议标确定具有相关资质的施工单位进行实施本项目。 三、资质条件 1.具有年审合格法人营业执照(副本)、税务登记证;组织机构代码证、银行开户许可证; 2.具有房屋建筑工程施工总承包资质,具有有效的安全生产许可证; 3.项目经理具有项目经理资质证书,电器技术人员和电工作业人员的资质证书。 四、改造实施方案 1.教学楼 (1)将该楼原有线路(从一层配电柜下方)、照明灯具、开关、插座等全部拆除; (2)每层安装一个楼层配电箱(三相100A空气开关、分相分路开关),每个教室安装一个配电盒(20A自动开关、漏电保护器);

数据迁移整合方案

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

数据库迁移方案

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

深圳高新区北区产业升级改造实施方案

深圳高新区北区产业升级改造实施方案 (修订征求意见稿) 为加快推进深圳高新区北区产业优化升级,拓展高新技术产业发展空间,建设产业更高端、资源更集聚、空间更广阔、交通更便利、环境更优美的世界一流高科技园区,根据《深圳经济特区国家自主创新示范区条例》、《深圳经济特区高新技术产业园区条例》、《深圳市城市更新办法》及市政府关于深圳高新区优化升级工作要求,制定如下实施方案: 一、实施背景 (一)高新区北区是指北环大道以北、南海大道以东、广深高速以南、沙河西路以西围合的区域,总面积2.58平方公里。20多年来,高新区北区为推动我市高新区和高新技术产业发展作出了重要贡献,但也面临以下发展瓶颈和突出矛盾: 1、产业结构层次不高。农副产品、食品加工,玻璃、塑胶制造,化工生产等低端传统产业用地占高新区北区产业用地的四分之一,且半数以上企业处于停产、半停产状态。 2、产业空间布局不优。产业用地平均容积率仅为 1.98,大部分早期建设的工业厂房低矮陈旧,无法满足新型总部企业办公、研发需要,也不能适应创新创业活动需求。 3、公共技术支撑不强。实验室、工程中心、技术中心、检测机构等公共技术服务平台数量少,使用效率低。 4、公共配套设施不全。教育、文化、医疗卫生、公园、员工宿舍等公共服务设施亟待完善,餐饮、购物、休闲等商业服务设施严重不足。 5、交通承载能力不足。北向道路阻断,内部循环不畅,拥堵节点较多,公共交通运力严重不足,目前尚无建成地铁站点,难以满足片区工作、居住人员出行需求。

(二)为给产业战略升级提供空间支撑,南山区政府提出加快推进高新北整体更新,助力南山区成为国际科技、产业创新中心核心区、世界级创新型滨海中心城区。在市政府的指导下,2016年8月31日,南山区政府与深投控公司签订了《高新区北区升级改造战略合作框架协议》,确定深投控公司为统筹主体,同时提出“政府主导、统一规划、产业升级、投控统筹”的整体思路。南山区政府负责对高新区北区进行统一规划、制定园区产业升级政策,深投控公司作为高新区北区的整体运营商,代表南山区政府统筹实施具体工作。 二、总体目标 高新区北区产业升级改造按照统一规划、分步实施、立体布局、复合更新的原则,通过片区统筹来实现产业升级、空间倍增和产城融合的总体目标,将深圳高新区打造成为世界一流高科技园区,为全国高新区“二次创业”探索集约型发展道路并发挥示范作用。 (一)产业升级。引入战略性新兴产业和未来产业,培育产业集群。到2020年,高新区北区每平方公里产业用地创造工业总产值力争超过2000亿元,高新技术产品产值、工业增加值、利税总额比2014年翻一番。 (二)空间倍增。通过拆除重建和综合整治等多种模式,高新区北区建筑面积由310万平方米增加到660万平方米。产业用地平均容积率由1.98提高到5,产业用房和产业配套用房建筑面积倍增。 (三)产城融合。建立多层次、全方位、立体化的公共服务体系,公园、休闲绿地面积由8万平方米增加到16.5万平方米,商业服务面积由3万平方米增加到不低于36万平方米,员工宿舍、保障性住房、公寓面积由43.2万平方米增加到148万平方米,住户由9千户增加到2.8万户。 三、政策要点 在高新区北区产业升级改造中,根据产业布局、更新规划和企业需求,

相关主题
文本预览
相关文档 最新文档