达梦数据库移植方案篇二

3.2.4 迁移实施策略选择

3.2.4.1 全量迁移

将所有数据一次性全部迁移，在这个过程中数据内容不能有更改，所以一般这种情况是使用脱机迁移的方式，通过达梦的迁移工具 DTS 来实现数据迁移。

3.2.4.2 增量迁移

数据量比较大，窗口期内无法将所有数据迁移出来，这时需要分多次将数据迁移，可以使用数据实时同步工具 DMHS 进行数据迁移。

3.2.4.2.1 按时间

每天规定的时间进行数据迁移，一般选择业务不繁忙的时间段。

优点：不影响正常业务的办理。

缺点：是如果每天新增的数据量比较多，要追平数据的时间会长。

3.2.4.2.2 按功能

可以按照业务的功能进行迁移，比如一般先迁移一些不常用的功能来验证方案的可行性。

优点：对业务功能的影响较小。

缺点：在分库分表上要仔细考虑。

3.2.4.2.3 按地域

按地域先后进行数据迁移，进行地区试点能更好的验证方案的可行性。

优点：方案的验证成熟后再全面推广，能减少不可控的情况出现。

缺点：已经迁移数据的区域和未迁移数据的地区在应用层面上可能出现差异。

3.2.4.3 柔性替换    

为了切实降低安全风险、改善用户在国产基础软件替代过程中的问题，对此达梦公司在数据库自主可控替代过程中，研发了“实时同步软件”（DMHS）所构建的“双活”、“AB”角解决方案，借助 DMHS 实现了柔性替代方案，并妥善解决了这一问题，该方案分为三个阶段。

3.2.4.3.1 第一阶段

Oracle 集群做主库负责读写业务，DMHS 同步至 DM 主备集群，DM 主备集群旁听，测试 DMHS 同步功能。

3.2.4.3.2 第二阶段

DM主备集群负责读写业务，Oracle集群做备库。DMHS全部数据同步至oracle集群。

3.2.4.3.3 第三阶段

最终将 Oracle 备库集群完全撤出或者将 Oracle 备库集群替换成 DM 数据库做为备库。

3.2.4.4 分批实施

3.2.4.4.1 第一批试点

可以选取部分用户进行试点，确定用户范围后将涉及的数据迁移至达梦，老系统和新系统并轨运行，公共数据使用 DMHS 进行同步，观察业务承载量和压力。

3.2.4.4.2 第二批试点

在满足当前业务的前提下，根据实际情况增加用户范围，扩容集群节点和数量，调整同步方案，逐渐进行第三批、第四批试点，最终全部替换。

3.2.5 数据库迁移流程

数据迁移过程，可分为迁移规划、数据整理、数据迁移和系统切换四个步骤。 其流程如下图所示：

 

图：数据迁移的 4 个阶段

 

数据迁移的 4 个阶段目标和着重点不同，迁移规划阶段确定数据迁移的目标和范围，并确定迁移的人员和工作计划。数据准备阶段主要对原数据进行校验并进行数据清理、数据整理，保证数据迁移不会受原数据中的异常数据影响。数据迁移阶段主要完成迁移程序的开发和验证，迁移程序完成原数据到新数据的转换、清理工作，并通过测试对比保证迁移程序的正确性。最后的系统切换阶段，完成原系统到新系统的切换，保证系统间的无缝对接，保证业务的正确性和连续性。

3.2.5.1 迁移规划阶段

迁移规划阶段主要对迁移过程进行整理规划，并明确需要的各类软硬件资源和组织机构。此阶段的主要工作如下：

1.成立数据迁移小组。数据迁移小组的成员应包括本次项目的分析设计人员，原系统的开发设计员、原系统的维护管理人员、原网站的内容维护人员和主要使用人员等组成；

2.明确系统迁移计划的目标。迁移计划的目标包括对迁移数据的范围、内容以及最终在新系统中的使用范围的明确。   

3.明确系统迁移工作的质量要求。需要明确对迁移数据的质量要求，包括最终对数据迁移效果的定义和校验方法，可以定义几张统计表对比迁移前后数据的一致性和完整性等；

4.制定项目实施时间表。最终制定迁移的时间进度表，明确迁移的任务。

3.2.5.2 数据准备阶段

数据准备是对系统业务数据，进行遵守统一标准的规范性整理、补齐数据内容的完整性和实现数据的正确性，包括内部整理和外部核对两部分。

在进行数据迁移前，应做好充分的准备，进行充分的前期准备可以帮助把系统过渡的风险很好地分散。主要包括数据整理、数据校验、迁移准备和异常处理：

1.数据整理

分析需要迁移的业务数据，确定迁移数据量。对原有数据的数据库结构、代码表、业务管理和数据逻辑进行分析和整理。此阶段需要根据原系统的数据库设计以及系统设计文档为基础、并与原系统开发设计人员以及熟悉原系统的管理维护、业务使用人员的配合，最终形成原数据的分析报告作为后续数据整理，校验、迁移的基础。

2.数据校验

建立数据库表的映射关系，进行系统之间数据检查。在数据整理完毕后，对实际数据的质量进行校验和整理的过程，其主要目的是对原系统的数据质量情况进行分析和排查，在迁移之前将有问题的数据清理处理完毕。从下面三方面：完整性、有效性和一致性进行。

完整性。对数据完整性进行校验时，要以新系统的数据要求为基准，检验新系统中规定不可为空的数据或在新系统中非常关键的一些数据在老系统中是否存在。对于校验出来不完整的数据需要使用这些数据的用户单位予以配合补齐。

有效性。数据有效性校验首先要明确需要进行校验的目标数据及有效值范围。一般说来代码类的数据都是需要进行有效性校验的，这些数据的有效值范围也比较容易确定。另外还有些数据如出生日期、年龄等也是需要进行校验的。这些数据的有效值范围相对来讲比较难确定一些，但基本上都能确定一个比较合理的取值区间。校验出来的无效数据同样需要使用这些数据的用户单位配合进行更正，对于更正的结果需要进行重新校验。

一致性。数据的一致性校验是通过同一表内或多个数据表间的相关数据项的比较来进行的，要校验历史数据的一致性就必须对原有系统的数据表间的各种关系，数据流向等非常的清楚。检验出来的不一致数据需要交给使用这些数据的用户单位进行更正，对于更正的结果要进行重新校验。

3.迁移准备

准备数据迁移的工具，编写数据迁移的测试计划和校验程序。进行历史数据质量分析，确定采用手工、半自动或全自动等方式进行数据的清洗、整理和转换。具体过程是，首先根据具体系统的情况，制定方案，建立结构规范的临时数据库（简称为整理库或中间库），将原生产数据转换导入该库。然后对导入的信息进行初步比较、核查、校正以后，采用逻辑推理、经验判断、合理数值范围检验等方法，进行合法性检查及代码过滤等方面的审核和筛选，滤出可疑数据和缺失数据，并提交至外部核对环节，由原负责业务处室、科技部门和维护单位等补充确认。

4.异常数据处理

异常数据处理就是对数据校验发现的不完整或者不一致的数据进行处理和调整。对于不完整的数据需要根据已有的数据进行推导和补充，但这种补充必须依据业务的内在逻辑，并得到业务人员的认可。

对于无效数据需要进行清理和补充，无法对应的数据需要删除、代码不存在的数据项需要根据实际情况进行补充或者校正、对于不合理的数据需要提交业务人员判断并做出相应的处理。

3.2.5.3 数据迁移的实施

数据迁移阶段是根据数据整理阶段产生的数据分析报告和数据校验的结果开始将原有系统的数据实际迁移到新系统中。数据迁移逻辑功能图如下。

图：据迁移逻辑功能图

迁移的过程需要首先进行数据的迁移设计，将原系统的指标与新系统的对应指标进行匹配，设计数据转换和清洗的规则，然后进行迁移测试，验证迁移程序的稳定性、容错性和正确性，最后对迁移的数据与原数据进行对比，根据对比的结果调整迁移程序并重复测试直到达到原定的质量要求为止。

数据迁移后的校验是对迁移质量的检查，同时数据校验的结果也是判断新系统能否正式启用的重要依据。同时对迁移的数据进行备份，避免数据丢失。

3.2.5.4 系统切换

系统切换阶段就是新系统上线替换旧系统的过程。此阶段的重点是保证新旧     系统的平稳过渡，无缝对接，保证公众能正常访问系统，业务人员的工作不受影响。系统切换分成三个步骤，分别是：原系统停机、数据正式迁移和新系统上线。

1.原系统停机

在新系统上线，数据正式迁移之前需要首先将原系统停机下线，否则将不能保证数据完整的迁移到新系统中，可能在数据迁移完成后又有新的数据发布，使得数据又发生变换，造成数据不统一。由于新旧系统在信息发布和数据处理上会有所不同，在原系统中处理一半的数据可能无法在新系统中继续使用，因此在原系统停机前应当要求业务人员将所有正在发布的内容和处理的数据都办结，保证数据都是完整的。

2.数据正式迁移

在原系统停机后，保证业务数据已经不再变换，开始正式运行数据迁移程序，将原系统数据迁移到新系统中，完成后再次运行迁移结果比对程序，比对数据迁移一致性和新系统功能完整性。这个过程中原系统数据仍然保留原来的状态，一旦数据迁移失败，可以快速的恢复原系统的运行，保证网站访问和信息查询不受影响。

3.新系统上线

数据正式迁移完成并比对测试通过后，新系统可以上线运行，如果新系统上线失败，可以紧急恢复原系统得运行，保证业务办理不受影响。

3.3 移植方案确认

在分析了系统特性和用户需求之后，应确定移植的重点和难点，并确定移植方案。

移植工作通常分为后台数据库的移植和前台应用系统的移植。在进行后台数     据库的移植时，以数据库供应商为主，应用软件开发商则应提供对应用系统比较熟悉的技术人员配合移植工作；在进行前台应用系统的移植时，则以应用软件开发商为主，此时数据库供应商提供该数据库的技术支持服务，并负责和承担数据库差异的解释工作。

用户方、数据库供应商、应用系统开发商应该协商确定项目的实施范围、目标和工期安排。

对于数据库供应商来说，应该根据用户目标和系统分析结果制定合理的移植方案，并报用户方确认。在移植方案得到各方正式确认后须严格按计划执行移植方案，如有变更须及时征得各方协商同意。

4 移植方案实施

4.1 移植方案的实施策略

对于基于 Oracle 等其他数据库开发的应用系统需要移植到达梦数据库上进行上线的，需要做好数据迁移和应用移植工作。

数据迁移和应用移植对系统切换乃至新系统的运行有着十分重要的意义，数据迁移和应用移植的质量不仅是新系统成功上线的重要前提，同时也是新系统今后稳定运行的有力保障。

数据迁移和应用移植的实现具体可分为以下阶段：

1）迁移工作评估；

2）数据库初始化参数配置；

3）对象定义迁移；

4）数据迁移；

5）校验数据；    

6）应用移植验证。

整个迁移工作应该形成完整的《迁移方案》。

在做移植的时候，主要包括数据库的迁移和应用系统移植。在应用系统的功能移植的过程中，保持一个原则就是不改变其应用逻辑，因为在功能移植的阶段重点是在解决系统差异上面，如果过多的考虑应用逻辑问题，移植工作的进度将会受到影响，也增加了移植工作的难度，同时如改变应用的程序逻辑，将存在功能修改错误的风险。

在进行后台数据库移植的时候，最好找一个比较方便操作，便于进行内容查找、内容替换和差异对比的编辑工具，如使用 Vc 的编辑器，Beyond Compare 等工具，也可以辅助使用版本控制工具，如 CVS 等，因为移植过程中需要经常进行修改，这些工具可起到一个很好的辅助作用。

后台数据库的移植工作主要是脚本的移植和数据迁移工作。一般采用的顺序是先进行脚本的移植，再进行数据的迁移，这样做的好处主要有以下的几点：

1. 整理好脚本之后，便于快速搭建移植环境。

2. 有了脚本文件，能够对系统有一个整体的了解，便于对系统的把握。

3. 容易进行相应的特殊处理，如缺省值、类型、主键、外键等的处理。

4. 便于存储模块的移植。

5. 便于优化系统等。

当后台数据库中用到的存储模块、触发器等较多的时候，并且脚本长而复杂，这时候最好进行多人合作。

前台系统的移植主要是连接串的修改，一些差异的修改，如 SQL 参数的处理等，因应用系统千变万化，只能具体情况具体对待。    

在移植的过程中注意做好修改记录，便于分析查找问题。

4.2 移植前的准备工作

在正式开始移植工作前，应明确各方要求，例如项目总体目标、项目重要节点时间的进度计划安排、用户方提供的停机窗口计划、用户方提供的软硬件环境等。

此外，还必须开展的工作有：收集原系统信息，包括原应用系统和数据库系统的部署架构、集群方案、网络拓扑及软硬件设备配置；搭建环境，根据项目需求搭建对应的软硬件环境，配置服务器、网络设备、操作系统、数据库、中间件等；开发、测试、生产环境的检查，包括服务器配置检查、数据库安装配置检查、操作系统参数检查、网络环境检查。

4.3 数据库迁移

4.3.1迁移工作评估

迁移工作量的准确评估，是完成数据迁移的基础。对源数据库的数据进行分析：数据的存放方式、数据的种类（数据类型）、数据量等，只迁移应用系统需要的数据，不迁移重复的、违反业务规则的脏数据。

4.3.1.1 统计源数据库基础信息及对象个数

表 迁移对象统计

4.3.1.2 统计源数据库待迁移的表的记录条数    

表：表数据量统计

4.3.1.3 应用环境迁移评估 

迁移工作的评估需要根据达梦最新手册提供的最新支持列表进行评估。

1）应用访问数据库的接口？    

达梦支持通用数据库访问接口，如 JDBC，ODBC，Python，PHP，Oracle兼容接口(OCI 等)、Node.js 等。

需要评估是否使用专有的数据访问接口，如 Oracle 数据库的 EBS 接口等。

2）应用系统是否通过中间件或第三方软件访问数据库？

达梦支持主流软件的操作数据库方式，如中间件 Hibernate，东方通，金蝶，中创等。

需要评估应用是否使用第三方访问数据库的软件，如 Openstack 框架、第三 方数据备份软件如 NBU 等。

3）是否需要特征硬件的支持？

达梦支持主流硬件平台 X86-32/64、SPARC、Power、Itanium 等，包括国产兆芯、龙芯、飞腾、申威等国产硬件平台。

需要评估系统是否需要特殊硬件平台，如加密硬件等。

4）应用开发是否使用了某个产品的特征功能？

需要评估产品的特征功能，如使用 HA 软件等。

5）有应用迁移需求的项目，由于不同数据库产品策略的差异，是否涉及应用的修改和调整？

应用迁移需要评估修改的代价，如果是数据源是 Oracle 数据库，应用修改的代价较小。如 SQLServer 是单实例多数据库的架构，应用迁移中 PL/SQL 迁移代价大于 Oracle。具体项目需要具体分析。