数据库迁移 存储过程、包，触发器，脚本和应用程序,数据库的迁移

本文讲述了数据库迁移 存储过程、包，触发器，脚本和应用程序,数据库的迁移

成本和风险因素都被详细介绍，同时也会着重介绍ZTO2M和其相关技术以便了解如何完成一次高效的转换。

在过去几年中MySQL被证明是十分稳定和可收缩的数据库产品，在很多数据库排行榜上MySQL紧跟***之后，是世界上最流行的开源数据库。很多企业利用MySQL社区版的免费优势，有效降低了软件许可证、硬件、管理等多方面的成本。然后从***迁移到MySQL平台最大的挑战在于要将复杂的业务逻辑和数据结构转换成MySQL的格式，特别是在现有应用程序本身大量使用***特性例如 PL/SQL存储过程、触发器、程序包package和***特有SQL语句的情况下。

由此***到mySQL的迁移会变得困难重重，耗费大量时间、以及异常昂贵。ZTO2M的设计就是为了简化这种迁移的复杂度，做到对于简单的应用程序使用的***数据库（极少使用PL/SQL存储过程、函数、触发器或包的实例）可以一路next迁移。对于复杂度较高的场景则可以极大降低迁移工程师的工作量。这一系列技术革新的目的就是为了降低***到MySQL迁移的成本和风险。在ZTO2M的帮助下，迁移的工作量可以被评估，迁移计划可以有限规划，迁移动作可以自动化运作。 在合理使用ZTO2m的前提下迁移工程师会从一个无地下脚的场景中解放出来，有效降低70%以上的工作量。

迁移复杂在哪里？

***数据库提供非常先进和丰富的技术给我们的应用程序开发者来开发异常复杂的应用程序逻辑，这几乎导致开发者生成一种对***的强烈依赖感。举个例子来说在开发应用程序上***就像自动档位车，有效降低了开发者本身的技术门槛，让初级的开发者也能实现复杂的业务逻辑的同时保证一定的性能。其所提供的开发技术包括PL/SQL存储过程，函数，程序和触发器。

*** Pl/SQL语言是一种易于使用的开发语言，PL/SQL天生是对SQL的一种强大的基于过程的扩展，在各个行业PL/SQL都有广泛的使用，例如EPR行业中ORACLE EBS应用程序中大量采用PL/SQL来实现各种业务逻辑。在绝大多数应用程序中，使用PL/SQL必然导致不小数量的存储过程、包和触发器。MySQL中虽然也有类似的功能，但和PL/SQL差异巨大。

除了***特有的语法外，PLSQL提供很多非ANSI标准化的复杂特性，包括如下这些：

• Package包，共享包变量，内建包

• %TYPE,%ROWTYPE,exception

• 面向对象的特性：object type,函数，集合

• 商业智能和XML特性

如果你需要转换PLSQL代码（过程，包，函数和触发器）或查看/查询包含*** 特有的SQL语法，则你不得不了解这些特性到底是如何使用的，并确定这些使用存在的分布和数量。下面是一些例子需要被重视的：

• 非ANSI兼容性的SQL函数，操作符和语句

• results set

• 游标循环

• exceptions

• 临时表

• 对象类型和函数

• 集合

• 动态SQL

• 内建包

• OLAP函数

• XML函数

在你完成上述评估后；最好在理清下MySQL中对象的功能或解决方案以便替代***特性的特性。一般可以在后续章节找到典型的迁移方案。

应用程序评估

除了schema和服务器端的商业逻辑转换外，用户有时还需要修改应用程序内的SQL语句。此时评估工作量将是至关重要的。

从一开始你就要检查所有哪些你的应用程序正在使用的数据库API； 获取你的应用程序源代码，这些代码包括在数据库外运行的JAVA或其他语言程序，包含在程序中的SQL语句，和存放在***中的PLSQL代码；获取所有这些程序的代码并一一评估，毫无遗漏在迁移中是至关重要的。

大多数应用程序使用一种标准的API: ODBC,JDBC或http://ADO.NET来访问***，但是一些应用程序可能使用一种原生的 API例如ORACLE OCI或Pro*C或C++。收集这些信息细节是必要的。

即便你使用的是标准API，例如 ODBC/JDBC这些驱动器，还是要对现存的SQL语句做大量的修改。举例来说 DECODE函数或左外连接语法(*)都需要被改写。ZTO2M工具可以有效抓出这些***原生语句。

若应用程序确实使用了***原生API例如OCI，则几乎需要全盘重写数据库访问部分的代码，修改为使用MySQL API或ODBC。

评估工具

ZTO2M工具工具可以有效评估现有***数据库内使用过的SQL语句，已经创建的PLSQL对象。以下是一个简要的评估表：

基于上述评估结果，用户可以编写迁移计划。若用户只有几十个存储过程，则可以考虑做手动代码转换。但是如果你有成千上百个存储过程需要迁移，则最好还是评估使用ZTO2M的自动转换功能。

成本和风险

迁移项目相关的成本和风险主要来源于迁移的代码量。***独有的特性用的越多则迁移复杂性越高。同时***特性用的越多则自动化迁移工作所能做的也越多。

数据和DDL迁移成本

数据和DDL对象迁移是最典型的迁移对象，所以其迁移成本较低，工作量相比起代码－应用程序迁移而言简单得多。

典型的数据和DDL迁移包含如下的转换：

• 数据类型

• 约束 主外键，唯一键，空值，默认值

• 数据转移

• 索引

虽然***和mysql之间的DDL语句中存在语法差异，但有着类似的数据类型（字符，数字，日期，时间，LOB大对象等）并允许你指定类似的完整性约束。

样例DDL/数据迁移评估：

由于是自动化操作，所以迁移DDL和数据的成本与表的数量和数据的大小没有直接的关系。举例来说，若数据结构差异不大，则迁移100个表和300个表在成本上是近似的。

但当表的数量和数据容量大到某个数量级别，则用户需要花费更多的时间来配置MYSQL数据库，调优数据传输速度，并关心例如索引创建性能等细节。

迁移DDL和数据的风险

典型的DDL/数据迁移的迁移风险较低。使用ZTO2M可以将整个数据库的应用DDL和数据都迁移过到MySQL数据库中。

典型的工作流如下：

1. 启动全库传输

2. 检查传输错误，比较表结构，比较***和MySQL中的表的行数

3. 针对所有表或有针对性的表做验证和测试数据，可以用如sqldeveloper、 mysql query browser等工具做验证。

4. 运行应用程序连接到新的MySQL数据库做验证

数据迁移中的挑战：

虽然常规来说数据和ddl迁移是相对简单的，与之相比商业逻辑转换要复杂得多。但下面这些场景会增加数据和ddl迁移的难度：

超大数据量

若你需要迁移超大容量的数据，你可能需要进一步配置Mysql目标服务器。

极大容量的数据将直接影响迁移过程，特别是何时才能完成迁移。为了降低迁移时间，你可能需要将迁移工作以并发的形式来提高效率。当然这将增加迁移的复杂度。

对于海量数据的迁移可能在迁移过程中出现报错，若出现报错则可能导致你没有足够的时间再重新跑一次整个迁移过程。

迁移项目将受益于批量插入特性，通过bulk insert可以大批量插入数据从而减少交互和循环次数。

最小停机时间

在一些关键任务环境中，你必须让停机时间最短，例如对于医院和银行、电信等关键业务而言只允许停机1个小时。为了迎合这样的要求，就必要将数据迁移工作以最快速度并行实现，或在非停机窗口时间将静态表优先传输完成。有些时候也要利用一些同步复制工具例如goldengate来减少停机时间。

强性能要求

在一些环境中对于产品数据库性能有着极高的要求。但当迁移到MySQL后，很难保证性能要比原来的***好。这样就要求用户花费更多的时间去做数据库调优，更重要的是在迁移前做必要的全盘性能测试。

数据迁移风险

具有挑战性的数据迁移工作不是简单的点击下鼠标就能完成的。在正式迁移前建议做一个完整的 POC proof of concept。

在大多数情况下，对于迁移进程而言简意做如下的准备：

1. 做 迁移POC以检查可行性

2. 测试迁移以便做完整的测试，包括 可用性和性能

3. 产品迁移

商业逻辑转换成本

若数据库包含几十个存储过程和触发器，则很容易纯手工重写代码到 MySQL的标准。若你有成千个存储过程和触发器，则手动转换的成本太高了。用户必须考虑基于自动化工具来实现大量代码的转换。

手动转换的成本直接与代码的函数相关。换句话说，自动化工具极大的降低了成本，并让迁移上百万行代码的项目存在一个合理的报价。

取决于要转换的代码行数，自动化转换商业逻辑代码对比手动转换降低了7～10倍的成本。

***特性在代码中使用的分布和频率决定了商业逻辑转换的复杂度和自动化工具工作的复杂度级别。

ZTO2M的有效自动转换可以针对95%以上的复杂业务逻辑做到自动转换。

下面是一个简单的例子，对于业务逻辑转换而言的工作项目罗列：

若你要比较DDL/数据和业务逻辑的迁移，则你回发现后者的成本占总本的约95%。这是***到MySQL迁移的基本因子。

业务逻辑迁移风险

若有大量的代码行以及分布广泛的***特有特性要做迁移，则转换存在较大的风险，这样需要几个步骤来实现迁移。

经验

负责做迁移项目的员工应当有该项目的开发者和管理人员，并拥有较为丰富的***和MySQL使用经验。他们需要清楚工作中的挑战、任务和各个阶段。

完整的评估

在最初的阶段，用户需要实施一个完整的数据库评估。作为整个评估的产物用户将知道哪些特定的功能需要做转换，例如用户最终要决定使用何种方案去替换非 ANSI的 ***特性。

用户需要判断是否针对各个特性存在一个解决方案。一些***特性是不易于去转换到MySQL的，这时则需要重新设计这些功能

在所有代码基础上做 POC

例如 ZTO2M的自动化工具让迁移易于去执行，完全可以在初始阶段直接对所有的代码做转换测试。我们建议在一开始就使用 ZTO2M介入进来，以便暴露所有的潜在问题，并厘清哪些部分是可以自动化完成的。

最重要的是，这会让你对这些笨重的PL/SQL 代码的转换充满信心。

尽可能使用自动化迁移

虽然纯手工迁移的成本很高，但其在初始阶段有就有效发掘了解决了瓶颈。与之对比，自动化工具在低成本的前提下让转换能够大量重复执行，但需要用户更多的反馈介入其中。 通常来说，手动转换是一项十分繁重的体力和脑力劳动，即便对于有经验的人而言也会出现一系列的人类人为错误。 几乎没有人能承受常见做这样的工作，因此手动转换是高成本的，同时也会耗费大量的时间。

早期测试

在早期阶段测试应当可以最小化工程的风险。用户可以在应用级别的功能测试还没开始前就开展单元测试，或实施代码核验。

利用自动化工具可以自动产生 测试场景来以特定变量调用存储过程和函数并比较结果。请注意这并不能替代应用级别的功能测试，但可以帮助发现潜在的问题。

应用程序转换

除了服务器端的业务逻辑转换外，在大多情况下你还需要修改你的应用程序以适应MYSQL。

在 java或Powerbuild应用中都可能存在非ANSI的SQL语句，不同于MySQL的 SQL语法的语句都需要修改。

例如***的左外连接(+)使用特殊的语法，那么转到MySQL中就要特别当心了。decode,nvl和sysdate都要特别注意。

你不能光使用find/replace寻找替换来替换函数名，在大多数情况下，函数都可能有不同的参数语法或需要SQL语句做整体修改。

此外简单的string字符串替换可能会替换那些不该替换的位置，例如字符串，或java语言语句。

最佳的方式是使用例如ZTO2M工具的自动修改应用程序的能力来转换SQL语句到合理的MySQL语法。

ZTO2M工具可以正确识别代码中SQL语句，实施转换，并生成修改报告，极大地简化了转换工作。

方案规划

合理的方案规划对于成功的迁移而言至关重要，典型的迁移步骤如下：

评估

评估涌来分析数据库和应用程序，定义迁移范围，记录那些***特性功能的使用。

基于评估产生的信息，用户可以定义具体要使用的方法途径：手动转换还是自动转换以及相关的风险。

在早期阶段完成一次全部转换 这是一次POC

假设你的数据库有2000个存储过程，那么你可以使用ZTO2M来转换所有的代码，特别是在 POC阶段。我们建议你这样做无论你是否喜欢一个模块一个模块来做测试和部署。

显然现在是迁移的早期阶段，但对整个迁移项目的基本了解和反馈是很重要的，这让我们大概知道要踩哪些坑。显然用软件实现自动化转换与手工转换要花上几十个小时来预习这些代码要来的核算。

基于ZTO2M你可以实施一个整合和统一的迁移方法。 与之对比手工转换必然是在一群人中开展，不同的存储过程，不同的代码风格现在又要求一堆人来修改，可以想象工作的繁重。所以显然风格约统一结果越好。

理想状况下用户的转换完成后可以在MySQL中直接无错运行。这意味着所有的表、函数、过程和触发器都在MySQL中成功创建。

对于复杂的应用代码而言100%转换是十分困难的，我们通常还是要做一些手动修复工作。

运行时，逻辑以及性能测试

迁移经常是以一个一个模块的形式来实现的。当你已经转换了服务器端的业务逻辑，而应用程序还没做转换且应用级测试都还没做时，应当先做数据库的转换。

用户可以选择几个有代表性的或特别重要的过程来做代码检查。当然你可能在检查代码时并不能找出所有的毛病，但在早期阶段这仍是必要的。

通过检查转换后的代码，你可以找出使用了哪些替代技术方案，并评估转换质量。

若你想深入了解转换的技术背景则有必要对哪些***独有特性的转换情况列出清单。

即便你的代码在转换后可以在MySQL中成功创建，也不意味着运行时不会出错。许多报错可以在运行时快速发现。

ZTO2M可以针对存储调用采用不同的输入变量；在测试代码时ZTO2M可以知道哪些变量被使用了，使用的变量类型是字符串还是日期常数，流程控制条件。 为了实施复杂的逻辑和性能测试，用户也可以用真实数据配合自己开发的测试脚本来满足多种多样的测试场景。

若你针对***数据库使用自动化测试软件，则考虑升级这些自动化质控软件以应对MYSQL。

典型的转换场景 － 样例

虽然转换任务和方案是case by case的，也就是说每个项目的都差异很大；但转换工作中的大部分内容还是相似的。

注意 所有下面提到的转换场景都可以使用ZTO2M来自动转换。

DDL

***和mysql都支持create table语句，但语法差异很大：

数据类型

保留词

***和MySQL 使用不同的保留词 ，所以一些列名在MySQL查询中要打上引号：

查询和PLSQL代码

你需要修改SQL语句以修改函数和表达式的语法。PL/SQL代码要完整地转换到MySQL SQL过程语法。

Outer Joins外连接

***对外连接支持特定的语法，并被很多应用程序大量使用：

给列自动分配ID

***在12c之前不支持自增列（auto0increment identity column)，一般用sequence 序列来实现对应用程序新ID的分配。

***中虽然创建一个简单的序列sequence对象可以用来给多张表分配值，但绝大多数场景中也就只是给一张表分配ID罢了，所以可以利用***中的自增列 auto-increment column 。

代码形式如下：

同一个event多个触发器

在***中，针对同一张表用户可以定义多个触发器应对同一个事件（例如针对employees表的INSERT事件有多个触发器）。

在MySQL里这个行不通，所以要求把针对该事件的所有代码都写在一个触发器里。

包和共享变量

在***中，一个包是一组相关存储过程和函数，并可以共享变量。MYSQL中存储过程和函数都要转换成单独的对象。

包变量可以在包中的存储过程中被修改，之后另一个包中国年的存储过程可以看到并传递回变更的变量。 在MYSQL中可以以@符号开头的会话变量来替代这一功能：

返回的结果集

在***中要用一个游标变量(REF CURSOR)当一个外参来返回结果集。 在很多场景中，MYSQL里就是很简单的SELECT

%TYPE 和 ％ROWTYPE 数据类型定义

***中%TYPE属性允许开发者让PL/SQL变量和表上的列的数据类型一致。在MYSQL里，用户需要精确指定数据类型。

JAVA应用程序中的SQL转换

在JAVA应用程序需要这样修改SQL语句语法：

powerbuilder应用程序中的SQL转换

在powerbuilder中，需要这样修改SQL语法：

一些其他的不支持的功能

ORACLE PL/SQL中很多功能点仍不被MYSQL SQL过程语言支持。若这些功能确实在源库中有被使用，则需要利用一些方法绕过：

PLSQL集合

MYSQL中可以使用临时表和SQL DML 操作(SELECT ,INSERT,UPDATE,DELETE)

RAISE_APPLICATION_ERROR

在 MYSQL 存储过程中可以使用 UDF来报错

UTL_FILE内建包

在 MYSQL 存储过程中可以使用 UDF来操作文件

复杂的业务逻辑

复杂的业务逻辑可以转成JAVA代码

结论

迁移到MYSQL的收益时巨大的，同时自动化迁移也是经济实惠的。使用ZTO2M功能来简化迁移项目可以答复降低项目周期，提升转换质量。

所谓数据库迁移就是一个数据库到另一个数据库之间的任意形式的数据移动。

本文从热迁移和冷迁移的概念以及基本迁移流程简单分享一下：

一、数据库迁移主要分为热迁移和冷迁移：

1、热迁移是将内存数据和硬盘数据同步进行迁移。热迁移的优势在于其对用户业务的影响是非常小的；热迁移对内存数据进行了迁移，用户业务应用对其是无感知的。而缺点是热迁移的过程是不可中断的，整个操作过程相对复杂。

2、冷迁移就是在关机迁移。优势是整个冷迁移过程的操作简单，一般为自动化操作。但其缺点是该方式不支持内存数据的保存，容易导致内存数据的丢失。

二、数据库迁移关键流程

数据库迁移的工程按照进度可以划分为前期规划、中期实施和后期运维3个阶段，具体可以分为源数据库及应用系统调研、兼容性和风险评估、可行性验证、全面业务改造、全面业务测试、割接演练、迁移执行、业务验证、正式割接和护航保障10个关键环节，如下图

1、源数据库及应用系统调研：

源数据库及应用系统调研有助于后续深入评估改造点和工作量，有利于定位系统迁移过程中的难点和风险，其调研内容可以分为源数据库、应用系统、数据库和应用系统3个方面。 

（1）源数据库调研：需要考虑数据库结构、数据类型、数据库性能、数据使用场景4部分基础数据。数据库结构和数据类型是静态数据，可以通过语法、语义比对完成调研；数据库性能和数据使用场景是动态数据，与其对应的业务属性、数据库硬件资源、数据库自有能力、数据属性和应用系统属性直接相关。 

（2）应用系统调研：主要是发现应用和数据库之间的调用关系和调用方式，厘清应用各个模块与数据库调用SQL的兼容特点，明确应用在各个模块转换的改造点。通过调用SQL详情实现改造点定位，即交互SQL点定位。 

（3）数据库与应用系统调研：数据库与应用系统的关联关系通常包含但不限于数据复制链路、API结构调用等内容，其架构关系的梳理是迁移流程的重中之重，需要投入大量人力物力。掌握源数据库和应用的结构、架构、性能、关系拓扑，有助于后续决策。

2、兼容性和风险评估：

调研完成后，进入兼容性和风险评估环节。兼容性评估工作宜从结构语法分析、结构语义分析、上下文环境兼容分析几方面进行；风险评估工作主要包括目标库性能风险、数据一致性风险、应用改造风险、时间窗口风险和上线误操作风险五大方面。

3、可行性验证：

充分调研和评估后，迁移工程进入到可行性验证环节，即POC测试。其流程可划分为4个阶段：其一，选取业务中典型的交易模块，制定POC测试内容；其二，准备、部署POC测试环境；其三，根据POC预设，完成测试需求；其四，POC测试总结。针对数据库的特性，在可行性验证过程中需重点关注几个方面：其一，异常场景下事务是否一致；其二，异常场景下副本是否一致；其三，异常场景下大批量已提交事务回滚是否对系统有影响；其四，锁冲突较多的场景下是否对系统有影响；其五，副本数据的时延是否满足系统要求。验证结束后，需出具可行性验证报告，说明应用系统迁移至数据库是否可行，以及相关注意事项，为后续迁移工作打好基础。

4、全面业务改造：

改造工作繁琐，需要对业务逻辑、应用程序、源和目标数据库相关语法规则进行深入了解，为保证改造有效进行，宜遵循3个原则：其一，业务改造过程中需要谨慎地规划以及选取良好的方法，结合数据库产品自身技术特点，进行一系列数据库及应用程序的调整；其二，业务改造宜遵循从宏观到微观、从整体到局部、自顶向下的方式；其三，宜遵循先实现再调优的原则，性能调优需根据实际软硬件环境和业务场景，一次或者多次调整。

业务改造可以从几个方面依次进行：首先是数据类型，目标数据类型范围和精度应不小于源数据类型，以确保业务数据不会丢失，且目标数据类型范围和精度应避免超大于源数据类型，以免带来性能下降。其次是函数，改造场景可能会遇到函数同名，但在源数据库和目标数据库功能不同或不完全相同；函数同名，但参数隐式转换规则不同；函数同名，但参数个数或者参数类型不同；函数不同名，但功能相同；无对应函数，需通过其他方式实现。最后是语法规则，除了应当遵循ANSI或ISO的SQL标准语法，数据库方言的使用难以避免，因此需要将源数据库自身支持的语法规则调整为目标数据库的语法规则。

5、全面业务测试：

测试环节是迁移关键环节的重中之重，需要投入大量的时间和资源，稍有不慎，可能会导致后续的迁移失败、数据丢失甚至是业务中断、混乱的灾难性后果。全面业务测试通常包含功能测试、性能测试、稳定性测试、可靠性测试、扩展能力测试、安全能力测试、回退方案验证等。测试环节的典型测试类型及测试项如下：

6、割接演练：

割接演练是针对正式迁移前，模拟真实上线环境下，对系统进行的压力测试和破坏性测试，主要分为割接方案制定、压力测试和破坏性测试、测试总结、新旧系统同步互备和切换演练5部分。割接方案中应包含系统备份方案、应急预案、回退方案，明确割接的操作步骤、操作时间和操作人员，对新系统实施压力测试和破坏性测试，模拟在最极端环境下新系统功能的完整性、稳定性和高可靠性。正式割接前的备份工作必不可少，在新环境上线前务必做好旧程序包的保留和数据同步，以便在紧急情况可以快速回退。切换演练需制定切换检查清单，演练期间严密监控容灾数据库的系统负载、异常等待事件等内容。

7、迁移执行：

迁移执行宜按照最少改动的数据库结构和应用系统SQL代码；完整、准确的数据对象及数据迁移；最短的业务中断的原则进行，其包含的流程如图2所示。

迁移环境检测包含主机环境检测、网络环境检测和数据库环境检测。结构迁移是指将源数据库的建表语句迁移到目标端不同数据库中，迁移完成保证源、目标数据库中的建表语句功能、性能等价使用。数据迁移分为全量数据迁移和增量数据迁移。迁移结束环境确认需要重建序列、启用触发器和收集执行计划等。构建数据回流是为保证业务迁移后目标数据库切换为生产库出现故障无法持续对外提供业务时，保证目标端已经变化的数据能够迁移回流到原来的生产库，并保证业务不中断。 

8、业务验证：

业务验证分为迁移数据验证和业务功能验证。从源数据库导入到目标数据库中的历史数据文件可以按主键顺序进行组织，以文本文件的方式卸载迁移数据，并确保导出数据能够按照主键有序输出。对导入文件和导出文件分别进行比较操作，通过比对结果是否一致，完成迁移数据的一致性验证。业务功能验证分为运行过程比对、运行结果比对和静态数据比对。 

（1）运行过程比对：通过在原和新应用系统前端增加网络镜像分流设备，将发往原应用系统的网络数据镜像分流到新应用系统中，使用覆盖实际交易场景的大量生产数据进行连续测试。在运行过程中，解析目标、源数据库中的日志文件，根据流水号、主键、时间等唯一性标识，比对日志文件中新旧值的变化，找出异常过程，达到验证目标系统数据正确性与一致性目的。 

（2）运行结果比对：在原应用系统和新应用系统前端增加网络镜像分流设备，将发往原应用系统的网络数据镜像分流到新应用系统中，将目标、源数据库返回的结果信息保存到文件或数据库中，根据流水号、主键、时间等唯一性标识，比对目标、源数据库的交易结果。

（3）静态数据比对：根据源数据库的每日备份时间，在目标数据库做相同时刻的备份操作，备份完成后，将两份备份文件导入到比对库中，按表逐条比对两份数据一致性以及每张表的数据总量，验证目标系统数据的正确性与一致性。

9、正式割接：

割接前通常需要至少3次割接演练，以确保割接过程中各个环节没有疏漏，并根据不同业务系统情况制定割接流程，分配每个流程责任人，通关制完成各个环节。正式割接环节分为生产环境准备和按照割接方案正式执行割接两部分。 

10、护航保障：

迁移完成后，最危险的环节是切换后生产环境的第一个业务高峰，需要配置专业的数据库专家，快速响应应用和数据库出现的突发问题。之后，需要定期跟踪一定时间，以保障业务系统的稳定运行。最终的护航时间，需要根据实际情况确定。如果遇到突发情况，在无法处理的情况下，应依据回退方案和演练细则逐步完成回退。

上文就是小编为大家整理的数据库迁移 存储过程、包，触发器，脚本和应用程序,数据库的迁移

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。