1.1 DB migration analysis
在从Oracle向EDB迁移数据之前，须要做非常多准备工作。比方须要分析源数据库数据量大小、数据是否稳定、异构数据库兼容、编码方式、业务逻辑（存储过程、函数、触发器）等迁移情况，最好在迁移实施之前出一个迁移方案；选择迁移工具实施数据迁移。保存迁移日志；迁移完毕后还须要验证数据的完整性、一致性等，记录条数检查，检查新旧数据库相应的记录条数是否一致。特殊样本数据的检查，检查同一样本在新旧数据库中是否一致。
迁移数据库源为ORACLE,目标数据库为EDB；迁移工具：navicat premium11；源数据库共149张表，本次迁移仅仅迁移64张表，因为本次迁移数据量不大，採取一次迁移（结构和数据）方式；使用Postgres Enterprise Manager工具创建EDB目标数据库；迁移完毕后随机抽取2个样本进行迁移结果校验。
1.2 DB migration preparation
创建目标数据库：
打开Postgres Enterprise Manager工具。例如以下图1.1所看到的。
图1.1
打开刚加入的server。创建目标数据库登陆用户test。例如以下图1.2和1.3所看到的。 
图1.2
图1.3
对着Databases右键打开创建数据库对话框，例如以下图1.4所看到的，在Properties选项卡中填入目标数据库名test并选择上一步创建的登陆用户test；然后切换到Definition选项卡。填写数据库相关属性，当中“connection limit”默认就可以，最后点击OK，例如以下图1.5所看到的。
图1.4
图1.5
在目标数据库中创建SCHEMA。打开上一步建好的数据库test(同源数据库schema)。然后右键Schemas选择New Schema,填写schema name并选择owner。例如以下图1.6和图1.7所看到的。
图1.6
图1.7
到此。目标数据库已经创建好。
1.3 DB migration Implementation
本次迁移工具选择navicat premium。打开navicat premium。然后分别连接迁移源数据库和目标数据库。
Navicat Premium 是一个可多重连接的数据库管理工具。它可让你以单一程序同時连接到 MySQL、SQLite、Oracle 及 PostgreSQL数据库，让管理不同类型的数据库更加方便。最重要的是它不用装Oracleclient。
假设不是必要，无需安装 Oracle client。占用空间大。有500M左右。装完后非常难卸载干净。依据 Navicat 官方的文档。事实上仅仅须要下载 Oracle 的 Instance Client就可以，具体方案能够在百度中搜索“Navicat Premium oci”。
连接源数据库，例如以下图1.8所看到的。
图1.8
连接目标数据库，例如以下图1.9所看到的，打开目标数据库test，然后打开schema。刷新一下表、视图等，确认表、视图等以下的对象为空，例如以下图1.10所看到的。
图1.9
图1.10
在navicat premium的菜单条中点击工具，选择传输数据。打开传输数据对话框，在常规选项卡中填写迁移数据库信息并选择迁移对象，例如以下图1.11所看到的；然后打开高级选项卡设置迁移详情（迁移数据/迁移表结构/同一时候迁移数据和结构），例如以下图1.12所看到的。设置完后点击“開始”就可以。
图1.11
图1.12
迁移完毕后。信息日志中的时间不再发生变化。能够看到本次迁移共花费时间237.914s，例如以下图1.13所看到的。
图1.13
1.4 DB migration verification
本次迁移验证选取首尾两张表做为样本，进行正确性、完整性验证。源数据库中的RI_ABANDON_INFO表概要信息例如以下图1.14所看到的，迁移目标数据库中的ri_abandon_info表表概要信息例如以下图1.15所看到的，经过对照能够觉得该表数据迁移没有问题。
图1.14
图1.15
在源数据库中对表RI_ABANDON_INFO右键，选择设计表。例如以下图1.16所看到的，相同操作目标数据库中的ri_abandon_info表。例如以下图1.17所看到的，通过对照两个表对象的约束（主、外键）、索引等信息，确定该表表结构迁移没有问题。
图1.16
图1.17
用相同的方式验证源数据库中的RI_TKSU_WHITE_LIST_HIS表和目标数据库中的ri_tksu_white_list_his表，确定被验证表的表结构和数据迁移没有问题。
1.5 DB migration results
经过对样本的验证对照，基本确认本次数据库迁移成功。