随着Oracle数据库19c在去年的发布，越来越多之前的数据库版本走入其生命周期的末期。企业中原来应用甚广如Oracle 11gR2目前已经退出支持，只为某些特殊客户提供有限并且是付费式的技术支持。客户需要将老旧的数据库迁移到19c等较新版本的数据库来获得Oracle官方的支持。

另外，IT技术的发展使客户的IT架构逐步走向云化和微服务化。许多客户的采购部门已经开始停止采购IBM、EMC之类的国外的硬件设备，转而大量采购国产的x86架构甚至是ARM架构的PC服务器。这个变化也极大的推动了企业数据库迁移。

最后，Oracle 19c及前面版本中引入的许多新特性以及增强属性，例如12c中引入的cdb与pdb，19c中引入的自动化索引（Automatic indexing）等全新特性也吸引着企业逐步将老旧数据库升级迁移到新版本，以应用全新的数据库特性。

以上三个因素是企业Oracle数据库升级迁移的主要动力。

最近，我们协助了一个电信行业的客户将其核心系统的数据库，按不同的地市分三次迁移到Oracle 19c的数据库中。整个数据库迁移环境前后的对比如下：

因为涉及到核心系统数据库的迁移升级，客户从方案可靠性、数据一致性、停机时长以及迁移后数据库稳定性给我们提出了相应的要求：

因此，我们根据客户的实际环境情况、迁移需求，大致对常用的五种数据迁移方式进行评估和测试，包括：

• Datapump工具：使用数据泵工具完成源数据库数据的导出，并传输目标数据库，利用工具将数据导入，安全稳定。

• Rman备份和恢复：利用源数据库Rman的备份集在目标主机上进行数据库恢复，并apply归档日志实现数据完全恢复。

• DataGuard同步：源数据库与目标数据库之间实现DataGuard数据同步，在迁移完成后断开DataGuard同步，目标数据库升级为生产环境。

• GoldenGate同步：GoldenGate实现部分表或用户的数据逻辑同步，确认数据一致后将数据同步断开。

• XTTS：在可传输表空间实现数据初始化，并且通过增量数据备份和恢复实现数据同步。

下表是我们经过评估和测试后的对比：

结合实际迁移前后环境以及客户的迁移需求，我们分别排除了Rman、DataGuard、以及Data Pump三种方案，而最终选择使用GoldenGate的方案。为什么要使用GoldenGate来迁移呢？主要是考虑到以下因素：

首先，GoldenGate可以通过Datapump或Rman的方式提前将所需要的数据迁移到目标数据库，数据变化再通过GoldenGate实现秒级同步。应用停机后，只需要确认同步状态OK，断开GoldenGate同步，就完成了数据同步的动作，停机实际时间非常短。

其次，GoldenGate实际上是一种逻辑复制同步的方式，避免了物理复制以及Rman恢复等方式不能跨主机平台、操作系统以及数据库版本进行数据同步的问题。

考虑到停机时间、风险以及业务影响等因素，本次整个数据库升级迁移实际上分三次完成，每次迁移工程迁移该数据库中的部分地市用户（这些地市用户通过不同的schema加以区分）。因此，GoldenGate可以通过配置实现部分schema或者表数据的过滤，以此实现数据库中部署数据的实时同步。数据迁移同步更加灵活且可操作性更强。

最后，GoldenGate在客户的数据容灾应急等环境中应用广泛，因此我们技术团队在GoldenGate数据同步，在数据灾备、应急同步、数据迁移等场景下有较深厚的技术积累。

基本方案确定后，我们还需要制定具体的实施方案。俗话说：一根针不会两头尖。我们在GoldenGate带来迁移便利的同时，也需要考虑其带来的风险。

GoldenGate本质上是基本逻辑同步的方式，相对于Rman以及DG等物理同步的方案，可靠性有所不及。因此，一方面要扬长避短，实现数据最终一致性目标，调整实施方法实现多通道分散式同步；另一方面，在同步过程中验证测试+实时检查保障数据同步和时延。

所以整个实施过程我们大致划分为四个阶段：

前期准备是整个实施的关键一环，好的前期准备工作是整个数据库升级迁移的实施保证。前期准备的工作除了基本设备的安装以外，我们重点要做好以下几项工作：

首先是数据库的测试，应用RAT等自动化测试工具以及应用联调等人工测试手段联合，有效地释放由于数据库版本升级以及硬件平台改变所引入的风险。例如：参数设置、新特点、SQL执行计划、性能等等可能引起升级前后重大问题。在数据迁移前，想方设法将这些问题加以解决。

另一项关注的重点是数据同步范围的梳理及规划。仔细梳理待迁移数据，按照数据的重要程度、业务关联度、数据量的大小以及数据变化量，以表为单位对数据进行分门别类，并且以此为基础做出OGG数据同步通道的初步规划。

一般可参考的原则是，将小表和修改频率较小表的抱团处理，将大表和数据变化频率较大的表作单独通道处理。这样做带来的好处是：一方面，分散数据同步的压力，降低数据时延；另一方面，即使偶发性因素导致数据同步失败或者数据不一致，也可以按通道重新初始化数据，避免全量数据的重新初始化。

此外，值得特别注意的是并非所有数据类型OGG都可以支持，部分数据类型不能同步或存在一些限制。尽管这些数据类型通常不太常用，但是我们在进行数据梳理的时候要对这些限制类型进行小心判别。

数据初始化是一个操作密集型的步骤，一般而言我们会视乎数据初始化的数据量在正式割接前2-3天完成数据初始化。尽早完成数据初始化并拉起OGG的数据同步，可以让我们有充足的时间进行异常问题处理，有利于工程的顺利开展。

OGG数据初始化以后，我们在割接前需要持续监控和优化数据同步通道。

监控的内容主要会涉及到：

此外，在这个阶段我们通常还会针对一些静态表和配置表进行全量的数据核对，降低实际割接时数据核对的工作量和时间。

数据割接是应用停机后，停止OGG所有同步链路和确认数据同步完成，将目标数据库正式启用为新生产环境的过程。在这个过程中，大致会分为四个步骤：

每个步骤会涉及多个操作及检查点，并且由于数据割接通常是在深夜（至少是晚上10点以后）才启动，因此我们非常强调操作的准确性，一般的原则是：

另外，作为数据迁移项目，我们还需要保障的是数据的准确性。为此，我们一般会开发一些专门的脚本和工具进行前后数据的稽核和对比。对比的范围包括数据对象的核对、数据结构（字段、类型、长度等）的核对、数据总量（记录行数）的核对以及实际数据记录的核对。实际工作中，全量数据记录我们一般采取主键+数据MD5值的方法进行对比。这种方式可以极大地降低数据对比的时长和实际资源开销。

当然即使预留了一定数据稽核时间（一般为1小时内）以及采取MD5方法，实现全量几十TB数据稽核也不太现实。因此我们需要做出一些取舍，以我们这次迁移为例：

一方面，许多数据质量的校验和稽核工作可以与其他过程和操作并行，这样可以充分利用时间。例如由于我们整个迁移工程中有Oracle TT cache group重建的步骤,此时，数据库还没有业务接入，我们可以利用这段时间做好核心数据的稽核工作。

另一方面，数据质量校验还需要根据数据的重要情况做出一致性稽核取舍。我们一般会对整体数据进行分类，如基本处于的静态数据（如大部分的配置数据、产品定义等）之类，我们是在迁移前已经进行了校验，只会监控是否有数据变更就OK。如核心的业务数据，则会利用迁移后进行全量的校验。如类似于不重要的过程数据，则只会进行记录数量以及抽样的校验就好了。

最后，我们会跟甲方进行有效沟通，根据测试的情况、风险等级、停机时长等因素确定最终的数据稽核方案。

历时一个月分三次工程，我们将该省级电信运营商的核心系统数据库迁移到Oracle 19c上。数据库运行至今非常稳定，并且数据库的性能也得到不少提升。

当然，我们后面也将会面临一些全新的问题需要做出应对，包括像一些巨无霸级别的地市，迁移方案估计需要做出一定的调整和修订，这些也将是我们未来的重大考验。但是尽管如此，我们对本次Oracle 19c的升级迁移总结为以下几点：

​