本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# SQL Server 端点故障排除
<a name="CHAP_Troubleshooting_Latency_Source_SQLServer"></a>

本节包含特定于 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)

## 索引重建
<a name="CHAP_Troubleshooting_Latency_Source_SQLServer_Indexrebuilds"></a>

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 吞吐量，并加以解决。

## 大型事务
<a name="CHAP_Troubleshooting_Latency_Source_SQLServer_Largetransactions"></a>

具有大量事件的事务或长时间运行的事务会导致事务日志增长。这会导致 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 轮询间隔配置错误
<a name="CHAP_Troubleshooting_Latency_Source_SQLServer_MisconfiguredCDC"></a>

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 任务
<a name="CHAP_Troubleshooting_Latency_Source_SQLServer_MultipleCDC"></a>

在完全加载阶段，我们建议在任务之间拆分表以提高性能，以逻辑方式分隔依赖表，并减轻任务失败的影响。但是，在 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 的事务日志备份处理
<a name="CHAP_Troubleshooting_Latency_Source_SQLServer_backup"></a>

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 依靠系统表来识别本机开始位置的起点，而不是在您指定本机开始时间时扫描单个日志备份。