用数据泵迁移数据

笔者单位新购置了数据库服务器，为了便于管理、维护和节约成本的考虑，需要对数据库按功能以及服务级别进行整合。但部分数据库实时性要求时间性特别强，数据迁移工作给笔者带来不小的挑战。

为了尽快完成数据库迁移并尽量减少服务终止时间，我们使用了Oracle数据库提供的数据泵（DATA PUMP）工具对生产数据库进行迁移。

环境：

操作系统：AIX7.1

数据库：Oracle 12.0.4

迁移工具：DataPump

迁移数据库表空间：DZGWZDTB、DZGWDOCZDTB

前期准备：

对于一个生产系统来说，一旦投入使用，应用数据持续产生和变化将是必然。对于系统的切换以及更新，需要很好的工程化方法，也需要多个应用业务部门的协调和沟通。因为数据彼此的关联性已经有驱动力效应，导致越来越多的系统集成后，某些局部故障引发的蝴蝶效应。

因此，不论是既有系统更新或是新建系统上线与既有系统的整合都需要很好的部门间协调和共同努力来应对可能的问题和挑战。

对业务及数据流的梳理是前期准备工作的重要方面。切换前的实验以及切换时间的确定需要组织级决策。实验的目的是输出良好的自动化脚本，减少切换时间内人为错误的发生带来的服务终止时间延续，避免因为切换带来的灾难性后果。同时，可以通过实验进行良好的切换时间推算和预算，为组织级决策提供有效依据。

测试中发现使用数据泵进行数据导出导入时，对视图、同义词以及过程等没有存放在表空间的用户元数据需要进行特定步逐来进行，否则会导致这部分没有存放在表空间的用户元数据消失，导致应用系统及程序出错。

切换实施过程:

1.源数据库表空间导出操作

第一步，创建DIRECTORY，我们可以把DIRECTORY变量理解为EXPDP或者IMPDP导出、导入数据泵的工作目录，它将dump文件、log文件以及SQL文件保存在其中。数据泵要求将目录路径作为一个目录对象，创建过程如下所示：

这样我们就可以在随后的数据导出中使用该目录对象进行数据导出。

使用ALL_DIRECTORIES视图查看刚刚创建成功的DIRECTORY对 象，SELECT语句如下所示：

第二步，对用户进行授权操作，对目录对象的READ或WRITE权限仅仅表示Oracle将会替你读写这个文件。

你并没有访问Oracle以外文件的权限，因此使用AIX系统进行数据泵导入导出时，也需要检查文件系统指定目录权限。操作命令如下：

然后需要在操作系统中使用命令创建指定目录，并进行用户、属组以及权限修改。

第三步，进行待导出表空间严格自包含检查，导出没有存放在表空间的用户元数据（视图、同义词、过程等），并将该表空间修改为只读，执行语句如下所示：

出现no rows selected后继续执行以下的语句，先行导出没有存放在表空间的用户元数据（视图、同义词、过程等），执行语句如下所示：

然后执行表空间修改为只读属性语句，执行语句如下：

第四步，执行表空间的用户元数据导出命令，执行语句如下：

完成后系统将在目录“/data/tmp/dzgw”中生成dzgwzd2017.dmp。

2.源、目标节点数据传输

在进行完数据导出操作后，用户需要将产生的DMP文件以及表空间对应的数据文件按照实际情况定义的目标文件目录一同传输到目标数据库所在主机。

这里基本就是按照规划好的目录结构进行数据复制，用户可以根据自己喜欢的方式选择具体工具进行文件传输。

生产系统中我们还是使用了工程化方法，保证两台数据库节点DMP文件及表空间文件目录名称统一，这样将减少因此带来的不必要的细节干扰。

两个节点上数据库中数据文件目录统一设置为/data/oradata/ORAXA/datafile/，数据泵使用的DIRECTORY目录统一设置为/data/tmp/dzgw。

3.目标数据库表空间导入操作

第一步，按照在源数据库中创建DIRECTORY及授权操作的方法在目标数据库中创建数据泵工具需要的基础配置。

第二步，目标数据库创建对应Oracle用户并进行授权操作

根据源数据库Oracle用户信息，在目标数据库中创建该用户，执行命令内容如下：

用户创建完成后继续执行用户授权操作，执行命令如下：

第三步，执行数据泵导入命令导入用户元数据，内容如下：

导入没有存放在表空间的用户元数据（视图、同义词、过程等），执行语句如下所示：

第四步，将用户默认表空间指向导入表空间，执行命令内容如下：

继续执行命令进行表空间状态查询，执行命令内容如下：

此时新导入表空间状态应该为”READ ONLY”状态。

第五步，将表空间置为可读写状态，完成整个表空间的迁移任务。

使用命令修改表空间为可读写状态，执行命令如下：

至此数据库迁移工作完成，可以进入应用测试和业务倒切恢复。

写在最后

此次实际生产系统数据库使用中对一个近80GB的数据库进行迁移用时2.5小时，和传统的EXPORT和IMPORT相比缩短近8小时，大大提高了数据库迁移的时效性，有效的减少了服务终止时间。

基本对业务应用用户没有带来影响，同时在测试中发现和解决了数据泵在导入过程中出现的表视图、同义词以及过程消失带来的应用系统错误问题并进行了问题解决，避免了生产系统中数据库迁移过程中可能出现的隐性问题。