本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# SQL Server 端點疑難排解
<a name="CHAP_Troubleshooting_Latency_Source_SQLServer"></a>

本節包含 SQL Server 特定的複寫案例。若要判斷要從 SQL 伺服器複寫哪些變更會 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 輪詢間隔。如需調整輪詢間隔的相關資訊，請參閱[使用 RDS for SQL Server 做為 來源時的建議設定 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 for 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 依賴系統資料表來識別原生開始位置的起點，而不是在您指定原生開始時間時掃描個別日誌備份。