本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 排除延迟问题
本节包含复制延迟的故障排除步骤。
要排除延迟问题，请执行以下操作：
+ 首先，确定任务的延迟类型和时间长度。从 DMS 控制台或 CLI 查看任务的“表统计数据”部分。如果计数器发生变化，则数据传输正在进行中。检查 `CDCLatencySource` 和 `CDCLatencyTarget` 指标，以确定 CDC 期间是否存在瓶颈。
+ 如果高 `CDCLatencySource` 或 `CDCLatencyTarget` 指标表明您的复制存在瓶颈，请检查以下内容：
+ 如果`CDCLatencySource`为高且等`CDCLatencyTarget`于`CDCLatencySource`，则表示您的源端点存在瓶颈，并且 AWS DMS 正在顺利地向目标端点写入数据。参见下文中的 [排除源延迟问题](CHAP_Troubleshooting_Latency_Source.md)。
+ 如果`CDCLatencySource`为低且`CDCLatencyTarget`高，则表示您的目标终端节点存在瓶颈，并且 AWS DMS 正在顺畅地从源端读取数据。参见下文中的 [排除目标延迟问题](CHAP_Troubleshooting_Latency_Target.md)。
+ 如果 `CDCLatencySource` 较高且 `CDCLatencyTarget` 明显高于 `CDCLatencySource`，则表示源读取和目标写入都存在瓶颈。首先调查源延迟，然后再调查目标延迟。
有关监控 DMS 指标的信息，请参阅 [监控 AWS DMS 任务](CHAP_Monitoring.md)。
# 排除源延迟问题
以下主题描述了特定于源端点类型的复制场景。
**Topics**
+ [Oracle 端点故障排除](CHAP_Troubleshooting_Latency_Source_Oracle.md)
+ [MySQL 端点故障排除](CHAP_Troubleshooting_Latency_Source_MySQL.md)
+ [PostgreSQL 端点故障排除](CHAP_Troubleshooting_Latency_Source_PostgreSQL.md)
+ [SQL Server 端点故障排除](CHAP_Troubleshooting_Latency_Source_SQLServer.md)
# Oracle 端点故障排除
本节包含特定于 Oracle 的复制场景。
## 源读取暂停
AWS DMS 在以下情况下，会暂停从 Oracle 来源读取。此行为是设计使然。您可以使用任务日志调查这种情况的原因。在任务日志中查找类似于以下内容的消息。有关使用任务日志的更多信息，请参阅[查看和管理 AWS DMS 任务日志](CHAP_Monitoring.md#CHAP_Monitoring.ManagingLogs)。
+ **SORTER 消息**：这表明 DMS 正在缓存复制实例上的事务。有关更多信息，请参阅下面的[任务日志中的 SORTER 消息](CHAP_Troubleshooting_Latency_Target.md#CHAP_Troubleshooting_Latency_Target_Sorter)。
+ **调试任务日志**：如果 DMS 中断了读取进程，则您的任务会将以下消息重复写入调试任务日志，而不会更改上下文字段或时间戳：
+ **Binary Reader**：
```
[SOURCE_CAPTURE ]T: Produce CTI event:
context '00000020.f23ec6e5.00000002.000a.00.0000:190805.3477731.16'
xid [00000000001e0018] timestamp '2021-07-19 06:57:55'
thread 2 (oradcdc_oralog.c:817)
```
+ **Logminer**：
```
[SOURCE_CAPTURE ]T: Produce INSERT event:
object id 1309826 context '000000000F2CECAA010000010005A8F500000275016C0000000000000F2CEC58'
xid [000014e06411d996] timestamp '2021-08-12 09:20:32' thread 1 (oracdc_reader.c:2269)
```
+ AWS DMS 为每个新的重做或存档日志操作记录以下消息。
```
00007298: 2021-08-13T22:00:34 [SOURCE_CAPTURE ]I: Start processing archived Redo log sequence 14850 thread 2 name XXXXX/XXXXX/ARCHIVELOG/2021_08_14/thread_2_seq_14850.22977.1080547209 (oradcdc_redo.c:754)
```
如果源有新的重做或归档日志操作， AWS DMS 并且没有将这些消息写入日志，则表示该任务没有处理事件。
## 重做生成速率高
如果您的任务正在处理重做或存档日志，但源延迟仍然很高，请尝试确定重做日志的生成速率和生成模式。如果您有很高的重做日志生成水平，这会增加源延迟，因为任务会读取所有重做和存档日志，以便提取与复制的表相关的更改。
要确定重做生成速率，请使用以下查询。
+ 每日重做生成速率：
```
select trunc(COMPLETION_TIME,'DD') Day, thread#,
round(sum(BLOCKS*BLOCK_SIZE)/1024/1024/1024) GB,
count(*) Archives_Generated from v$archived_log
where completion_time > sysdate- 1
group by trunc(COMPLETION_TIME,'DD'),thread# order by 1;
```
+ 每小时重做生成速率：
```
Alter session set nls_date_format = 'DD-MON-YYYY HH24:MI:SS';
select trunc(COMPLETION_TIME,'HH') Hour,thread# ,
round(sum(BLOCKS*BLOCK_SIZE)/1024/1024) "REDO PER HOUR (MB)",
count(*) Archives from v$archived_log
where completion_time > sysdate- 1
group by trunc(COMPLETION_TIME,'HH'),thread# order by 1 ;
```
在此场景中要排除延迟问题，请检查以下内容：
+ 检查网络带宽和复制的单线程性能，确保底层网络可以支持源重做生成速率。有关网络带宽如何影响复制性能的信息，请参见前文中的[网络速度和带宽](CHAP_Troubleshooting_Latency.md#CHAP_Troubleshooting_Latency_Causes_Replication_Network)。
+ 检查您是否正确设置了补充日志记录。请避免在源上进行额外的日志记录，例如在表的所有列上启用日志记录。有关设置补充日志记录的信息，请参阅[设置补充日志记录](CHAP_Source.Oracle.md#CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging)。
+ 确认您使用了正确的 API 来读取重做或归档日志。您可以使用 Oracle LogMiner 或 AWS DMS 二进制阅读器。 LogMiner 读取在线重做日志和存档的重做日志文件时，Binary Reader 会直接读取和解析原始重做日志文件。因此，Binary Reader 的性能更高。如果您的重做日志生成速率超过 10 GB/小时，建议您使用 Binary Reader。有关更多信息，请参阅 [在 CDC 中使用 Oracle LogMiner 或 AWS DMS 二进制阅读器](CHAP_Source.Oracle.md#CHAP_Source.Oracle.CDC)。
+ 检查 `ArchivedLogsOnly` 是否设置为 `Y`。如果设置了此端点设置，则 AWS DMS 会从存档重做日志进行读取。这会增加源延迟，因为要 AWS DMS 等待在线重做日志存档后再读取。有关更多信息，请参阅 [ArchivedLogsOnly](https://docs.aws.amazon.com/dms/latest/APIReference/API_OracleSettings.html#DMS-Type-OracleSettings-ArchivedLogsOnly)。
+ 如果您的 Oracle 源使用自动存储管理（ASM），有关如何正确配置数据存储的信息，请参阅 [使用 Oracle 作为源时在 Oracle ASM 上存储 REDO AWS DMS](CHAP_Source.Oracle.md#CHAP_Source.Oracle.REDOonASM)。您还可以使用 `asmUsePLSQLArray` 额外连接属性（ECA）进一步优化读取性能。有关使用 `asmUsePLSQLArray` 的信息，请参阅 [使用 Oracle 作为来源时的终端节点设置 AWS DMS](CHAP_Source.Oracle.md#CHAP_Source.Oracle.ConnectionAttrib)。
# MySQL 端点故障排除
本节包含特定于 MySQL 的复制方案。 AWS DMS 定期扫描 MySQL 二进制日志以复制更改。以下情况下，此过程可能会增加延迟：
**Topics**
+ [源上长时间运行的事务](#CHAP_Troubleshooting_Latency_Source_MySQL_Longrunning)
+ [源端工作负载过高](#CHAP_Troubleshooting_Latency_Source_MySQL_Highworkload)
+ [二进制日志争用](#CHAP_Troubleshooting_Latency_Source_MySQL_Binarylog)
## 源上长时间运行的事务
由于 MySQL 仅将已提交的事务写入二进制日志，因此长时间运行的事务会导致与查询运行时间成比例的延迟峰值。
要识别长时间运行的事务，请使用以下查询或使用慢速查询日志：
```
SHOW FULL PROCESSLIST;
```
有关使用慢速查询日志的信息，请参阅 [MySQL 文档](https://dev.mysql.com/doc/)中的[慢速查询日志](https://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html)。
为避免长时间运行的事务导致延迟峰值，请重构源事务，以缩短查询运行时间或增加提交频率。
## 源端工作负载过高
由于 DMS CDC 是单线程的，因此大量事务会增加源延迟。要确定源延迟是否由于工作负载繁重而造成，请将出现延迟期间生成的二进制日志的数量和大小，与出现延迟之前生成的日志的数量和大小进行比较。要检查二进制日志和 DMS CDC 线程状态，请使用以下查询：
```
SHOW BINARY LOGS;
SHOW PROCESSLIST;
```
有关 CDC 二进制日志转储线程状态的更多信息，请参阅[复制源线程状态](https://dev.mysql.com/doc/refman/8.0/en/source-thread-states.html)。
您可以将源上生成的最新二进制日志位置与 DMS 当前正在处理的事件进行比较来确定延迟。要确定源上最新的二进制日志，请执行以下操作：
+ 在 SOURCE\$1CAPTURE 组件上启用调试日志。
+ 从任务调试日志中，检索 DMS 处理二进制日志和位置详细信息。
+ 使用以下查询来确定源上最新的二进制日志：
```
SHOW MASTER STATUS;
```
要进一步优化性能，请调整 `EventsPollInterval`. 默认情况下，DMS 每 5 秒轮询一次二进制日志，但您可以通过降低此频率来提高性能。有关 `EventsPollInterval` 设置的更多信息，请参阅[使用 MySQL 作为来源时的端点设置 AWS DMS](CHAP_Source.MySQL.md#CHAP_Source.MySQL.ConnectionAttrib)。
## 二进制日志争用
迁移包含大量数据的多个表时，对于 MySQL 5.7.2 或更高版本，建议将表拆分为单独的任务。在 MySQL 5.7.2 及更高版本中，主转储线程创建的锁争用较少并提高了吞吐量。因此，转储线程在读取事件时不再锁定二进制日志。这意味着多个转储线程可以同时读取二进制日志文件。这还意味着转储线程可以在客户端写入二进制日志时读取二进制日志。有关转储线程的更多信息，请参阅[复制线程](https://dev.mysql.com/doc/refman/8.0/en/replication-threads.html)和 [MySQL 5.7.2 发行说明](https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-2.html)。
对于 5.7.2 之前版本的 MySQL 源，要提高复制性能，请尝试使用 CDC 组件整合任务。
# PostgreSQL 端点故障排除
本节包含特定于 PostgreSQL 的复制场景。
**Topics**
+ [源上长时间运行的事务](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Longrunning)
+ [源端工作负载过高](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highworkload)
+ [高网络吞吐量](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highnetwork)
+ [Aurora PostgreSQL 中的溢出文件](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Spill)
## 源上长时间运行的事务
当源数据库中有长时间运行的事务（例如单个事务中有几千次插入）时，在事务完成之前，DMS CDC 事件和事务计数器不会增加。这种延迟可能会导致延迟问题，您可以使用 `CDCLatencyTarget` 指标来衡量。
要查看长期运行的事务，请执行以下操作之一：
+ 使用 `pg_replication_slots` 视图。如果该`restart_lsn`值未更新，PostgreSQL 很可能因为长期处于活动状态的事务而无法发布 Write Ahead Logs WALs ()。有关 `pg_replication_slots` 视图的信息，请参阅 [PostgreSQL 15.4 文档](https://www.postgresql.org/docs/15/)中的 [pg\$1replication\$1slots](https://www.postgresql.org/docs/15/view-pg-replication-slots.html)。
+ 使用以下查询返回数据库中所有活动查询的列表以及相关信息：
```
SELECT pid, age(clock_timestamp(), query_start), usename, query
FROM pg_stat_activity WHERE query != ''
AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;
```
在查询结果中，`age` 字段显示每个查询的活动时长，您可以使用该时长来确定长时间运行的查询。
## 源端工作负载过高
如果您的源 PostgreSQL 的工作负载很高，请检查以下事项以减少延迟：
+ 使用 `test_decoding` 插件，从具有高每秒事务数（TPS）值的源数据库迁移表的子集时，您可能会遇到高延迟。这是因为 `test_decoding` 插件会将所有数据库更改发送到复制实例，然后 DMS 会根据任务的表映射对这些更改进行筛选。不属于任务表映射的表中的事件可能会增加源延迟。
+ 使用以下方法之一检查 TPS 吞吐量。
+ 对于 Aurora PostgreSQL 来源，请使用该指标。`CommitThroughput` CloudWatch
+ 对于在 Amazon RDS 或本地运行的 PostgreSQL，请通过 PSQL 客户端版本 11 或更高版本使用以下查询（在查询期间按 **enter** 可显示结果进度）：
```
SELECT SUM(xact_commit)::numeric as temp_num_tx_ini FROM pg_stat_database; \gset
select pg_sleep(60);
SELECT SUM(xact_commit)::numeric as temp_num_tx_final FROM pg_stat_database; \gset
select (:temp_num_tx_final - :temp_num_tx_ini)/ 60.0 as "Transactions Per Second";
```
+ 为了减少使用 `test_decoding` 插件时的延迟，请考虑改为使用 `pglogical` 插件。与 `test_decoding` 插件不同，`pglogical` 插件会筛选源端的预写日志（WAL）更改，并且仅将相关更改发送到复制实例。有关将`pglogical`插件与一起使用的信息 AWS DMS，请参阅[配置 pglogical 插件](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.Security.Pglogical)。
## 高网络吞吐量
使用 `test_decoding` 插件时，您的复制可能会占用大量的网络带宽，尤其是在有大量事务期间。这是因为 `test_decoding` 插件会处理更改，并将它们转换为人类可读格式，这比原始二进制格式更大。
为了提高性能，请考虑改用 `pglogical` 插件，它是一个二进制插件。与 `test_decoding` 插件不同，`pglogical` 插件生成二进制格式的输出，从而导致压缩的预写日志（WAL）流更改。
## Aurora PostgreSQL 中的溢出文件
在 PostgreSQL 版本 13 及更高版本中，`logical_decoding_work_mem` 参数决定了用于解码和流式传输的内存分配。有关 `logical_decoding_work_mem` 参数的更多信息，请参阅 [PostgreSQL 13.13 文档](https://www.postgresql.org/docs/13/)中的 [PostgreSQL 中的资源消耗量](https://www.postgresql.org/docs/13/runtime-config-resource.html#GUC-LOGICAL-DECODING-WORK-MEM)。
逻辑复制会累积内存中所有事务的更改，直到这些事务提交为止。如果所有事务中存储的数据量超过数据库参数 `logical_decoding_work_mem` 指定的量，则 DMS 会将事务数据溢出到磁盘，以便为新的解码数据腾出内存空间。
长时间运行的事务或许多子事务可能会导致 DMS 占用更多的逻辑解码内存。内存使用量的增加会导致 DMS 在磁盘上创建溢出文件，从而导致复制期间源延迟很高。
要减少源工作负载增加所带来的影响，请执行以下操作：
+ 减少长时间运行的事务。
+ 减少子事务数。
+ 避免执行会生成大量日志记录的操作，例如在单个事务中删除或更新整个表。改为以较小的批量执行操作。
您可以使用以下 CloudWatch 指标来监控源上的工作负载：
+ `TransactionLogsDiskUsage`：逻辑 WAL 当前占用的字节数。如果逻辑复制槽无法跟上新写入数据的步伐，或者如果任何长时间运行的事务阻碍对旧文件进行垃圾回收，则此值会单调增加。
+ `ReplicationSlotDiskUsage`：逻辑复制插槽当前使用的磁盘空间量。
您可以通过调整 `logical_decoding_work_mem` 参数来减少源延迟。此参数的默认值为 64 MB。此参数限制每个逻辑流复制连接使用的内存量。建议将 `logical_decoding_work_mem` 值设置为显著高于 `work_mem` 值，以减少 DMS 写入磁盘的解码更改量。
建议定期检查溢出文件，尤其是在迁移活动繁忙或延迟期间。如果 DMS 正在创建大量溢出文件，则意味着逻辑解码的运行效率低下，可能会增加延迟。要缓解这种情况，请增加 `logical_decoding_work_mem` 参数值。
您可以使用 `aurora_stat_file` 函数检查当前事务溢出量。有关更多信息，请参阅《Amazon Relational Database Service 开发人员指南》**中的[调整工作内存以进行逻辑解码](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.html#AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.logical-decoding-work-mem)。
# SQL Server 端点故障排除
本节包含特定于 SQL Server 的复制场景。要确定要从 SQL Server 复制哪些更改，请 AWS DMS 读取事务日志，并对源数据库进行定期扫描。复制延迟通常是因为资源有限，SQL Server 限制这些扫描所导致。这也可能是由于短时间内写入事务日志的事件数量显著增加所导致。
**Topics**
+ [索引重建](#CHAP_Troubleshooting_Latency_Source_SQLServer_Indexrebuilds)
+ [大型事务](#CHAP_Troubleshooting_Latency_Source_SQLServer_Largetransactions)
+ [Amazon RDS SQL Server 的 MS-CDC 轮询间隔配置错误](#CHAP_Troubleshooting_Latency_Source_SQLServer_MisconfiguredCDC)
+ [从同一个源数据库复制多个 CDC 任务](#CHAP_Troubleshooting_Latency_Source_SQLServer_MultipleCDC)
+ [针对 RDS for SQL Server 的事务日志备份处理](#CHAP_Troubleshooting_Latency_Source_SQLServer_backup)
## 索引重建
SQL Server 在重建大型索引时使用单个事务。这会生成大量事件，如果 SQL Server 同时重建多个索引，就可能会占用大量日志空间。发生这种情况时，可以预计会出现短暂的复制高峰。如果您的 SQL Server 源持续出现日志峰值，请检查以下内容：
+ 首先，使用`CDCLatencySource`和`CDCLatencySource` CloudWatch 指标或通过查看任务日志中的吞吐量监控消息来检查延迟峰值的时间段。有关 CloudWatch 指标的信息 AWS DMS，请参阅[复制任务指标](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.Task)。
+ 检查在延迟高峰期间，活动事务日志或日志备份的大小是否增加。还要检查在这段时间内是否运行了维护作业或重建。有关检查事务日志大小的信息，请参阅 [SQL Server 技术文档](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16)中的[监控日志空间使用情况](https://learn.microsoft.com/en-us/sql/relational-databases/logs/manage-the-size-of-the-transaction-log-file?view=sql-server-ver16#MonitorSpaceUse)。
+ 验证您的维护计划是否符合 SQL Server 最佳实践。有关 SQL Server 维护最佳实践的信息，请参阅 [SQL Server 技术文档](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16)中的[索引维护策略](https://learn.microsoft.com/en-us/sql/relational-databases/indexes/reorganize-and-rebuild-indexes?view=sql-server-ver16#index-maintenance-strategy)。
要修复索引重建期间延迟问题，请尝试以下操作：
+ 使用 `BULK_LOGGED` 恢复模式进行离线重建，以减少任务必须处理的事件。
+ 如果可能，请在索引重建期间停止任务。或者，尝试将索引重建安排在非高峰时段，以减轻延迟峰值的影响。
+ 尝试找出导致 DMS 读取速度减慢的资源瓶颈，例如磁盘延迟或 I/O 吞吐量，并加以解决。
## 大型事务
具有大量事件的事务或长时间运行的事务会导致事务日志增长。这会导致 DMS 读取时间更长，从而产生延迟。这类似于索引重建对复制性能的影响。
如果您不熟悉源数据库上的典型工作负载，则可能很难识别此问题。要排除此问题，请执行以下操作：
+ 首先，使用`ReadThroughput`和`WriteThroughput` CloudWatch 指标或通过查看任务日志中的吞吐量监控消息来确定延迟激增的时间。
+ 检查源数据库上在延迟高峰期间是否有任何长时间运行的查询。有关长时间运行的查询的信息，请参阅 [SQL Server 技术文档](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16)中的 [SQL Server 中运行缓慢的查询故障排除](https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/performance/troubleshoot-slow-running-queries)。
+ 检查活动事务日志或日志备份的大小是否增加。有关更多信息，请参阅 [SQL Server 技术文档](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16)中的[监控日志空间使用情况](https://learn.microsoft.com/en-us/sql/relational-databases/logs/manage-the-size-of-the-transaction-log-file?view=sql-server-ver16#MonitorSpaceUse)。
要修复这个问题，请执行以下操作之一：
+ 最好的解决办法是在应用程序端重构您的事务，使它们能够快速完成。
+ 如果您无法重构事务，则短期解决方法是检查是否存在资源瓶颈，例如磁盘等待或 CPU 争用。如果您发现源数据库中存在瓶颈，则可以通过增加源数据库的磁盘、CPU 和内存资源来减少延迟。这可减少系统资源的争用，使得 DMS 查询可以更快地完成。
## Amazon RDS SQL Server 的 MS-CDC 轮询间隔配置错误
Amazon RDS 实例上错误配置的轮询间隔设置可能会导致事务日志增长。这是因为复制会防止日志截断。虽然正在运行的任务可能会以最小的延迟继续复制，但停止和恢复任务或启动仅 CDC 的任务会导致任务失败。这是由于扫描大型事务日志时超时所造成。
要排除错误配置的轮询间隔，请执行以下操作：
+ 检查活动的事务日志大小是否在增加，以及日志使用率是否接近 100%。有关更多信息，请参阅 [SQL Server 技术文档](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16)中的[监控日志空间使用情况](https://learn.microsoft.com/en-us/sql/relational-databases/logs/manage-the-size-of-the-transaction-log-file?view=sql-server-ver16#MonitorSpaceUse)。
+ 检查日志截断是否延迟，并且 `log_reuse_wait_desc value` 为 `REPLICATION`。有关更多信息，请参阅 [SQL Server 技术文档](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16)中的[事务日志（SQL Server）](https://learn.microsoft.com/en-us/sql/relational-databases/logs/the-transaction-log-sql-server?view=sql-server-ver16#FactorsThatDelayTruncation)。
如果您发现前面列表中的任何项目有问题，请调整 MS-CDC 轮询间隔。有关调整轮询间隔的信息，请参阅[使用适用于 SQL Server 的 RDS 作为来源时的推荐设置 AWS DMS](CHAP_Source.SQLServer.CDC.md#CHAP_Source.SQLServer.Configuration.Settings)。
## 从同一个源数据库复制多个 CDC 任务
在完全加载阶段，我们建议在任务之间拆分表以提高性能，以逻辑方式分隔依赖表，并减轻任务失败的影响。但是，在 CDC 阶段，我们建议整合任务以尽可能减少 DMS 扫描。在 CDC 阶段，每个 DMS 任务每分钟都会扫描几次事务日志以查找新事件。由于每个任务都是独立运行的，因此每个任务都会单独扫描每个事务日志。这会增加源 SQL Server 数据库的磁盘和 CPU 使用率。因此，大量并行运行的任务可能会导致 SQL Server 限制 DMS 读取，从而导致延迟增加。
如果有多个任务逐步开始，您可能很难确定此问题。此问题最常见的症状是大多数任务扫描开始需要花费更长的时间。这会导致这些扫描的延迟更高。SQL Server 会优先处理一些任务扫描，因此其中一些任务显示正常延迟。要排除此问题，请检查所有任务的 `CDCLatencySource` 指标。如果有些任务的 `CDCLatencySource` 增加，而少数几个任务的 `CDCLatencySource` 较低，则很可能是 SQL Server 限制了某些任务的 DMS 读取。
如果 SQL Server 在 CDC 期间限制任务读取，请整合任务以尽可能减少 DMS 扫描次数。可以连接到源数据库而不造成争用的最大任务数取决于源数据库容量、事务日志增长速率或表数量等因素。要确定复制场景的理想任务数量，请在与生产环境相似的测试环境中测试复制。
## 针对 RDS for SQL Server 的事务日志备份处理
AWS DMS 3.5.3 及更高版本支持从 RDS 复制 SQL Server 日志备份。从 RDS 实例上的备份日志中复制事件比从活动事务日志中复制事件要慢。这是因为 DMS 按顺序请求访问备份，以确保其保持事务顺序，并尽可能地降低 Amazon RDS 实例存储空间被填满的风险。此外，在 Amazon RDS 端，向 DMS 提供备份所需的时间因日志备份的大小以及 RDS for SQL Server 实例上的负载而异。
由于这些限制，我们建议您将 ECA `ActivateSafeguard` 设置为 `true`。这可确保 DMS 任务在读取活动事务日志时不会备份事务。当 DMS 从备份中读取事务时，此设置还可防止 Amazon RDS 将事务归档到活动日志中，从而消除了 DMS 无法赶上活动日志步伐的可能性。请注意，这可能会导致在任务赶上步伐时活动日志大小增加。确保您的实例有足够的存储空间以防止实例空间不足。
对于从 RDS for SQL Server 源复制的仅 CDC 任务，请尽可能使用本机 CDC 开始位置而不是本机 CDC 开始时间。这是因为 DMS 依靠系统表来识别本机开始位置的起点，而不是在您指定本机开始时间时扫描单个日志备份。
# 排除目标延迟问题
本节包含可能导致目标延迟的场景。
**Topics**
+ [索引问题](#CHAP_Troubleshooting_Latency_Target_Indexing)
+ [任务日志中的 SORTER 消息](#CHAP_Troubleshooting_Latency_Target_Sorter)
+ [数据库锁定](#CHAP_Troubleshooting_Latency_Target_Locking)
+ [LOB 查找缓慢](#CHAP_Troubleshooting_Latency_Target_LOB)
+ [多可用区、审计日志记录和备份](#CHAP_Troubleshooting_Latency_Target_MultiAZ)
## 索引问题
在 CDC 阶段，通过在 AWS DMS 目标系统上执行 DML 语句（插入、更新和删除）来复制源上的更改。对于使用 DMS 的异构迁移，源端和目标端在索引优化方面的不同，可能会需要导致花费更长的时间写入目标系统。这会引发目标延迟和性能问题。
要排除此索引问题，请执行以下操作：这些步骤的过程因不同的数据库引擎而异。
+ 监控目标数据库的查询时间。比较目标和源上的查询执行时间可以指明哪些索引需要优化。
+ 为运行缓慢的查询启用日志记录。
要修复长时间运行复制的索引问题，请执行以下操作：
+ 调整源数据库和目标数据库上的索引，使源数据库和目标数据库上具有相似的查询执行时间。
+ 比较源和目标的 DML 查询中使用的二级索引。确保目标上的 DML 性能与源 DML 性能相当或更好。
请注意，优化索引的过程特定于数据库引擎。没有用于调整源索引和目标索引的 DMS 功能。
## 任务日志中的 SORTER 消息
如果目标端点无法跟上 AWS DMS 写入其中的更改量，则该任务会在复制实例上缓存更改。如果缓存的增长大于内部阈值，则任务将停止从源读取更多的更改。DMS 这样做是为了防止复制实例的存储空间不足，或者在读取大量待处理事件时任务停滞不前。
要解决此问题，请检查 CloudWatch 日志中是否有类似于以下任一内容的消息：
```
[SORTER ]I: Reading from source is paused. Total disk usage exceeded the limit 90% (sorter_transaction.c:110)
[SORTER ]I: Reading from source is paused. Total storage used by swap files exceeded the limit 1048576000 bytes (sorter_transaction.c:110)
```
如果您的日志包含的消息与第一条消息类似，请禁用该任务的所有跟踪日志记录，并增加复制实例存储空间。有关增加复制实例存储空间的信息，请参阅[修改复制实例](CHAP_ReplicationInstance.Modifying.md)。
如果日志包含的消息与第二条消息类似，请执行以下操作：
+ 如果包含大量事务或长时间运行 DML 操作的表，与任务中的其他表没有任何依赖关系，则将其移至单独的任务中。
+ 增加 `MemoryLimitTotal` 和 `MemoryKeepTime` 的设置，使事务在内存中保留更长的时间。如果延迟一直保持较高，则这种方法没有帮助，但它有助于在短暂的交易量突发期间降低延迟。有关这些任务设置的信息，请参阅[更改处理优化设置](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md)。
+ 通过将 `BatchApplyEnabled` 设置为 `true`，评估是否可以对事务使用批量应用。有关 `BatchApplyEnabled` 设置的信息，请参阅[目标元数据任务设置](CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.md)。
## 数据库锁定
如果应用程序访问用作复制目标的数据库， AWS DMS 则该应用程序可能会锁定 DMS 正在尝试访问的表。这会导致锁争用。由于 DMS 按照更改在源数据库上的发生顺序将更改写入目标数据库，因此由于锁争用而导致写入一个表出现延迟，会导致写入所有表出现延迟。
要排除此问题，请查询目标数据库以检查锁争用是否在阻止 DMS 写入事务。如果目标数据库阻止 DMS 写入事务，请执行以下一项或多项操作：
+ 重构查询以更频繁地提交更改。
+ 修改您的锁定超时设置。
+ 对表进行分区以尽可能减少锁争用。
请注意，优化锁争用的过程特定于数据库引擎。没有可用于调整锁争用的 DMS 功能。
## LOB 查找缓慢
AWS DMS 复制大型对象 (LOB) 列时，它会在向目标写入更改之前对源执行查找。这种查找通常不会在目标上造成任何延迟，但是如果源数据库由于锁定而导致查找的延迟，则可能会出现目标延迟峰值。
这个问题通常很难诊断。要排除此问题，请在任务日志上启用详细调试，并比较 DMS LOB 查找调用的时间戳。有关启用详细调试的信息，请参阅[查看和管理 AWS DMS 任务日志](CHAP_Monitoring.md#CHAP_Monitoring.ManagingLogs)。
要修复这一问题，请尝试以下操作：
+ 提高源数据库上的 SELECT 查询性能。
+ 调整 DMS LOB 设置。有关调整 LOB 设置的更多信息，请参阅[迁移大型二进制对象 (LOBs)](CHAP_BestPractices.md#CHAP_BestPractices.LOBS)。
## 多可用区、审计日志记录和备份
对于 Amazon RDS 目标，在以下情况中目标延迟可能会增加：
+ 备份
+ 启用多可用区（Multi-AZ）后
+ 启用数据库日志记录后，例如审计日志或慢速查询日志。
这些问题通常很难诊断。要排除这些问题，请监控在 Amazon RDS 维护时段或数据库负载繁重期间，延迟的周期性峰值。
要修复这些问题，请尝试以下操作：
+ 如果可能，在短期迁移期间，请禁用多可用区、备份或日志记录。
+ 将维护时段重新安排到活动量较低的时段。