将关键业务应用迁移至亚马逊 RDS for Oracle

作者 Raymond Lai 和 Alvin Liu日期 2023年11月9日类别 高级 (300) 客户解决方案 RDS for Oracle永久链接 评论区 在此发表评论

关键要点

亚马逊关系数据库服务Amazon RDSfor Oracle 是一款完全托管的商业数据库，让在云中设置、操作和扩展 Oracle 部署变得简单。在本文中，我们分享了一则关于业务关键应用的数据库迁移故事，该应用由客户从位于 Oracle SuperCluster 的重要数据库实例迁移至 Amazon RDS for Oracle，使用了多可用区 (MultiAZ)的功能。我们讲述了项目的不同阶段，从规划与架构到迁移关键应用，分享了所面临的挑战以及他们在迁移过程中如何克服这些问题。最后，我们讨论了一些在 Amazon RDS for Oracle 上运行关键应用的最佳实践和建议，包括在最小停机时间内运行例行操作的细节。

背景及Oracle迁移项目的倡议

Oracle SuperCluster 是一款工程化系统，配备 Exadata 特性，旨在一起运行多个高性能的 Oracle 数据库工作负载。然而，这种方法带来了业务敏捷性挑战，因为每个工作负载可能需要不同的数据库引擎，而 Exadata 的专有特性可能会导致企业被锁定。此外，Oracle SuperCluster 的总拥有成本 (TCO) 可能很高，因为其依赖于 Oracle 进行硬件部署、维护和支持。

随着客户决定转向采用云服务，他们希望用微服务替代单体软件架构，以提高敏捷性和创新性，降低复杂性。然而，每个服务的具体数据需求不同，增长速度也有所差异，而他们被迫使用相同的数据库引擎。采用单一大型的单体数据库引擎来满足所有服务的需求，严重阻碍了开发人员的灵活性和敏捷性。

因此，客户决定从 Oracle SuperCluster 迁移至各种 AWS 完全托管的数据库引擎，例如 Amazon RDS for Oracle、Amazon RDS for MySQL 和 Amazon RDS for PostgreSQL。这种做法提供了更大的灵活性和敏捷性，因为他们可以选择最适合每个应用的数据库引擎。同时也减少了锁定挑战和 TCO，因为 AWS 的完全管数据库不依赖专有硬件，并提供更丰富的部署和定价选项。

收集有关 Oracle AWR 的特定数据库实例的数据

对于大规模数据库的迁移，根据现有的 Oracle 本地数据库对 RDS 实例进行正确调整非常重要。可以通过两种方式获取所需信息以规划实例的规模。

生成 AWR 报告

为了了解本地 DB 实例的工作负载，我们使用 SQL 脚本从 Oracle 的自动工作负载库AWR中提取数据库性能指标，例如 I/O 相关指标、共享池利用率、PGA 使用情况和其他相关指标。这些脚本可以为在 Oracle SuperCluster 上运行的特定 DB 实例生成 AWR 报告。

可以在不同的时间段内收集 AWR 报告，以表示峰值和平均加载统计数据。在我们的案例研究中，源数据库在一个 Oracle RAC 环境中运行。因此，我们首先运行以下 SQL 命令获取实例编号，以便在过去 24 小时内为指定实例编号生成 AWR 报告。为了从 AWR 报告中提取准确的数据，建议在生产的高负载期间运行该报告，并尽量减少强烈的维护操作，如 RMAN 备份。

sqlSELECT INSTANCENUMBER FROM VINSTANCE

切换到 SYS 用户并使用以下 PL/SQL 脚本生成 AWR 报告：

DECLARE dbid NUMBER instnum NUMBER dbname VARCHAR2(50)BEGIN SELECT DBID INSTANCENUMBER DBNAME INTO dbid instnum dbname FROM VDATABASE DBMSWORKLOADREPOSITORYCREATESNAPSHOT(instnum dbid SYSDATE1 SYSDATE)END/

运行以下命令以生成 HTML 格式的 AWR 报告：

sqlSELECT FROM TABLE(DBMSWORKLOADREPOSITORYAWRREPORTHTML(INSTNUM DBID SYSDATE1 SYSDATE 0))

注意，您需要有效的 Oracle 数据库企业版许可证和诊断与调优包。作为替代方案，您可以考虑使用 Oracle Statspack 来监控数据库性能，而无需此许可证。

下载 AWR 报告并根据 CPU、SGA 和 I/O 配置信息审查实例大小。

作为替代方案，您可以参考 根据 Oracle 性能指标进行大规模的 Amazon RDS 实例调整 以获取有关如何使用 Python 和 SQL 脚本收集本地 Oracle 数据库的性能工作负载的更多信息。

解释 AWR 报告中提取的关键信息以进行合理划分

Oracle SuperCluster 使用的是 SPARC M7 处理器，而 RDS 使用的是 Intel x86 或 AWS Graviton。为了找到 Amazon RDS for Oracle 上 vCPU 的数量以便映射到 SPARC M7 环境的使用情况，我们使用了 x86 CPU 线程映射比率，这是由 SPEC 进行性能基准测试的结果。以下表格总结了我们的结果：

根据报告 SPEC CPU2017 整数率结果 在 SPARC M7 上，其有 32 核心 8 线程/核心 = 256 总线程，SPECintratebase2017 = 114。其每线程得分为 114/256 = 044531。类似的，从报告 SPEC CPU2017 整数率结果 中的 Intel Xeon Platinum 8158与 RDS for Oracle r5 实例系列相似，其有 48 核心 2 线程/核心 = 96 总线，SPECintratebase2017 = 304。其每线程得分为 304/96 = 31667。它们的 CPU 线程映射比率 = 31667/044531 = 71。这意味着我们需要 71 个 SPARC M7 线程才能对 1 个 x86 线程在 RDS for Oracle 实例上产生相同的基准贡献。

接下来，我们检查了 AWR 报告中的 OS 统计信息按实例 部分。我们注意到，DB 实例分配了 12 个 CPU 核心，最大支持 96 个线程。通过使用 CPU 线程映射比率，我们需要 96 线程/71 = 135 线程来完成相同的任务。因此至少需要 r54xlarge 实例，该实例支持 16 个 vCPU 和启用超线程。

接着，我们审查了 Oracle 实例中分配给 SGA系统全局区和 PGA程序全局区的内存。在我们的示例中，这些值的设置为 pgaaggregatetarget 为 215 GB，sgatarget 为 644 GB。我们可以解释为 Oracle SuperCluster 为该 DB 实例分配了 86 GB 的内存。

为了谨慎起见，我们进一步验证了提议的 RDS for Oracle 实例是否能满足以下指南。目的是确认 RDS for Oracle 实例的总内存应适合 SGA PGA，并带有额外的缓冲区：

根据这些条件，我们建议的 RDS for Oracle 实例应该至少为 256 GB 内存，这样其 3/4 的值为 192 GB大于 644 GB 的 sgatarget，而其 1/8 的值为 32 GB大于 215 GB 的 pgaaggregatetarget。

最后，我们根据 I/O 配置查看读写 IOPS。在我们的案例中，它记录了 2025 IOPS/秒1813212的快照期。我们需要选择一个能够处理此 I/O 吞吐量要求的实例大小。

RDS for Oracle 实例的 IOPS 和吞吐量能力取决于实例类别和大小以及存储配置。

选择 RDS for Oracle 实例配置时，请务必确保能够满足工作负载在 亚马逊弹性计算云 (Amazon EC2) 实例级别 和 存储层 的 I/O 和吞吐量要求。

总之，我们决定根据我们的研究，从 RDS for Oracle r58xlarge 实例开始，其配备 32 个 vCPU、256 GiB 内存、20000 GiB gp2 EBS。这一实例能够提供 16000 IOPS 的基线性能，最大可达到 6800 Mbps 的 EBS 带宽，满足原 Oracle DB 实例 2025 IOPS 及 7253 MBps 或 58024 Mbps 的数据库读写操作性能需求。

体系结构及迁移方法

关键业务应用需要高可用性和容错能力，以减少停机及服务中断。Amazon RDS 的多可用区 (MultiAZ) 功能在两个可用区之间复制数据库更新，以提高耐用性和可用性。亚马逊 RDS 会在计划维护和意外中断时自动切换到备用实例。对于某些在维护期间不能容忍停机的 Amazon RDS for Oracle 应用，我们可以考虑使用 AWS 数据库迁移服务 (AWS DMS) 作为逻辑复制工具，以模拟 在升级期间尽量减少停机的蓝绿部署。

除了 MultiAZ 设计外，我们还可以选择使用 RDS for Oracle 副本以卸载只读任务并提高容错能力。Oracle 副本数据库是主数据库的物理副本。有两种类型的 RDS for Oracle 副本。在只读模式下的 Oracle 副本称为只读副本。在挂载模式下的 Oracle 副本称为挂载副本。挂载副本和只读副本都需要企业版许可。此外，您还必须拥有活动数据保护许可才能支持只读副本。

初始数据加载迁移

在此次 Oracle SuperCluster 迁移中，我们面临的挑战之一是处理一个源数据库实例，数据库大小为 20 TB，包含大型表以及每日写入事务量可达 50 MB 每秒或 4 TB 每天。迁移工作将使用 AWS DMS 进行初始数据复制。接下来，我们利用 AWS DMS 的变更数据捕获 (CDC) 进行持续数据同步，以跟踪迁移期间源数据库的变化。在对 20 TB 的大型表进行初始数据迁移时，AWS DMS 数据迁移任务可能需耗时数天才能完成。由于源数据库在初始加载过程中仍然开放以供读写活动，因此其持续时间较长。除了 AWS DMS 使用的方式外，还有 通过 RMAN 可迁移表空间 进行初始数据迁移的另一种方法。您可以使用 Oracle RMAN XTTS 将一组表空间迁移至 Amazon RDS for Oracle，从而简化大量数据的迁移并加快迁移过程。

尽管在我们的迁移项目中未能使用 RMAN XTTS 解决方案，但我们顺利实施了 AWS DMS 的初始加载方法，证明这是执行全面加载的可靠解决方案。然而，需要指出的是，RMAN XTTS 解决方案带来的潜在优点和优势，比起未来的完整加载要求，它无疑是一个极佳的替代方案。

并行运行

对于关键业务系统，客户通常会在现有和新环境上执行并行运行，以验证迁移后新系统的功能和数据完整性。在我们的迁移中，Oracle SuperCluster 和 Amazon RDS for Oracle 上的数据库需要并行运行 3 周，以支持应用。在这 3 周里，应用将写入操作发送到 Oracle SuperCluster 和 RDS for Oracle 数据库。读取操作则由 SuperCluster 提供。如果在本地和 RDS 数据库之间出现性能或数据完整性问题，则整个数据库迁移工作流程将从头开始。

如果我们需要重新启动数据库迁移工作流程，则需要对新的 RDS for Oracle 实例重新执行 AWS DMS 初始数据加载。这对我们的案例来说将非常耗时。因此，为了更有效地促进我们的迁移工作，我们使用了挂载副本。AWS DMS 的目标 RDS 实例将作为与 Oracle SuperCluster 同步的备份数据库。我们从此 RDS 实例创建一个副本，以使我们的并行运行和切换工作顺利进行。

通过从 AWS DMS 目标 RDS 实例创建挂载副本，我们可以在之后将此副本转变为新的独立 RDS for Oracle 生产系统。同时，我们维持了 AWS DMS 目标 RDS for Oracle 实例作为备份，这样将来可以创建新的副本。由于此 RDS for Oracle 实例与本地 SuperCluster 同步，我们能够快速准备迁移环境，而无需再次执行 AWS DMS 初始数据加载。

迁移方法论

下图展示了整体架构和迁移流程的详细信息。流程包括准备迁移环境、执行并行运行、数据验证和迁移切换。

[](https//