AWS Database Migration Service 的最佳做法

要想尽可能高效地使用 AWS Database Migration Service (AWS DMS)，请参阅此部分中有关以最有效方式迁移数据的建议。

AWS Database Migration Service 的迁移规划

在规划使用 AWS Database Migration Service 进行数据库迁移时，请考虑以下事项：

要将源数据库和目标数据库连接到 AWS DMS 复制实例，您需要对网络进行配置。只需在与您的复制实例相同的虚拟私有云 (VPC) 中连接两个 AWS 资源，即可实现此目的。还可以进行更复杂的配置，例如通过虚拟专用网络 (VPN) 将本地数据库连接到 Amazon RDS 数据库实例。有关更多信息，请参见数据库迁移的网络配置。
源端点和目标端点 – 确保您知道源数据库中的哪些信息和表需要迁移到目标数据库。AWS DMS 支持基本架构迁移，包括创建表和主键。但是，AWS DMS 不会在目标数据库中自动创建辅助索引、外键、用户账户等。根据源和目标数据库引擎，您可能需要设置补充日志记录或者修改源和目标数据库的其他设置。有关更多信息，请参阅数据迁移的源和数据迁移的目标：
架构和代码迁移 – AWS DMS 不执行架构或代码转换。您可以使用 Oracle SQL Developer、MySQL Workbench 和 pgAdmin III 等工具来转换架构。如果需要将现有架构转换到不同的数据库引擎，可以使用 AWS Schema Conversion Tool (AWS SCT)。它可以创建目标架构，也可以生成和创建整个架构：表、索引、视图等。您还可以使用此工具来将 PL/SQL 或 TSQL 转换为 PgSQL 和其他格式。有关 AWS SCT 的更多信息，请参阅 AWS SCT 用户指南。
不支持的数据类型 – 确保可将源数据类型转换为目标数据库的等效数据类型。有关支持的数据类型的更多信息，请参阅有关数据存储的源或目标部分。
诊断支持脚本结果 – 在规划迁移时，我们建议您运行诊断支持脚本。利用这些脚本的结果，您可以找到有关潜在迁移失败的预告信息。

如果您的数据库有可用的支持脚本，可以使用下文所述相应脚本主题中的链接下载脚本。验证并查看脚本后，可以按照脚本主题中描述的步骤在本地环境中运行该脚本。脚本运行完成后，您可以查看结果。我们建议将运行这些脚本作为任何故障排除工作的第一步。在与 AWS Support 团队合作时，这些结果可能很有用。有关更多信息，请参见在中使用诊断支持脚本 AWS DMS。
迁移前评估 – 迁移前评估会评估数据库迁移任务的指定组件，这有助于确定可能导致迁移任务无法按预期运行的任何问题。使用此评估，您可以在运行新的或修改的任务之前确定潜在的问题。有关使用迁移前评估的更多信息，请参阅为任务启用和使用迁移前评估。

转换架构

AWS DMS 不执行架构或代码转换。如果要将现有架构转换为其他数据库引擎，您可以使用 AWS SCT。AWS SCT 将源对象、表、索引、视图、触发器和其他系统对象转换为目标数据定义语言 (DDL) 格式。您还可以使用 AWS SCT 将大部分应用程序代码（例如 PL/SQL 或 TSQL）转换为对等的目标语言。

您可以通过从 AWS 免费下载来获取 AWS SCT。有关 AWS SCT 的更多信息，请参阅 AWS SCT 用户指南。

如果源端点和目标端点位于同一个数据库引擎上，则可以使用 Oracle SQL Developer、MySQL Workbench 或 PgAdmin 4 等工具来移动架构。

查看 AWS DMS 公共文档

我们强烈建议您在首次迁移之前浏览源端点和目标端点的 AWS DMS 公共文档页面。本文档可以协助您在开始迁移之前确定迁移的先决条件并了解当前的限制。有关更多信息，请参见使用 AWS DMS 端点。

在迁移期间，公共文档可以帮您解决与 AWS DMS 相关的任何问题。文档中的故障排除页面可以帮您解决使用 AWS DMS 和所选端点数据库的常见问题。有关更多信息，请参见对中的迁移任务进行故障排除 AWS Database Migration Service。

运行概念验证

为了协助在数据库迁移的早期阶段发现环境问题，我们建议您运行一次小型测试迁移。这样做还有助于设置更符合实际情况的迁移时间表。此外，您可能需要运行全面的测试迁移，以衡量 AWS DMS 能否通过网络处理数据库的吞吐量。在此期间，我们建议对您的初始完全加载和持续复制进行基准测试和优化。这样做有助于了解网络延迟和衡量整体性能。

此时，您还有机会了解自己的数据配置文件以及数据库的大小，包括以下内容：

大、中、小型表的数量。
AWS DMS 如何处理数据类型和字符集转换。
包含大对象 (LOB) 列的表的数量。
运行测试迁移需要多长时间。

改进 AWS DMS 迁移的性能

AWS DMS 迁移的性能受多种因素影响：

源上的资源可用性。
可用的网络吞吐量。
复制服务器的资源容量。
目标接收更改的能力。
源数据的类型和分布。
要迁移的对象数量。

可以使用下面所述的部分或全部最佳实践来改进性能。是否使用这些实践之一取决于您的特定使用案例。您可以在下面找到一些限制：

预置合适的复制服务器

AWS DMS 是一项在 Amazon EC2 实例上运行的托管服务。此服务可连接到源数据库，读取源数据、格式化数据以供目标数据库使用，并将数据加载到目标数据库中。

大部分这种处理发生在内存中。但是，大型事务可能需要部分缓冲到磁盘上。缓存事务和日志文件也会写入磁盘。在以下章节中，您可以了解在选择复制服务器时应考虑的事项。

CPU

AWS DMS 专为异构迁移而设计，但它也支持同构迁移。要执行同构迁移，请先将每个源数据类型转换为其等效 AWS DMS 的数据类型。然后将每个 AWS DMS 类型的数据转换为目标数据类型。您可以在《AWS DMS 用户指南》中找到适用于每个数据库引擎的这些转换参考资料。

要让 AWS DMS 以最佳性能执行这些转换，进行转换时必须有 CPU 可用。如果由于 CPU 过载而没有足够的 CPU 资源，可能会导致迁移速度缓慢，这也可能导致其他副作用。

复制实例类

一些较小的实例类足够用于测试服务或小型迁移。如果您的迁移涉及大量表，或者打算同时运行多个复制任务，应考虑使用较大的实例之一。最好使用较大的实例，因为该服务会消耗大量的内存和 CPU。

T2 类型实例设计用于提供适度的基准性能，并能够根据您工作负载的需要实现性能的显著突增。它们可用于不经常或不持续使用完整 CPU、但偶尔需要突增性能的工作负载。T2 实例非常适合通用型工作负载，例如 Web 服务器、开发人员环境和小型数据库。如果您要排除迁移缓慢问题，并使用 T2 实例类型，请查看 CPU 利用率主机指标。它可以显示您是否突破了该实例类型的基准。

C4 实例类旨在为计算机密集型工作负载交付最高级别的处理器性能。它们显著提高了每秒数据包 (PPS) 的性能、降低了网络抖动和网络延迟。AWS DMS 可能会占用大量 CPU，尤其是在执行异构迁移和复制（例如从 Oracle 迁移到 PostgreSQL）时。针对这些情况，C4 实例是理想选择。

R4 实例类针对内存密集型工作负载优化了内存。使用 AWS DMS 持续迁移或复制高吞吐量事务系统有时会占用大量 CPU 和内存。R4 实例的每个 vCPU 包含更多内存。

AWS DMS 支持 R5 和 C5 实例类

R5 实例类是内存优化型实例，旨在让处理内存中的大型数据集的工作负载实现快速性能。使用 AWS DMS 持续迁移或复制高吞吐量事务系统有时会占用大量 CPU 和内存。R5 实例每个 vCPU 提供的内存比 R4 高 5%，最大容量可提供 768 GiB 的内存。此外，与 R4 相比，R5 实例每 GiB 的价格提高了 10%，CPU 性能提高了大约 20%。

C5 实例类针对计算密集型工作负载进行了优化，能够以较低的价格提供经济实惠的高性能。它们显著提高了网络性能。弹性网络适配器 (ENA) 为 C5 实例提供高达 25 Gbps 的网络带宽和高达 14 Gbps 的 Amazon EBS 专用带宽。AWS DMS 可能会占用大量 CPU，尤其是在执行异构迁移和复制时，例如从 Oracle 迁移至 PostgreSQL。针对这些情况，C5 实例是理想选择。

存储

根据具体的实例类，您的复制实例附带 50 GB 或 100 GB 的数据存储。此存储用于存储加载期间收集的日志文件以及所有缓存更改。如果源系统繁忙或需要处理大量事务，则可能需要增加存储空间。如果您在复制服务器上运行多个任务，可能还需要增加存储空间。不过，通常默认容量已经足够。

AWS DMS 中的所有存储卷均为 GP2 或通用型固态硬盘 (SSD)。GP2 卷的基本性能为每秒三次 I/O 操作 (IOPS)，并且能够基于积分突增至 3000 IOPS。根据经验，请检查复制实例的 ReadIOPS 和 WriteIOPS 指标。确保这些值的总和不会超过该卷的基本性能。

多可用区

选择多可用区实例可以保护您的迁移免受存储故障的影响。大多数迁移都是短暂的，不会长时间运行。如果您将 AWS DMS 用于持续复制，选择多可用区实例可在出现存储问题时提高可用性。

在完全加载期间使用单可用区或多可用区复制实例并且发生失效转移或主机更换时，预计完全加载任务将失败。对于未完成或处于错误状态的其余表，您可以从失败点重新启动此任务。

并行加载多个表

默认情况下，AWS DMS 一次加载八个表。在使用非常大的复制服务器时，例如 dms.c4.xlarge 或更大的实例，您可以稍微提升此值来实现一些性能改进。但是，某些时候增加此并行度会降低性能。如果您的复制服务器相对较小，例如 dms.t2.medium，则建议您减少并行加载的表数量。

要在 AWS Management Console 中更改此数量，请打开控制台，选择任务，再选择创建或修改任务，然后选择高级设置。在 Tuning Settings (优化设置) 下，更改 Maximum number of tables to load in parallel (并行加载的最大表数) 选项。

要使用 AWS CLI 更改此数，请更改 TaskSettings 下的 MaxFullLoadSubTasks 参数。

使用并行完全加载

您可以根据分区和子分区从 Oracle、Microsoft SQL Server、MySQL、Sybase 和 IBM Db2 LUW 源执行并行加载。这样做可以缩短整个完全加载的持续时间。此外，在运行 AWS DMS 迁移任务时，您可以加快大型表或分区表的迁移速度。为此，请将表拆分为多个段，然后在同一个迁移任务中并行加载这些段。

要使用并行加载，您可以使用 parallel-load 选项创建类型为 table-settings 的表映射规则。在 table-settings 规则中，请指定要并行加载的一个或多个表的选择条件。要指定选择条件，请将 parallel-load 的 type 元素设置为下列设置之一：

partitions-auto
subpartitions-auto
partitions-list
ranges
none

有关这些设置的更多信息，请参阅表和集合设置规则和操作。

使用索引、触发器和引用完整性约束

索引、触发器和引用完整性约束可能会影响您的迁移性能，并导致迁移失败。它们具体如何影响迁移取决于您的复制任务是完全加载任务还是持续复制（更改数据捕获或 CDC）任务。

对于完全加载任务，建议您删除主键索引、二级索引、引用完整性约束和数据操作语言 (DML) 触发器。或者，您也可以将其创建延迟到完全加载任务完成之后。完全加载任务期间不需要索引，如果存在索引，则会导致维护开销。由于完整加载任务一次加载一组表，这会违反引用完整性约束。同样，插入、更新和删除触发器会导致错误，例如，以前批量加载的表会触发行插入。由于增加了处理量，其他类型的触发器也会影响性能。

如果数据量相对较小并且不担心额外增加的迁移时间，您可以在完全加载任务之前生成主键和二级索引。应始终禁用引用完整性约束和触发器。

对于完全加载外加 CDC 任务，建议您在 CDC 阶段之前添加二级索引。由于 AWS DMS 使用逻辑复制，应确保采用支持 DML 操作的二级索引来防止全表扫描。您可以在 CDC 阶段之前暂停复制任务以构建索引、创建引用完整性约束，然后重新启动任务。

您应该在割接之前启用触发器。

关闭备份和事务日志记录

迁移到 Amazon RDS 数据库时，在您准备好割接之前，最好关闭目标上的备份和多可用区。类似地，迁移到非 Amazon RDS 系统时，通常最好关闭目标上的任何日志记录，直到完成割接。

使用多个任务

有时候，为单个迁移使用多个任务可以提升性能。如果您有不参与到通用事务的表集，也许可将迁移拆分为多个任务。在任务中维护事务一致性，因此，不同任务中的表不参与到通用事务中非常重要。此外，每个任务独立读取事务流，因此请注意，不要对源数据库施加过多压力。

您可以使用多个任务来创建多个单独的复制流。通过这样做，您可以并行处理源数据库上的读取、复制实例上的进程以及对目标数据库的写入。

优化更改处理

默认情况下，AWS DMS 在事务模式下处理更改，这可保护事务完整性。如果您可以承受事务完整性的临时失效，可以改为使用批量优化应用选项。该选项有效分组事务并批量应用，以实现提高效率的目的。使用批量优化的应用选项几乎总是违反引用完整性约束。因此，我们建议您在迁移过程中关闭这些限制，然后在割接过程中再次将其打开。

使用您自己的本地名称服务器

通常，AWS DMS 复制实例使用 Amazon EC2 实例中的域名系统 (DNS) 解析程序来解析域端点。但是，如果您使用 Amazon Route 53 Resolver，则可以使用自己的本地名称服务器来解析某些端点。使用此工具，您可以使用入站和出站端点、转发规则和私有连接在本地和 AWS 之间进行查询。使用本地名称服务器的好处包括通过防火墙提高了安全性和易用性。

如果您有入站端点，则可以使用源自本地的 DNS 查询来解析 AWS 托管的域。要配置端点，请在您要提供解析程序的每个子网中分配 IP 地址。要在您的本地 DNS 基础设施与 AWS 之间建立连接，请使用 AWS Direct Connect 或虚拟专用网络 (VPN)。

出站端点连接到您的本地名称服务器。域名服务器仅授予对允许列表中包含和出站端点中设置的 IP 地址的访问权限。名称服务器的 IP 地址是目标 IP 地址。为出站端点选择安全组时，请选择复制实例使用的同一安全组。

要将选定域转发到名称服务器，请使用转发规则。出站端点可以处理多个转发规则。转发规则的范围是您的虚拟私有云 (VPC)。通过使用与 VPC 关联的转发规则，您可以预置 AWS 云的逻辑分隔部分。在这个逻辑分隔部分，您可以启动虚拟网络中的 AWS 资源。

您可将本地 DNS 基础设施中托管的域配置为设置出站 DNS 查询的条件转发规则。对其中一个域进行查询时，规则触发尝试将 DNS 请求转发到配置了规则的服务器。同样，需要通过 AWS Direct Connect 或 VPN 建立私有连接。

下图显示了 Route 53 Resolver 的架构。

有关 Route 53 DNS 解析程序的更多信息，请参阅《Amazon Route 53 开发人员指南》中的 Route 53 Resolver 入门。

将 Amazon Route 53 Resolver 与 AWS DMS 配合使用

您可以为 AWS DMS 创建本地名称服务器，从而使用 Amazon Route 53 Resolver 来解析端点。

为基于 Route 53 的 AWS DMS 创建本地名称服务器

登录到 AWS Management Console，然后通过以下网址打开 Route 53 控制台：https://console.aws.amazon.com/route53/。
在 Route 53 控制台上，选择要在其中配置 Route 53 Resolver 的 AWS 区域。Route 53 Resolver 特定于一个区域。
选择查询方向，即入站和/或出站。
提供您的入站查询配置：
1. 输入端点名称并选择 VPC。
2. 从 VPC 内分配一个或多个子网（例如，选择两个子网以确保可用性）。
3. 分配特定的 IP 地址以用作端点，或者让 Route 53 Resolver 自动分配这些地址。
为本地域创建规则，以便 VPC 内的工作负载可以将 DNS 查询路由到您的 DNS 基础设施。
为本地 DNS 服务器输入一个或多个 IP 地址。
提交您的规则。

所有内容都已创建，您的 VPC 与您的入站和出站规则相关联，并且可以开始路由流量。

有关 Route 53 Resolver 的更多信息，请参阅《Amazon Route 53 开发人员指南》中的 Route 53 Resolver 入门。

迁移大型二进制对象 (LOB)

通常，AWS DMS 分两个阶段迁移 LOB 数据：

AWS DMS 会在目标表中创建一个新行，并用除相关 LOB 值之外的所有数据来填充该行。
AWS DMS 使用 LOB 数据更新目标表中的行。

LOB 的这种迁移过程要求，在迁移期间，目标表上的所有 LOB 列都必须可为空。即使源表上的 LOB 列不可为空，也是如此。如果 AWS DMS 创建目标表，默认情况下会将 LOB 列设置为可为空值。在某些情况下，您可能使用其他机制（例如导入或导出）来创建目标表。在这种情况下，在开始迁移任务之前，请确保 LOB 列可为空值。

此要求有一个例外情况。假设您执行从 Oracle 源到 Oracle 目标的同类迁移，并且您选择 Limited Lob mode (受限 LOB 模式)。在这种情况下，将一次填充整行，包括任何 LOB 值。对于此类情况，如果需要，AWS DMS 可以使用不可为空的约束创建目标表 LOB 列。

使用受限 LOB 模式

当迁移包含 LOB 值时，AWS DMS 使用两种方法来平衡性能与简便性。

Limited LOB mode (受限 LOB 模式) 迁移所有最大为用户指定的大小限制 (默认为 32 KB) 的 LOB 值。大于此大小限制的 LOB 值必须手动迁移。Limited LOB mode (受限 LOB 模式) 是所有迁移任务的默认值，通常提供最佳性能。不过，请确保最大 LOB 大小参数设置正确。应将该参数设置为所有表的最大 LOB 大小。
Full LOB mode (完整 LOB 模式) 迁移表中的所有 LOB 数据，而不受大小限制。Full LOB mode (完整 LOB 模式) 提供了移动表中所有 LOB 数据的便利性，不过该过程对性能可能会有显著影响。

对于某些数据库引擎（如 PostgreSQL），AWS DMS 处理 JSON 数据类型的方式类似于 LOB。确保如果您选择了受限 LOB 模式，则将最大 LOB 大小选项设置为不会导致 JSON 数据被截断的值。

AWS DMS 完全支持使用大对象数据类型（BLOB、CLOB 和 NCLOB）。以下源终端节点具有完整的 LOB 支持：

Oracle
Microsoft SQL Server
ODBC

以下目标终端节点具有完整的 LOB 支持：

Oracle
Microsoft SQL Server

以下目标终端节点具有有限的 LOB 支持。对于此目标终端节点，您不能使用无限制的 LOB 大小。

Amazon Redshift
Amazon S3

对于具有完整 LOB 支持的终端节点，您还可以为 LOB 数据类型设置大小限制。

提高了 LOB 性能

迁移 LOB 数据时，您可以指定以下不同的 LOB 优化设置。

每个表的 LOB 设置

使用每个表的 LOB 设置，您可以覆盖部分或所有表的任务级 LOB 设置。为此，请在 table-settings 规则中定义 lob-settings。以下是包含一些较大的 LOB 值的示例表。


SET SERVEROUTPUT ON
CREATE TABLE TEST_CLOB
(
ID NUMBER,
C1 CLOB,
C2 VARCHAR2(4000)
);
DECLARE
bigtextstring CLOB := '123';
iINT;
BEGIN
WHILE Length(bigtextstring) <= 60000 LOOP
bigtextstring := bigtextstring || '000000000000000000000000000000000';
END LOOP;
INSERT INTO TEST_CLOB (ID, C1, C2) VALUES (0, bigtextstring,'AnyValue');
END;
/
SELECT * FROM TEST_CLOB;
COMMIT

接下来，创建迁移任务，并使用新 lob-settings 规则修改表的 LOB 处理。bulk-max-siz 值决定了最大 LOB 大小 (KB)。如果它大于指定的大小，则会被截断。


{
	"rules": [{
			"rule-type": "selection",
			"rule-id": "1",
			"rule-name": "1",
			"object-locator": {
				"schema-name": "HR",
				"table-name": "TEST_CLOB"
			},
			"rule-action": "include"
		},
		{
			"rule-type": "table-settings",
			"rule-id": "2",
			"rule-name": "2",
			"object-locator": {
				"schema-name": "HR",
				"table-name": "TEST_CLOB"
			},
			"lob-settings": {
				"mode": "limited",
				"bulk-max-size": "16"
			}
		}
	]
}

即使此 AWS DMS 任务是使用 FullLobMode : true 创建的，每个表的 LOB 设置也会指示 AWS DMS 将此特定表中的 LOB 数据截断为 16000。您可以查看任务日志来确认这一点。


721331968: 2018-09-11T19:48:46:979532 [SOURCE_UNLOAD] W: The value of column 'C' in table
'HR.TEST_CLOB' was truncated to length 16384

内联 LOB 设置

创建 AWS DMS 任务时，LOB 模式决定了如何处理 LOB。

对于完整 LOB 模式和受限 LOB 模式，每种模式都有自己的优缺点。内联 LOB 模式结合了完整 LOB 模式和受限 LOB 模式的优点。

当您需要同时复制小型和大型 LOB，并且大多数 LOB 都很小时，可以使用内联 LOB 模式。选择此选项时，在完全加载期间，AWS DMS 任务会以内联方式传输小 LOB，这样更加高效。AWS DMS 任务通过从源表中执行查找来传输大型 LOB。

在更改处理过程中，小型和大型 LOB 都通过从源表中执行查找来复制。

使用内联 LOB 模式时，AWS DMS 任务会检查所有 LOB 大小，以确定内联传输哪些 LOB。大于指定大小的 LOB 将使用完整 LOB 模式进行复制。因此，如果您知道大多数 LOB 的大小都大于指定设置，最好不要使用此选项。而应允许使用无限制的 LOB 大小。

您可以使用任务设置 InlineLobMaxSize 中的属性来配置此选项，该属性仅在 FullLobMode 设置为 true 时才可用。InlineLobMaxSize 的默认值是 0，范围为 1–102400 KB (100 MB)。

例如，您可以使用以下 AWS DMS 任务设置。此处，将 InlineLobMaxSize 的值设置为 5 会导致所有小于或等于 5 KiB（5120 字节）的 LOB 都以内联方式传输。


{
  "TargetMetadata": {
  "TargetSchema": "",
  "SupportLobs": true,
  "FullLobMode": true,
  "LobChunkSize": 64,
  "LimitedSizeLobMode": false,
  "LobMaxSize": 32,
  "InlineLobMaxSize": 5,
  "LoadMaxFileSize": 0,
  "ParallelLoadThreads": 0,
  "ParallelLoadBufferSize":0,
  "BatchApplyEnabled": false,
  "TaskRecoveryTableEnabled": false},
  . . .
}

使用行筛选提高迁移大型表时的性能

要在迁移大型表时改进性能，可将迁移过程分解为多个任务。要通过行筛选将迁移分解为多个任务，您可以使用键或分区键。例如，如果您有一个整数主键 ID，范围从 1 到 8000000，您可以使用行筛选创建 8 个任务，每个任务迁移 100 万条记录。

在控制台中应用行筛选：

打开 AWS Management Console。
选择任务，然后创建新任务。
选择表映射选项卡，然后展开选择规则。
选择添加新选择规则。现在可以使用小于或等于、大于或等于、等于或范围条件（介于两个值之间）添加列筛选。有关列筛选的更多信息，请参阅通过控制台指定表选择和转换规则。

如果您有按照日期分区的大型分区表，您可以根据日期来迁移数据。例如，假设您有一个按月分区的表，并且只更新当前月份的数据。在此情况下，您可以为每个静态的每月分区创建一个完全加载任务，并为当前已更新的分区创建一个完全加载外加 CDC 任务。

如果您的表具有单列主键或唯一索引，则可让 AWS DMS 任务使用范围类型的并行加载来对表进行分段，以并行加载数据。有关更多信息，请参见表和集合设置规则和操作。

持续复制

AWS DMS 提供数据的持续复制，确保源数据库与目标数据库的同步。它只复制有限数量的数据定义语言 (DDL) 语句。AWS DMS 不传播索引、用户、权限、存储过程和其他不直接关联到表数据的数据库更改等项目。

如果您计划使用持续复制，则应在创建复制实例时启用多可用区选项。通过选择多可用区选项，可为复制实例提供高可用性和失效转移支持。但是，此选项可能会影响性能，并且在对目标系统进行更改时可能会减慢复制速度。

在升级源数据库或目标数据库之前，我们建议您停止在这些数据库上运行的所有 AWS DMS 任务。升级完成后再继续执行任务。

在持续复制期间，确定源数据库系统和 AWS DMS 复制实例之间的网络带宽至关重要。确保网络不会在持续复制期间造成任何瓶颈。

确定源数据库系统上每小时的更改率和存档日志生成率也很重要。这样做可以帮您了解在持续复制期间可能获得的吞吐量。

减少源数据库上的负载

AWS DMS 使用源数据库上的一些资源。在完整加载任务期间，AWS DMS 对并行处理的每个表执行源表的完整表扫描。此外，您在迁移过程中创建的各个任务会在 CDC 过程中查询源中的更改。要使 AWS DMS 对一些源（例如 Oracle）执行 CDC，您可能需要增加写入到数据库更改日志中的数据量。

如果您发现对源数据库造成的负担过重，可以减少迁移过程中的任务数或每个任务的表数量。每个任务独立获取源更改，因此整合任务可以减少更改捕获工作负载。

减少目标数据库的瓶颈

迁移期间，请尽可能消除目标数据库上会争用写入资源的任何进程：

关闭不必要的触发器。
在初始加载期间关闭二级索引，稍后在持续复制期间将其重新打开。
对于 Amazon RDS 数据库，最好在割接之前关闭备份和多可用区。
迁移到非 RDS 系统时，最好在割接之前关闭目标上的任何日志记录。

在迁移期间使用数据验证

为确保准确地将数据从源迁移到目标，我们强烈建议您使用数据验证。如果为任务启用数据验证，AWS DMS 会在对表执行完全加载后，立即开始比较源和目标数据。

数据验证使用以下数据库，而 AWS DMS 支持它们作为源终端节点和目标终端节点：

Oracle
PostgreSQL
MySQL
MariaDB
Microsoft SQL Server
Amazon Aurora MySQL 兼容版
Amazon Aurora PostgreSQL 兼容版
IBM Db2 LUW
Amazon Redshift

有关更多信息，请参见 AWS DMS 数据验证。

使用指标监控您的 AWS DMS 任务

您可以通过多种方式使用 AWS DMS 控制台监控任务的指标：

主机指标: 您可以在每个特定复制实例的CloudWatch 指标选项卡上找到主机指标。在这里，您可以监控您的复制实例的大小是否合适。

复制任务指标: 可以在每个特定任务的指标选项卡上找到复制任务的CloudWatch 指标，包括传入和提交的更改，以及复制主机和源/目标数据库之间的延迟。

表指标

您可以在每项任务的表统计选项卡上找到各个表指标。这些指标包括以下数字：

在完全加载期间加载的行。
自任务启动以来的插入、更新和删除操作。
自任务启动以来的 DDL 操作。

有关监视指标的更多信息，请参阅监控 AWS DMS任务。

事件和通知

AWS DMS 使用 Amazon SNS 在发生 AWS DMS 事件（例如创建或删除复制实例）时提供通知。您可以按照 Amazon SNS 在 AWS 区域中支持的任何形式使用这些通知。这些通知可能包括电子邮件、短信或对 HTTP 端点的调用。

有关更多信息，请参见在 AWS Database Migration Service 中使用 Amazon SNS 事件和通知。

使用任务日志以排除迁移问题

在某些情况下，AWS DMS 会遇到一些仅在任务日志中显示警告或错误消息的问题。具体而言，数据截断问题或者外键违规造成的行拒绝仅会写入任务日志。因此，在迁移数据库时务必要查看任务日志。要查看任务日志，请在任务创建过程中配置 CloudWatch Amazon。

有关更多信息，请参阅使用 Amazon 监控复制任务 CloudWatch。

使用 Time Travel 对复制任务进行故障排除

要排除 AWS DMS 迁移问题，您可以使用 Time Travel。有关 Time Travel 的更多信息，请参阅Time Travel 任务设置。

在使用 Time Travel 时，请注意以下事项：

为避免 DMS 复制实例的开销，请仅对需要调试的任务启用 Time Travel。
当您使用 Time Travel 对可能持续数天的复制任务进行故障排除时，请监控复制实例指标以了解资源开销。这种方法尤其适用于在源数据库上长时间运行高事务负载的情况。有关更多详细信息，请参阅监控 AWS DMS任务。
如果将 Time Travel 任务设置 EnableRawData 设置为 true，DMS 复制期间的任务内存使用量可能会高于未启用 Time Travel 时的内存使用量。如果您长时间启用 Time Travel，请监视您的任务。
目前，你只能在任务级别启用 Time Travel。对所有表的更改都记录在 Time Travel 日志中。如果您要对事务量大的数据库中的特定表进行故障排除，请创建单独的任务。

为 Oracle 目标更改用户和架构

在使用 Oracle 作为目标时，AWS DMS 将数据迁移到目标端点的用户所拥有的架构。

例如，假设您将名为 PERFDATA 的架构迁移到 Oracle 目标端点，并且目标端点用户名为 MASTER。AWS DMS 将作为 MASTER 连接到 Oracle 目标，并使用 PERFDATA 中的数据库对象填充 MASTER 架构。

要覆盖此行为，请提供架构转换。例如，要将 PERFDATA 架构对象迁移到目标端点上的 PERFDATA 架构，可使用以下转换。


{
    "rule-type": "transformation",
    "rule-id": "2",
    "rule-name": "2",
    "object-locator": {
        "schema-name": "PERFDATA"
    },
    "rule-target": "schema",
    "rule-action": "rename",
    "value": "PERFDATA"
}

有关转换的更多信息，请参阅使用 JSON 指定表选择和转换规则。

更改 Oracle 目标的表和索引表空间

使用 Oracle 作为目标时，AWS DMS 会将所有表和索引迁移到目标中的默认表空间。例如，假设您的源是 Oracle 之外的数据库引擎。所有目标表和索引都迁移到相同的默认表空间。

要覆盖此行为，请提供相应的表空间转换。例如，假设您要将表和索引迁移到 Oracle 目标中的表和索引表空间，这些表空间以源中的架构命名。在此情况下，您可以使用与下面类似的转换。在这里，源中的架构名为 INVENTORY，目标中的相应表和索引表空间分别名为 INVENTORYTBL 和 INVENTORYIDX。


{
   "rule-type": "transformation",
   "rule-id": "3",
   "rule-name": "3",
   "rule-action": "rename",
   "rule-target": "table-tablespace",
   "object-locator": {
      "schema-name": "INVENTORY",
      "table-name": "%",
      "table-tablespace-name": "%"
   },
   "value": "INVENTORYTBL"
},
{
   "rule-type": "transformation",
   "rule-id": "4
   "rule-name": "4",
   "rule-action": "rename",
   "rule-target": "index-tablespace",
   "object-locator": {
      "schema-name": "INVENTORY",
      "table-name": "%",
      "index-tablespace-name": "%"
   },
   "value": "INVENTORYIDX"
}

有关转换的更多信息，请参阅使用 JSON 指定表选择和转换规则。

如果 Oracle 同时作为源和目标，则可以通过设置 Oracle 源额外连接属性 enableHomogenousTablespace=true 来保留现有的表或索引表空间分配。有关更多信息，请参见使用 Oracle 作为来源时的终端节点设置 AWS DMS。

升级复制实例的版本

AWS 定期发布 AWS DMS 复制引擎软件的新版本以提供新功能和增强性能。每个版本的复制引擎软件都有自己的版本号。在将 AWS DMS 复制实例升级到更高版本之前，必须测试运行生产工作负载的复制实例的现有版本。有关可用版本升级的更多信息，请参阅AWS DMS发行说明。

了解您的迁移成本

AWS Database Migration Service 可协助您以低成本轻松安全地将数据库迁移到 AWS。您只需为复制实例和任何额外的日志存储空间付费。每个数据库迁移实例都包括足以容纳交换空间的存储空间、复制日志和用于大多数复制的数据缓存，并且入站数据传输是免费的。

在初始加载期间或加载高峰期，您可能需要更多资源。您可以使用 CloudWatch 指标密切监控复制实例的资源利用率。然后，您可以根据使用情况纵向扩展和缩减复制实例的大小。

有关估算迁移成本的更多信息，请参阅：

Javascript 在您的浏览器中被禁用或不可用。

要使用 Amazon Web Services 文档，必须启用 Javascript。请参阅浏览器的帮助页面以了解相关说明。

文档惯例

管理迁移项目

使用无 AWS DMS 服务器

AWS Database Migration Service 的最佳做法

主题

AWS Database Migration Service 的迁移规划

转换架构

查看 AWS DMS 公共文档

运行概念验证

改进 AWS DMS 迁移的性能

使用您自己的本地名称服务器

将 Amazon Route 53 Resolver 与 AWS DMS 配合使用

为基于 Route 53 的 AWS DMS 创建本地名称服务器

迁移大型二进制对象 (LOB)

使用受限 LOB 模式

提高了 LOB 性能

每个表的 LOB 设置

内联 LOB 设置

使用行筛选提高迁移大型表时的性能

在控制台中应用行筛选：

持续复制

减少源数据库上的负载

减少目标数据库的瓶颈

在迁移期间使用数据验证

使用指标监控您的 AWS DMS 任务

事件和通知

使用任务日志以排除迁移问题

使用 Time Travel 对复制任务进行故障排除

为 Oracle 目标更改用户和架构

更改 Oracle 目标的表和索引表空间

升级复制实例的版本

了解您的迁移成本