核心系统 Oracle 19c 数据库迁移方式对比与实践【转载】

迁移背景

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

 

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

 

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

 

 

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

 

方案选择

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

 

源数据库主机平台：IBM 小型机（PowerPC 架构）

 

源库操作系统：AIX

 

源库版本：11.2.0.4

 

数据库节点数：2

 

目标数据库主机平台：某国产数据库一体机（x86 架构）

 

目标库操作系统：Redhat 7

 

目标库版本：19.7

 

数据库节点数：6

 

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

 

  • 可靠性：迁移方案成熟可靠，迁移效率高且风险可控；

  • 数据一致：迁移前后数据需要保持高度一致；

  • 停机时长：包括应用启停在内的停机维护窗口控制在 8-10 小时，能在晚上 10 时开始，次日 8 点前完成所有操作；

  • 稳定性：数据库迁移后要保持数据库性能和稳定性。

 

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

 

  • 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 等物理同步的方案，可靠性有所不及。因此，一方面要扬长避短，实现数据最终一致性目标，调整实施方法实现多通道分散式同步；另一方面，在同步过程中验证测试+实时检查保障数据同步和时延。

 

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

 

1、前期准备

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

 

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

 

 

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

 

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

 

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

 

2、数据初始化

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

 

 

3、监控与优化

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

 

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

 

  • 同步进程的状态

  • 同步数据的时延

  • 源库以及目标库的数据库监控

  • 源库和目标主机的资源开销

  • ……

 

依照监控的结果，我们会重新调整 OGG 同步通道。例如，将一个变化量比较大且数据量大表从现有的 OGG 同步通道分离出来，独立成为一个同步通道降低整体同步数据时延。

 

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

 

4、数据割接

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

 

 

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

 

  • 复杂的操作过程，通过自动化脚本处理，保证高效、准确！

  • 验证后的割接方案细化到指令级别，每一条指令均责任到人！

  • 采用 Double Check 机制，保证执行到位，如有异常及时通报。

 

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

 

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

 

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

 

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

 

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

 

实施总结

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

 

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

 

  • 良好的前期准备和规划是项目成功的一半；

  • 善用同步工具，将迁移提早完成；

  • 监控与不断优化数据同步通道；

  • 割接操作保持傻瓜化，双人检查尤为必要；

  • 有效的数据稽核确保数据一致性；

  • 谨慎，谨慎，再谨慎！

 

Q&A

 

Q1：Oracle 9i 支持 OGG 吗？

 

A： 9i 是支持的，但需要旧版本的 OGG，这个估计要 mos 申请介质。最新两个 OGG 版本具体的数据库版本支持可以参考官方链接下载支持列表：https://www.oracle.com/middleware/technologies/fusion-certification.html

 

值得注意的是，每种数据库 OGG 支持的范围有所差异，有的版本只能作为同步的目标端（delivery），有的数据库源端和目标端均支持，有的数据库可以支持 DDL 操作。请各位使用前先确认一下。

 

Q2：用 OGG 同步数据支撑业务场景有什么限制因素？

 

A：主要的限制因素我认为如下：

 

  1. 数据库的日志，需要打开归档、附加日志等；

  2. 部分数据类型和数据对像的限制，如 Oracle 数据库里面的临时表、物化视图；

  3. 同步的数据表最好有主键；

  4. 数据库大事务以及网络带宽等带来的数据时延；

  5. 数据库日志分析和过滤带来的数据库的额外资源开销；

  6. 逻辑数据复制有可能会带来数据不一致，需要额外关注数据一致性稽核。

 

Q3：数据是如何稽核的？

 

A： 我们一般数据稽核会从以下的维度来测量：

 

  • 数据对像的一致性；

  • 数据结构的一致性；

  • 数据记录数量的一致性；

  • 具体数据记录的一致性。

 

Q4：TT 重建怎么理解？

 

A：当时讲解的时候可能有点口误，实际应该是 TT cache group 的重建。TT 是 Oracle 的一种内存库产品，cache group 是一种 Oracle 物理库（也就是我们现在的 19c）和内存库的一种数据同步机制。重建 TT cache group 的目的是将内存库所需要的数据从物理库装载到内存库中并实现数据库之间的实时同步。

 

Q5：迁移完成后会和预期方案进行比较和评估吗？

 

A：事后的方案复盘是我们实施类似重大工程时必须做的。我们在每次迁移测试和实施，都会在 checklist 机制中记录所有操作以及检查点的时长、实施效果、检查问题等关键要素，并对迁移过程进行全程复盘。通过对方案进行各方面的比较和评估，我们会找到需要优化的细节点，并讨论进一步具体的优化方案，以利于后续工程的开展。

 

作者介绍：

 

梁铭图，新炬网络首席架构师

 

    • 十余年数据库运维、数据库设计、数据治理以及系统规划建设经验，拥有 Oracle OCM 和 ACE Director、Togaf 企业架构师（鉴定级）、IBM CATE 等认证，曾获 dbaplus 年度 MVP、华为云 MVP 等荣誉，并参与数据资产管理国家标准的编写工作。

    • 在数据库运维管理和架构设计、运维体系规划、数据资产管理方面有深入研究。

posted @ 2021-07-02 11:32  雪竹子  阅读(882)  评论(0)  编辑  收藏  举报