1.1补丁安装（可选）
若DB2安装介质文件中已包含fix pack5版本的补丁，通常不用进行补丁安装。但若是在原有版本之上打补丁，可以参考本节的内容。
DPF或者HADR或者PureScale环境中，需要在每台物理机器或者VM上安装DB2补丁包。
注意：对于DPF或者PureScale这边，没有什么特别注意的地方，也是按照同样的步骤安装、更新实例、启动、重新绑定程序包就可以了。（PureScale是多个实例，一个DB，DPF是1个实例多个partition），就需要在每一台物理机器或者VM上执行相同的步骤安装补丁。在启动实例之前需要确保所有机器上的补丁都在同一个补丁层次上。
1.1.1准备工作
1.1.1.1解压缩补丁包
将下载后的补丁包压缩文件上传到DB2数据库服务器的/tmp/db2v105目录下。
通过root用户登录DB2数据库服务器，具体步骤如下：
1.1.1.2停止DB2实例进程
1.作为 root 用户登录DB2数据库服务器。
2.确定与 DB2 副本相关联的所有实例。
发出以下命令：
本节后续步骤不需要执行）。
注：/opt/ibm/db2/V10.5/bin/db2greg -dump也可查看各种版本下的所有实例。
3.对 DB2 副本中的每个实例运行下列命令：
的停止步骤，停止每个存在的实例进程。
如果是 PowerHASystemMirror用户，那么必须使用 ha_db2stop 命令而不是 db2stop命令来停止 DB2。如果使用 db2stop 命令而不是 ha_db2stop 命令，将触发故障事件。
1.1.1.3停止DB2管理服务器
如果 DB2 管理服务器 (DAS) 属于要更新的 DB2 副本(如果服务器上没有安装
DAS管理服务器，则跳过此步），请停止 DAS：
首先确认是否安装了DAS：
如果没有安装，将不会有输出结果显示
停止DAS：
注：由于系统上只能有一个 DAS，因此，这个步骤将影响系统上的所有其他 DB2 副本。
1.1.1.4卸载内存共享库
在 AIX上，请在安装前运行 slibclean 以从内存中卸装未使用的共享库：
1.1.1.5禁用故障监视器
1.如果启动了故障监视器守护程序, 请停止故障监视器守护程序：
第一步：要确定是否启动了FM，请发出以下命令（用root用户运行）：
is A V AILABLE，
如果禁用了FM，那么输出内容将是：Gcf module 'fault monitor' is NOT operable
禁用故障监视器命令如下：
2.如果启动了故障监视器协调程序 (FMC)，请阻止实例自动启动（用root用户运行）：
第一步：要确定是否启动了 FMC，请发出以下命令：
禁用了 FMC，那么 db2fmcu 命令的输出将是：FMC: down。
禁用FMC命令如下：
自动启动。发出以下命令：
容，那么这表示该实例已配置为自动启动：DB2AUTOSTART=YES 第三步：阻止这些实例自动启动。发出以下命令：
3.
区中运行以下命令：
resources for db2inst1.则执行成功。
1.1.2安装补丁包
要安装补丁包：
DPF或者HADR或者PureScale环境中，需要在每台物理机器或者VM上安装DB2补丁包：
1.对于 root 用户安装，请作为 root 用户登录。
2.切换至包含补丁包映像的目录。
3.通过发出 installFixPack 命令来启动安装。例如：
注：缺省情况下，installFixPak 命令将落实 AIX 上所有已更新的文件集。在 AIX 上，如果不希望落实更新，则应按如下所示发出带 -a 选项（用于“应用”而不是“落实”）的installFixPak 命令, 一般情况下不用。
注意：如果是刚安装的DB2，还没有创建实例，则不需要进行下面的步骤。如果是在现有DB2系统上进行更新，有实例存在，installFixPak之后，必须更新所有实例。
1.1.3更新实例和DAS级别
更新该DB2副本（版本）下的所有实例和DAS以使用新的 DB2 级别：
步骤：
1.备份db2profile or db2cshrc 文件。由于 db2iupdt 命令覆盖 db2profile 和 db2cshrc 脚本，因此此操作是必需的。它不覆盖 userprofile 和 usercshrc 脚本。
2.
2.以 root 用户登录更新实例，对于每个实例，发出下列命令：
其中iname 表示实例名，install_home 表示适用于DB2软件的安装目录。
3.如果数据库管理服务器（DAS）实例存在并且是DB2 版本10.5 DAS 实例，要更新
DAS 实例，发出以下命令：
（好像install_home/instance/dasupdt 也可以）
其中dasname 表示 DAS 所有者名(dasusr1)，install_home 表示DB2软件的安装目录。
1.1.4更新数据库级别
升级数据库到最新FixPack Level：
以实例用户执行：
1.1.5重启DB2实例和DAS
以实例用户执行：
1.启动许可证服务器
2.启动实例（把该DB2副本下所有的实例都启动起来）
3.
1.1.6绑定程序
所有实例的下的所有数据库都需要做这个操作。
1.实例用户连接数据库：
2.绑定db2schema.bnd，db2ubind.lst 和 db2cli.lst文件
注意：db2ubind.lst 和 db2cli.lst 包含 DB2 UDB 使用所必需的绑定文件的列表，@符号不能少，因为bind只能操作.bnd文件，如果是.lst文件，必须带@符号。
执行：
其中path表示绑定文件所在的目录的全路径名，例如 $HOME/sqllib/bnd（如：
/db2home/db2inst1/sqllib/bnd）。
如：
或：
其中$DB2DIR表示DB2副本（版本）的安装目录。
或：
其中 $HOME 表示数据库服务器实例的主目录。
3.如果有嵌入式C/C++程序，也需要绑定：
不管有没有都最好进行rbind一次，因为存储过程也需要rbind
4.退出：
1.1.7验证版本以及状态
到这里补丁安装以及完成，需要进行DB2版本、数据库状态、完整性和有效性验证。
1.执行db2版本检查命令（root用户运行）
2.数据库状态、完整性和有效性验证（实例用户运行）：
1.1.8可能出现的问题
1.db2start出错
解决办法：
1.kill所有跟这个instance相关的进程、
2.IPClean
3.Run db2iupdt
如果kill之后还有db2fmxx这样京城，可以用：
fmcu -d 关掉db2fmcd进程，fm -i inst_name -D 关掉db2fmp进程，
再用ipclean命令清空进程间通信。
详细命令请参考1.1.1.5节
再用ipcs检查一下操作系统下有没有共享内存没被释放，用ipcrm -m/s来释放。
2.db2admin start 出错
解决办法：
1.kill所有跟这个admin server相关的进程、
2.IPClean
3.Run dasupdt
3.在1.1.1.2节中停止实例后，使用ipcs检查一下有多少共享内存还没被释放
手动释放：
自动释放的脚本（将如下代码写入.sh中，再用sh xx.sh执行）：
1.1.9回退保障
本例是摘自DB2V9的补丁升级。
不可回退到DB2 9.1版本，只能回退到一个比FP5更低的Fix Pack，比如FP4、FP3、FP1等。
在安装FP4、FP3、FP1等时，用以下命令：
./installFixPack -f -b DB2DIR
例如，要卸载 DB2 V9.1 FP2，请在 DB2 V9.1 FP1 安装映像中运行 installFixPack 命令，如下所示：
./installFixPack -f -b DB2DIR
其中 DB2DIR 是要强制为较低级别的修订包映像的 DB2 数据库产品的位置。例如：
./installFixPack -f -b /opt/ibm/db2/V9.1
1.1.10其他参考(以root用户执行)
无法停止实例强制杀进程：
Db2_ps
Db2_kill
ps -ef|grep db2inst1 |awk '{print $2}'|xargs kill -9
1)安装前应运行 slibclean 来从内存中卸装未使用的共享库：
/usr/sbin/slibclean
如果ipcs | grep db2的输出结果仍然有未卸装的共享内存，那么执行以下命令
ipcs -m| grep db2 | awk '{print $2}'|xargs -i ipcrm -m {}
ipcs -s| grep db2| awk '{print $2}'|xargs -i ipcrm -s {}
2)禁用故障监视器进程。要停止故障监视器守护程序，请发出以下命令：
/opt/ibm/db2/V9.5/bin/db2fm -i db2inst1 -D
return non-zero rc, please see log file '/home/db2inst1/sqllib/db2dump/db2diag.log'
3)如果启用了故障监视器协调程序（FMC），那么请阻止您的实例自动启动：
a. 要确定是否启用了 FMC，请发出以下命令：
/opt/ibm/db2/V9.5/bin/db2fmcu
FMC: down
如果启用了 FMC，那么您将看到类似于以下内容的输出：FMC: up: PID = 3415。使用/opt/IBM/db2/V9.5/bin/db2fmcu –d 停止FMC
如果禁用了 FMC，那么 db2fmcu 命令的输出将是：FMC: down。
b. 如果启用了 FMC，请确定是否有实例配置为在每次系统重新启动之后自动启动。发出以下命令：
/opt/ibm/db2/V9.5/instance/db2iset -i db2inst1 -all 每个实例执行一次(用
/opt/ibm/db2/V9.5/bin/db2ilist 查看当前DB2副本下所有实例)
[i] DB2COMM=TCPIP
[i] DB2AUTOSTART=YES
[g] DB2SYSTEM=ibmdb2
[g] DB2INSTDEF=db2inst1
[g] DB2ADMINSERVER=dasusr1
如果 db2set 命令的输出包含以下内容，那么这表示该实例已配置为自动启动：
DB2AUTOSTART=YES
阻止这些实例自动启动。发出以下命令：
/opt/ibm/db2/V9.5/instance/db2iauto -off db2inst1
/opt/ibm/db2/V9.5/instance/db2iset -i db2inst1 -all
[i] DB2COMM=TCPIP
[g] DB2SYSTEM=ibmdb2
[g] DB2INSTDEF=db2inst1
[g] DB2ADMINSERVER=dasusr1
如果有需要，请在完成修订包安装之后重新启用实例自动启动：
/opt/ibm/db2/V9.5/instance/db2iauto -on db2inst1
7)确保对要更新的实例清除了所有 DB2 进程间通信。作为实例所有者，在每个物理分区中运行以下命令：
$HOME/sqllib/bin/ipclean
Removing DB2 engine and client's IPC resources for db2inst1.
1应用及数据迁移方案 1.1应用及数据迁移概述 本次的应用及数据迁移工作，新旧设备的数据迁移也将体现本次实施工作的水准。 原应用及数据迁移具有时间短、系统结构复杂、测试时间长、设备繁多昂贵、人员 多、层次复杂等特点。本项目迁移工作，应用不能中断，迁移准备工作要充 足,迁移时间在尽可能非工作时间完成，并在极短的时间内完成准备工作，并能够有超过时 间的倒退方案，所有新设备的应用系统稳定性也是一个考验。因此，必须协调好各单位人 员的关系，齐心协力才可能在预定时间内完成应用和数据的迁移工作。 本方案是以尽量不影响XXX信用社的日常工作或将影响降低到最低为前提的情况下制 定的，在小型机及存储设备到货后，先完成对小型机及存储的独立系统安装与调试工作， 第二步完成应用系统的安装与调试工作，整个新系统完成可独立运行后，选择在非工作时 间开始开始数据迁移工作，到工作时间以前完成整个服务器、存储设备的数据迁移及测试 工作。并且在正式上线运行以后，继续跟踪系统的运行情况，随时处理系统运行的异常情 况。当然，在XXX信用社各方面人员的充分协调及配合下才能完成本次应用及数据的迁移 任务。 我公司在上游厂商资源方面有较大优势，如在迁移工作中出现设备故障，除在备品备件中提供的备件外，还可协调各方资源以最快速度解决客户设备故障问题。 1.2迁移规划 1、实施流程: 流程主要根据迁移前的需要制定，主要详细了解当前系统设备情况，系统运行情况。针对所了解情况制定详细迁移方案以及应急方案。 2、专业工程师了解用户原有设备的现状以及迁移后的具体要求。充分考虑 在实施过程中可能出现的各种情况，定制详细可行性的迁移实施计划，将应用及数据迁移
数据迁移方案 作者：Han.Xue 信息系统数据迁移需要考虑的因素很多，比如操作系统类别、数据库类型、版本、数据结构、数据规模、最小允许宕机时间等等。 对于本项目，假定满足下列条件： 1、操作系统一致 2、数据库类型一致，均为Microsoft SQL Server 3、数据库版本均为SQL Server 2000 现存在两种数据迁移的考虑，第一种是新旧数据库系统采用相同数据结构存储，第二种是新旧数据库系统采用不同数据结构存储。下面分别详细说明。 一、不同数据结构的数据升迁 新系统建设完成后，需要对旧系统中数据进行升迁。对于从旧系统中升迁历史数据，需要首先建立旧系统历史数据与新系统数据结构的对应关系，并根据对应关系建立数据逻辑视图。然后使用导入导出工具将历史数据一次性导入到新系统中。数据升迁工作需要遵循以下原则： 1.数据项长度不一致的处理 对于新系统与旧系统的数据项长度不一致的，为了防止数据丢失，应以数据项较长的为准。 2.代码标准不一致的处理 对于新系统与旧系统的同一数据项，而代码标准不一致的，需要
建立代码对照表交由用户审定后再进行升迁。 3.数据采集方式不一致的处理 旧系统为代码输入项目，新系统为手工录入项目的，数据升迁时直接将含义升迁至新系统中。旧系统为手工录入项目，新系统为代码输入项目的，数据升迁时应将数据导入临时表中，由用户确认这些数据的新代码后再导入正式库。 4.增减数据项目的处理 新系统中新增的数据项目，如果为关键非空项，在数据升迁时需要由用户指定默认值或者数据生成算法。旧系统有而新系统已取消的数据项目，原则上升迁至该记录的备注字段。对于没有备注项目的，需要与用户协商是否需要继续保留。 5.历史数据归档的处理 这种数据交换模式为大量、批量、一次性执行的工作。此项工作要求需要支持异常终断后继续，并且在完成数据升迁后，需要出具数据升迁报告交由用户审核确认。如果数据升迁工作顺利完成，原有一期系统数据在备份并刻录光盘后，将不再保留。 6.完成此项工作提交的文档： 1)数据升迁报告 2)新旧系统代码项对照关系备忘录 3)新版系统中取消数据对象、数据项备忘录 4)新版系统由于历史数据升迁工作要求数据结构修订备忘录 5)历史数据清理工作备忘录
正本 招标人：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.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 系统迁移和整合目标 一、系统切换的主要目标： ●保证系统正常运行 在数据转换过程中，由于原有的系统数据的复杂性，给数据转换工作带来了很大的难度，为了在新系统启动后不影响原系统正常的业务，因此数据转换完成后，必须保证新系统的正常运行。 ●保证原有系统在新系统中的独立性 原有系统是独立运行的系统，数据在新系统中虽然是集中存放的，但是各个
文档版本：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.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、数据库方式 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）提前作好停机前的沟通协调工作。
数据库系统和网络存储系统项目数据库迁移实施方案
文档控制 文档修订记录 审阅 分发 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安装数据库软件 (14) 第四章数据移植 (14) 4.1移植准备工作 (14) 4.2移植过程 (15) 4.3系统检查 (16) 数据库检查 (16) 导入后系统需要完成的工作 (17) 应用检查 (17) 4.4系统回退 (17) 第五章应用迁移 (18) 第六章新系统上线后的工作 (18) 第七章工作界面和工作内容 (18) 第八章实施计划 (20) 附件： ............................................................................. 错误！未定义书签。 1.设备、软件验收交付记录.................................................. 错误！未定义书签。 2.操作系统安装 ................................................................. 错误！未定义书签。 3.操作系统镜像 ................................................................. 错误！未定义书签。 3
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，从而使操作过程速度变得极快。此外，数据泵可以提取特定的对象，如特定的存储过程或特定表空
新老系统迁移及整合方案 本次总局综合业务系统是在原有系统的基础上开发完成，因此，新旧系统间就存在着切换的问题。另外，新开发的系统还存在与其他一些应用系统，例如，企业信用联网应用系统、企业登记子网站、外资登记子网站等系统进行整合使之成为一个相互连通的系统。本章将针对新老系统迁移和整合提出解决方案。 新老系统迁移及整合需求分析 系统迁移又称为系统切换，即新系统开发完成后将老系统切换到新系统上来。 系统切换得主要任务包括：数据资源整合、新旧系统迁移、新系统运行监控过程。数据资源整合包含两个步骤：数据整理与数据转换。数据整理就是将原系统数据整理为系统转换程序能够识别的数据；数据转换就是将整理完成后的数据按照一定的转换规则转换成新系统要求的数据格式，数据的整合是整合系统切换的关键；新旧系统迁移就是在数据正确转换的基础上，制定一个切实可行的计划，保证业务办理顺利、平稳过渡到新系统中进行；新系统运行监控就是在新系统正常运转后，还需要监控整个新系统运行的有效性和正确性，以便及时对数据转换过程中出现的问题进行纠正。 系统整合是针对新开发的系统与保留的老系统之间的整合，以保证新开发的系统能与保留的老系统互动，保证业务的顺利开展。主要的任务是接口的开发。 需要进行迁移的系统 需要进行整合的系统 需要与保留系统整合的系统包括： 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数据库中。 上下级国工商局之间的异构数据的集成利用数据交换系统来完成，重点在于数据库存储标准、交换标准的制定和遵守，保证数据的共享，这部分工作由数据中心完成。 系统迁移和整合目标 一、系统切换的主要目标： ●保证系统正常运行 在数据转换过程中，由于原有的系统数据的复杂性，给数据转换工作带来了很大的难度，为了在新系统启动后不影响原系统正常的业务，因此数据转换完成后，必须保证新系统的正常运行。 ●保证原有系统在新系统中的独立性 原有系统是独立运行的系统，数据在新系统中虽然是集中存放的，但是各个系统由于存在业务上的差别，数据在逻辑上应当保持一定的独立性。
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
数据库系统和网络存储系统工程数据库迁移实施方案 1 / 18
文档控制 文档修订记录 审阅 分发 目录 第一章文档介绍3 1.1背景3 1.2目标4 2 / 18
第二章系统硬件选型5 2.1存储设备6 2.1.1 设备选型6 2.1.2 设备功能及实现6 2.2服务器设备6 2.1.1 数据库服务器6 第三章系统安装8 3.1主机系统安装8 3.2配置SAN网络、磁盘阵列10 3.3配置HACMP10 3.4安装数据库软件12 第四章数据移植12 4.1移植准备工作12 4.2移植过程13 4.3系统检查14 数据库检查14 导入后系统需要完成的工作15 应用检查15 4.4系统回退15 第五章应用迁移16 第六章新系统上线后的工作16 第七章工作界面和工作内容16 第八章实施计划18 附件：错误！未定义书签。 1.设备、软件验收交付记录错误！未定义书签。 2.操作系统安装错误！未定义书签。 3.操作系统镜像错误！未定义书签。 4.设备配置清单(需确认)错误！未定义书签。 4.1 IBM p570服务器错误！未定义书签。 4.2 光纤交换机配置错误！未定义书签。 第一章文档介绍 1.1背景 3 / 18
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目标 针对某电厂实际业务需求，本次建议方案提供数据库的迁移，新采购设备选购、系统配置及业务上线测试到最终的迁移。 4 / 18
文档版本：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数据迁移需求 (5) 4数据迁移方案 (6) 4.1正式数据库数据 (6) 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 集群,如下图：
应用及数据迁移方案 应用及数据迁移概述 本次的应用及数据迁移工作,新旧设备的数据迁移也将体现本次实施工作的水准。 原应用及数据迁移具有时间短、系统结构复杂、测试时间长、设备繁多昂贵、人员多、层次复杂等特点。本项目迁移工作，应用不能中断,迁移准备工作要充足,迁移时间在尽可能非工作时间完成,并在极短的时间内完成准备工作,并能够有超过时间的倒退方案,所有新设备的应用系统稳定性也是一个考验。因此，必须协调好各单位人员的关系，齐心协力才可能在预定时间内完成应用和数据 在小型 到工作 2 3 情况分为多个系统进行分类。 4、在迁移过程中需要XXX信用社技术人员密切配合。 5、为保证迁移工作顺利、有序、安全的进行将制定详细的迁移流程，进行细致的分工，具体工作 安排到人，责任到人。 6、迁移工作中的工作原则最少安排3人以上，以保证工作的准确性。 详细实施方案 本次设备安装实施时间为20天。我们将尽量细化任务安排保证工作顺利进行。
为了迁移能按时顺利进行，并且在迁移后能够保证设备及应用正常运行，我们制定了一系列简单明了的工作表，帮助工程实施人员确定各种迁移工作中要执行的工作是否完成。避免工作失误，避免 造成迁移工作的延误。 实施流程： 环境的要求： 需要在迁移前检查环境及设备设施是否符合要求，本工作表是保证迁移后设备能否稳定正常运行的先决条件，在迁移前由迁移负责人同相关人员填写确认。 数据备份 数据备份需要迁移负责人和系统管理人员在设备迁移前对原设备进行备份。这次备份是迁移前的最后一次备份，是必须认真完成的一项工作。是数据迁移后数据是否完整的关键。备份包括服务器的 数据备份。网络设备的配置文件备份等。 此工作表在备份时由迁移负责人同系统管理人员共同确认完成。 服务器表
文档版本：0.7芜湖市区域卫生信息平台 数据迁移方案编制单位：东软集团股份有限公司 2014年11月12日
文档修改记录
1 弓I 言. (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 正式数据库环境（旧版） 旧版数据库为正式数据库，做了集群，其用于2012年、2013年的项目实施采 集，于2014年进行项目升级时暂停使用。 说明: 旧版数据库环境，交换库的数据完全无用，中心库的数据偶尔应对上级检查的集成浏览器调阅 显示（由于新版浏览器集成未做好），且只应用于旧版浏览器的调阅使用。 2.2 临时数据库环境（升级） 说明: 临时数据库环境的数据为2014年升级后采集的数据，数据库均未做集群，平台所有新版应用、综合管理系统、新上线的服务均连接访问临时数据库28。 3数据迁移需求 3.1软硬件需求 操作系统字符集为8 ； 两台小型机虚拟出独立的四台机器，两台作为交换数据库，两台作为中心 数据库，并支持集群，如下图： 1 :…r. kr
1.数据表分析 数据迁移首先需要做的是数据表分析，分析哪些数据表需要迁移、哪些数据表可作为初始化数据、哪些数据表不必操作，只有确定了需要迁移的数据表，数据迁移测试才是符合情理的工作，在确定了需要迁移的数据表之后，需要关注开发的数据迁移方案，根据具体的迁移方案制定测试方案，以下是数据迁移的测试步骤。希望各位指正！ 2.数据量的检查 数据库数据转移的前提必须要保证老数据库中的文件全部迁移到新的数据库中了，所以第一步要保证迁移的数据量正确 3.分析新老数据表的变化（举例从B表迁移数据到A表） 2.1B表中的字段对应到A表的哪个字段，例如B表的status迁移到A表的zhuangtai 1.直接迁移，对于某些字段的值可以直接迁移到新表中，但需要注意新旧表字段的长度和精度是否一致。 2.字段运算，数据源的字段进行数学运算得到目标字段，一般为数值型字段，例如ID。 3.参照转换，数据源的一个或者多个字段值作为key值查找出另外的值迁移到目标字段中。 4.字符串的装换，字符串在转移的过程中容易产生脏数据，需特别关注，另外字符串中有特殊字符的需要特别关注。 5.空值转换，在旧表中字段为空值对应到新表中相应的字段是否仍然保存为空值，需要关注；需要特别关注空与NULL的区别。 6.日期转换，注意新旧表日期格式的变化。 7.聚集运算，数据源的一个或者多个字段通过聚集函数得到新表的数据，例如sum,count,avg,min,max。 2.2B表中存在但A表中不存在的数据字段 1.直接废弃，将B表中的字段值直接废弃不迁移。 2.B表中的字段值通过特殊处理转移到A表中的其他字段，例如B表的资源编号转换到A表中作为提供商的资源编号 2.3B表中不存在但A表中存在的字段 直接留空. 根据实际的业务初始化一个字段值 4.业务的扩展 根据实际的业务情况查看数据迁移后相关的表中数据的变化情况，例如资源信息迁移后，资源的相关属性（资源所属的地域信息、资源的提供商）需要进行检查。 5.迁移后检查 数据迁移结束后先结合前台页面查看下迁移的数据能否正确显示，并且要保证数据迁移不会产生垃圾数据 6.数据制造 在测试数据迁移的过程中对于一些逻辑较为复杂、表结构很复杂的表，可以在测试数据迁移之前制造一些关联的数据，作为“卧底”潜入组织进行工作，工作结束后查看“卧底”