刘娟

摘要：在实践中，一般将容量超过1T的数据库，称之为超大型数据库。在运营过程中，经常会遇到不同的需求，需要对这类数据库的数据进行迁移，该文根据日常运营实践，总结了对Oracle超大型数据库数据采用逻辑迁移的解决方案。

关键词：数据库；逻辑；迁移；数据泵

中图分类号：TP391 文献标识码：A 文章编号：1009-3044（2016）30-0007-02

通信企业为了支撑业务发展和企业日常管理的需要，建设了规模庞大的IT系统。为了保障IT系统的长期稳定高效的运转，在日常运营过程中，常常会遇到服务器硬件升级扩容、系统软件升级等需求。为了完成这些需求，通常会对数据进行迁移，需要迁移的数据规模从几百G到超过10T。在长期的运营实践中，作者总结了一套完善、成熟的数据迁移方法论，通过该方法论，成功完成了大量系统的数据迁移，累计实现数据迁移规模超过100T，有效的支撐了系统稳定高效的运转。

1 不同迁移方法的对比

数据迁移通常可以采用物理和逻辑两种不同的方法，两种方法的对比见表1。

随着x86硬件平台的性能提高和成熟、Linux系统的稳定、以及基于x86平台虚拟化技术的发展，将会越来越多地出现将数据从小型机平台迁移到x86平台的需求，在这种情况下，逻辑迁移是最常用的一种迁移方法。本文重点讨论逻辑迁移的方法。

2 数据迁移准备工作

迁移前期需要完成的准备工作主要包括以下内容：目标主机数据库软件的安装、创建数据库、创建表空间以及下面的检查工作（注意目标数据库在迁移完成之前需要置为非归档模式）。

3 详细迁移步骤

为了减少逻辑迁移过程中的系统停机时间，需要对数据先进行分类，部分历史或者静态数据在正式迁移前先行导入到目标数据库中，尽量缩小正式迁移过程中的数据量。

10g以前的版本由于无数据泵技术，所以分两种情况讨论。

3.1 Oracle 9i（包括9i）之前版本数据迁移

Oracle 9i（包括9i）之前版本数据迁移采用Export/Import+DB Link方式，主要步骤为先利用Export/Import导出、导入用户元数据，再采用DB Link方式插入数据。不直接采用Import导入数据，主要原因是Import是串行执行，且如果中途报错，导入过程要整体回退，不容易掌控导入的进度；而采用数据库链接插入数据的方式则可以避免这些问题。

1） 在目标库上设置参数job_queue_processes为0，暂停目标数据库job的执行。

2） 比照源数据库，在目标数据库上创建用户、角色和profile，并将相关权限授予角色和用户。

3） 在源库上批量生成需要迁移的用户元数据导出脚本。

4） 在源库上批量生成目标库导入用户元数据的脚本。导入后，注意需要更新JOB$表来更正JOB导入的问题。

5） 检查对象总数、无效对象。首先在目标库上执行无效对象编译的脚本：@？/rdbms/admin/utlrp.sql然后对比目标库和源库的迁移用户的对象总数、无效对象数，是否有遗漏和不一致，在进行针对性的补充。

6） 通过数据库链接插入数据。关闭应用，在源库上设置job_processes=0停止所有JOB运行，在源库上创建一个端口号为1526的监听，停掉原来的端口号为1521的监听，避免有应用连接；插入数据前，再次确认表上是否有触发器，如果有，做好记录后将其删除。

7） 利用第三方工具，产生序列创建脚本，并传输到目标库上直接执行。

8） 利用第三方工具，产生索引创建脚本，并对脚本进行修改，增加nologging、parallel选项，加快索引创建速度，并传输到目标库上直接执行，执行完毕后，再取消并行，恢复logging模式。

9） 利用第三方工具，产生约束创建脚本，并传输到目标库上直接执行，注意主键和外键分开执行，先创建主键约束，再创建外键约束，两者不能同时执行。

10） 利用第三方工具，产生触发器创建脚本，并传输到目标库上直接执行。

11） 收集相关统计信息。

3.2 Oracle 10g之后版本数据迁移

在Oracle 10g以后的版本，由于数据泵技术的出现，可以直接在数据泵中使用并行，可以简化迁移的步骤。

1） 设置参数job_queue_processes为0，暂停新旧数据库job的执行。

2） 使用IMPDP直接按照用户迁移数据。

使用数据泵，采用DB Link的方式，开启并行迁移数据，如果一个用户数据量特别大，尤其是有特别大的表，可以将该表排除，或者将一个用户的表分割成多个IMPDP脚本执行：

impdp system/**** network_link=dl_old_db schemas=testuser directory=dir1 parallel=4 logfile=testuser.log

3） 按用户迁移数据完毕后检查用户的对象权限、角色权限是否有缺失，并进行补充。

4） 检查表和索引是否开启了并行，如果有进行关闭。

5） 编译失效对象。

6） 检查是否有失效的组件。

7） 恢复job参数。

8） 收集统计信息。

3.3 数据迁移的后续操作

应用启动后，标志着整个迁移工作已经完成绝大部分。但是仍然有以下几个重要步骤需要完成。

1） 调整JOB定时任务。

根据业务需要，某些定时任务只能在特定时间启动，可能需要调整定时任务的启动时间。

2） 复制脚本以及创建cron任务。

将源库上的以cron方式调用的定时任务以及相应的脚本复制到目标库主机上。

3） 对数据库进行备份。

将目标库设置为归档模式，在目标库安装备份软件，对数据库进行备份。

4） 如果数据库使用了GoldenGate等第三方复制软件，需要在目标库上重新配置。

4 迁移测试及回退

由于迁移操作步骤较多，操作较复杂，必须进行测试和演练，确保方案可行，保证能够在既定的停机时间内完成迁移。

由于迁移过程不影响源生产库。因此，可以按本方案，将所有的操作进行一次演练。 除了应用切换之外，其他步骤均可进行测试和演练。

如果在正式迁移时，发生不能修复的并且严重影响迁移的问题，需要切换回原生产库，根据不同的情况进行相应的操作：

l 如果应用没有启动，因为没有对原生产库做任何改动，那么不需要做任何其他的步骤，直接启动应用，保持现状即可。

l 如果应用已经启动，则需要将应用切换回原生产库。并将在目标库上发生的新的业务数据改动应用到原生产库中。为了避免数据改动过大，建议应用启动和测试时分步进行，首先进行查询型的业务操作测试，避免事务型的业务操作。

5 迁移方法总结

对超大型数据库的数据迁移采用逻辑方式，不论是采用Export/Import、数据库链接还是采用数据泵，都需要重点考虑以下几个问题：

l 要迁移的数据量有多少？

l 是否能够按照历史/静态数据、动态数据对数据进行分类？是否能对部分垃圾或者历史数据进行清理？

l 迁移过程中使用的网络带宽是100M还是1000M？这个因素直接影响迁移的速度。

l 迁移的数据表上索引、约束、触发器的数量？

l 业务最长停机时间是多少？

对迁移方案和过程的选择，要充分考虑以上因素，尽量缩短数据迁移的时间，对创建索引和约束要留够充足的时间，并对准备好的迁移方案在测试环境进行充分的测试和验证，如果涉及版本的升级，还需要对应用进行兼容性的测试，在确保稳妥可靠以后，再进行正式的数据迁移。