本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 針對延時問題進行疑難排解
本節包含複寫延時的疑難排解步驟。
若要針對延時進行疑難排解，請執行以下動作：
+ 首先，確定任務的延時類型和數量。從 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 來源讀取。此行為是依據設計。您可以使用任務日誌來調查造成此問題的原因。在任務日誌中尋找類似下列內容的訊息。如需使用任務日誌的相關資訊，請參閱[檢視和管理 DMS AWS 任務日誌](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 Binary Reader。LogMiner 讀取線上還原日誌和封存還原日誌檔時，Binary Reader 會直接讀取並剖析原始還原日誌檔。因此 Binary Reader 的效能更佳。如果還原日誌產生每小時超過 10 GB，建議您使用 Binary Reader。如需詳細資訊，請參閱[使用 Oracle LogMiner 或 AWS DMS Binary Reader for CDC](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 來源使用 Automatic Storage Management (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 scans 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 可能無法釋出預先寫入日誌 (WAL)。如需 `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 文件中的 PostgreSQL 中的資源使用](https://www.postgresql.org/docs/13/runtime-config-resource.html#GUC-LOGICAL-DECODING-WORK-MEM)。 [ PostgreSQL ](https://www.postgresql.org/docs/13/)
邏輯複寫會累積記憶體中所有交易的變更，直到這些交易遞交為止。如果跨所有交易存放的資料量超過資料庫參數 指定的量`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 伺服器複寫哪些變更會 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 輪詢間隔。如需調整輪詢間隔的相關資訊，請參閱[使用 RDS for SQL Server 做為 來源時的建議設定 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 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 依賴系統資料表來識別原生開始位置的起點，而不是在您指定原生開始時間時掃描個別日誌備份。
# 針對目標延時問題進行疑難排解
本節包含可能導致目標延時的案例。
**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 階段期間， 會透過在目標上執行 DML 陳述式 （插入、更新和刪除） 來 AWS DMS 複寫來源的變更。對於使用 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 查詢呼叫的時間戳記。如需啟用詳細偵錯的相關資訊，請參閱[檢視和管理 DMS AWS 任務日誌](CHAP_Monitoring.md#CHAP_Monitoring.ManagingLogs)。
若要解決此問題，請嘗試下列步驟：
+ 改善來源資料庫上的 SELECT 查詢效能。
+ 調整 DMS LOB 設定。如需調整 LOB 設定的相關資訊，請參閱[遷移大型二進位物件 (LOB)](CHAP_BestPractices.md#CHAP_BestPractices.LOBS)。
## 異地同步備份、稽核記錄和備份
對於 Amazon RDS 目標，在下列情況下，目標延時可能會增加：
+ 備份
+ 在啟用多個可用區域 (異地同步備份) 之後
+ 啟用資料庫記錄 (例如稽核或慢速查詢記錄) 之後。
這些問題的診斷難度通常很高。若要針對這些問題進行疑難排解，請在 Amazon RDS 維護時段或資料庫負載繁重期間監控週期峰值的延時。
若要修正這些問題，請嘗試下列方法：
+ 如果可能，請在短期遷移期間，停用異地同步備份、備份或記錄。
+ 重新安排活動較不頻繁期間的維護期間。