Db2 到 Amazon RDS 性能优化

关键要点

在本文中，我们将探讨如何优化从自管理 Db2 数据库到 Amazon RDS for Db2 的全量加载和持续复制任务的性能。通过采用合适的设置，可以显著降低延迟，并加速向目标数据库的切换。

AWS 最近宣布将 Amazon Relational Database Service (Amazon RDS) for Db2 作为支持的目标，提供给 AWS 数据库迁移服务 (AWS DMS)。这条新消息使得用户能够便捷地将自管理的 Db2 LUW 数据库工作负载迁移到 Amazon RDS for Db2，以快速且几乎没有停机时间的方式实现数据库迁移和后续变更的复制。

解决方案概述

以下图示展示了解决方案的架构：

自管理的 Db2 LUW 数据库通过 AWS Direct Connect 连接到 AWS DMS，您也可以使用站点间 VPN 服务私密连接到 AWS。AWS DMS 服务包含一个或多个复制实例和复制任务，以迁移和/或复制数据到目标 RDS Db2 实例。

为了更快速地迁移大量数据并复制持续变更，AWS DMS 支持 分段或并行加载 和 批处理应用 处理功能。AWS DMS 配置为在进行全量加载和持续复制时，使用 Db2 加载工具，并启用批处理应用。

准备条件

如果您对 AWS DMS 的工作原理和如何设置源及目标系统进行迁移有基本了解，那么您可以继续进行。如果您刚开始接触 AWS DMS，请参考 AWS DMS 文档。您应该还需要设置一个支持的 Db2 LUW 源 数据库，并配置一个 Amazon RDS for Db2 目标 以便进行迁移。入门可参考以下资源：

全量加载迁移

进行全量加载迁移时，您需要在源数据库上授予 DATAACCESS 权限，以便提取数据，并创建一个在要迁移的架构上具有所有权限的用户，或者在目标数据库上使用 RDS 主用户。

Db2 原生的 db2load API 提供更好的性能，因此我们在初始全量加载时使用它。当使用 Db2 目标时，仅支持有限的 LOB 模式。您可以在 KB 中配置 LobMaxSize 的值，以允许将 LOB 数据作为行内数据传输，最大推荐值为 100 MB。超过 LobMaxSize 的 LOB 大小将被截断，并向日志文件发出警告。此模式提供了性能提升，但有一定数据丢失的风险。如果您的表中没有 LOB，则无需担心。

LobMaxSize

您可以通过在源数据库中运行以下 PL/SQL 代码来检查 LOB 的存在及其最大大小。您需要输入您的架构和表名。

sqlBEGIN DECLARE vstatement varchar(256) DECLARE vcolumn varchar(180) DECLARE vtype varchar(20) DECLARE lsize BIGINT FOR v1 AS (SELECT 完整的 SQL 查询代码 ) DO SET vstatement = v1stmt END FOREND/

根据上述查询的输出，您可以识别并设置 LobMaxSize 的值，以便将 LOB 数据和行数据一起迁移。

数据集

在本文中，我们将一个示例 TPCC 数据集迁移到 Amazon RDS for Db2，其中包含九个表，总大小约为 75 GB。您可以使用以下查询来查找特定架构的表大小和行数：

sqlSELECT 完整的 SQL 查询代码

源、目标和复制实例配置

对于此全量加载操作，我们使用以下源、目标和复制实例的配置。我们在默认和调优设置下测试全量加载的性能，以便进行比较。我们还使用相同的硬件配置进行两个测试，仅修改各种设置。

使用默认任务设置迁移数据

由于这是基础任务，仅用于比较，我们在任务和端点设置中使用默认值，从源迁移 75 GB 数据到目标。由于数据传输通过公共网络进行，全量加载迁移耗时 4 小时 32 分，速度约为 46 MB/秒。

在默认设置下，我们并行加载八个表；在目标表上预先创建主键，每个表的加载过程每 10000 行提交。这样限制了并发加载的表数量，增加了全量加载的时间，因为每次数据加载时不断更新索引。

通过 选择规则，您可以选择要迁移的数据源，例如架构、表和视图。可以应用高级设置，例如数据过滤和表加载顺序；然而，因为这将只是一次性迁移，所以我们没有应用任何过滤或加载顺序。以下是示例代码：

json{ rules [ { ruletype selection ruleid 1 rulename 1 objectlocator { schemaname RDSDB tablename } ruleaction include } ]}

AWS DMS 提供表状态、全量加载行计数、加载时间、插入以及目标地应用的更新和删除，用于性能监控。以下截图显示了按迁移时间排序的表最长迁移时间为 4 小时 30 分 25 秒。

针对全量加载任务的可调设置

我们可以使用以下可调参数来提升全量加载任务的性能。

我们使用以下任务设置：

我们使用以下分段卸载设置：

我们使用以下目标端点设置：

前面提到的端点设置在启用批处理应用时同样适用改变数据捕获 (CDC) 阶段。

使用自定义设置和分段加载迁移数据

接下来，我们使用与之前相同的硬件配置重新运行全量加载操作，但我们修改全量加载和端点设置，尝试进行分段数据加载，以利用并行表加载。

在以下设置中，我们创建一个任务，以在全量加载后创建主键，减少数据库写入主键索引的次数，并将最大子任务设置为最大限度，以支持额外的并行加载线程，同时提交率设置为最大限制 50K 记录：

jsonFullLoadSettings { CreatePkAfterFullLoad true StopTaskCachedChangesApplied false StopTaskCachedChangesNotApplied false MaxFullLoadSubTasks 49 TransactionConsistencyTimeout 600 CommitRate 50000}

我们增加以下端点设置的值以提高性能。选择的值基于内存可用性和并行加载线程数：

WriteBufferSize=204800MaxFileSize=409600

在以下代码中，我们定义了一个任务，以使用分区和范围类型的并行加载。partitionsauto 选项使 DMS 自动为每个分区创建单独的加载线程，边界范围根据数据分布确定，这些边界提供了在所有段之间近似均等的数据分配：

json{ rules [ { ruletype selection ruleid 1 rulename 1 objectlocator { schemaname RDSDB tablename } ruleaction include } { ruletype tablesettings ruleid 2 rulename 2 objectlocator { schemaname RDSDB tablename STOCK } parallelload { type partitionsauto } } { ruletype tablesettings ruleid 3 rulename 3 objectlocator { schemaname RDSDB tablename ORDERLINE } parallelload { type ranges columns [ OLOID OLWID OLDID ] boundaries [ [1200 400 4] [1800 600 6] [2400 800 8] ] } } { ruletype tablesettings ruleid 4 rulename 4 objectlocator { schemaname RDSDB tablename CUSTOMER } parallelload { type ranges columns [ CID CWID CDID ] boundaries [ [1200 400 4] [1800 600 6] [2400 800 8] ] } } ]}

以下 AWS DMS 日志片段显示了已初始化的分段，以进行并行卸载和加载：

plaintext01292313 20231108T051009 [SOURCEUNLOAD ]I Initialization finished for segmented table RDSDBCUSTOMER (Id = 1) (streamcomponentc3799)

以下截图显示了某表的最长迁移时间为 3 小时 46 分 30 秒。

采用分段卸载和调优设置后，加载时间减少了约 45 分钟。通过增加实例规模和增加存储 IOPS，可以进一步加快全量加载迁移速度。

性能测试摘要

以下表格总结了我们的性能测试，展示了全量加载所花费的时间。

从源 Db2 到 Amazon RDS for Db2 的复制

在持续复制过程中，我们从源 Db2 实例的事务日志中提取变更，并根据任务配置将改变应用到目标数据库，支持事务或批量应用模式。目标上的变更采用单线程应用。使用事务模式的好处是可以保持与源的提交顺序一致，帮助保持引用完整性约束。虽然批量应用模式可提高性能，但由于我们将变更加载到中间的净变更表并将所有变更应用于目标数据库的表，可能会违反引用完整性约束。如果您选择批量应用模式，则需要在切换过程中禁用目标上的约束，并在切换前重新启用。

准备条件

要将变更从源 Db2 复制到 Amazon RDS for Db2，您必须在源数据库执行以下操作：

授予从事务日志中提取变更的数据库用户帐户 DBADM 权限。 例如，GRANT DBADM ON DATABASE TO USER RDSDB

在很多情况下，CDC 任务的起始位置在过去，必须手动提供。要设置起始位置以提取变更，您需要设置端点设置 StartFromContext。此设置的有效值包括：

用于基于时间戳启动复制的 UTC 时间戳。 例如，timestamp20231121T000000

连同 CurrentLSN scan，源必须为 105 或更高版本：{CurrentLSN scan StartFromContext NOW}

特定日志记录标识符 (LRI)。 例如，{StartFromContext 0100000000000022CC000000000004FB13}

AWS DMS 默认情况下启用所有参与复制的表的 CDC。

源 Db2 的工作负载

对于持续复制，我们使用了配置为运行 600 秒的工作负载生成器，包含 240 秒的预热时间，以增加源上的连接数。

连接速率将以 1、10 和 25 个并发连接的顺序进行扩展，并在每次运行之间等待 240 秒。我们已经为所有后续测试启用了批处理模式，以提高 CDC 任务的性能。如前所述，我们禁用了引用完整性约束以提高性能。

复制性能测试的范围包括：

总而言之，我们进行了两项主要测试。在初始测试中，AWS DMS 在所有默认任务和端点设置下运行，然后我们将配置更改为包括自定义设置，以改善处理性能，进行与默认任务设置一致的示例运行。在接下来的两个案例中，我们将工作负载放置一段时间，以查看在增加的事务并发下工作负载如何迁移。

我们决定将之前创建的复制实例扩展到 dmsr6i8xlarge 实例类，该类有 32 个 vCPU 和 256 GB 内存，以应对源端应用大量变更的情况。

使用默认设置的复制性能

我们设置一个复制任务，使用默认值复制九个表，除了启用批处理应用外，其他任务设置均保持默认。

以下是 AWS DMS 日志片段：

plaintext00037923 20230913T172328 [SORTER]W Reading from source is paused Total storage used by swap files exceeded the limit 1048576000 bytes (sortertransactionc110)

我们在 1719 UTC 启动了任务。在 1723 UTC，由于交换文件生成，读取源的操作被暂停。在首次运行生成的负载后，我们在 10