翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# レイテンシーに関する問題のトラブルシューティング
このセクションでは、レプリケーションレイテンシーのトラブルシューティングの手順を説明します。
レイテンシーのトラブルシューティングを行うには、次を実行します。
+ まず、タスクのレイテンシーのタイプと量を判断します。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` が高く、`CDCLatencySource` が `CDCLatencyTarget` よりも大幅に高い場合、ソース読み取りとターゲット書き込みの両方でボトルネックが発生していることを示しています。まずソースのレイテンシーを調べてから、ターゲットのレイテンシーを調査します。
DMS タスクメトリクスのモニタリングの詳細については、「[DMS AWS タスクのモニタリング](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 は、新しい REDO またはアーカイブされたログオペレーションごとに次のメッセージをログに記録します。
```
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)
```
ソースに新しい REDO またはアーカイブされたログオペレーションがあり、これらのメッセージをログに書き込んで AWS DMS いない場合、タスクがイベントを処理していないことを意味します。
## 大量の REDO 生成
タスクが REDO ログまたはアーカイブされたログを処理しているものの、ソースのレイテンシーが依然として高い場合は、REDO ログの生成速度と生成パターンを特定します。REDO ログの生成レベルが高い場合は、レプリケートしたテーブルに関連する変更をフェッチするタスクが REDO ログとアーカイブログをすべて読み取るため、ソースのレイテンシーが増大します。
REDO 生成率を判断するには、次のクエリを使用します。
+ 1 日あたりの REDO 生成率:
```
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;
```
+ 1 時間あたりの REDO 生成率:
```
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 ;
```
このシナリオでレイテンシーのトラブルシューティングを行うには、次の点を確認します。
+ レプリケーションのネットワーク帯域幅とシングルスレッドのパフォーマンスを調べて、基盤となるネットワークがソースの REDO 生成速度をサポートできることを確認します。ネットワーク帯域幅によるレプリケーションのパフォーマンスへの影響の詳細については、前の「[ネットワーク速度と帯域幅](CHAP_Troubleshooting_Latency.md#CHAP_Troubleshooting_Latency_Causes_Replication_Network)」を参照してください。
+ 補足ログが適切に設定されているかを確認します。テーブルのすべての列でログを有効にするなど、ソースでの余分なログ記録は避けます。補足ログの設定の詳細については、「[サプリメンタル ロギングの設定](CHAP_Source.Oracle.md#CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging)」を参照してください。
+ REDO ログまたはアーカイブされたログを読み取るために適切な API を使用していることを確認します。Oracle LogMiner または AWS DMS Binary Reader のいずれかを使用できます。LogMiner はオンラインの REDO ログとアーカイブされた REDO ログファイルを読み取ります。Binary Reader は raw REDO ログファイルを直接読み取り、解析します。このため、Binary Reader を使用するとパフォーマンスが向上します。REDO ログの生成が 1 時間あたり 10 GBを超える場合は、Binary Reader を使用することをお勧めします。詳細については、「[CDC での Oracle LogMiner または AWS DMS Binary Reader の使用](CHAP_Source.Oracle.md#CHAP_Source.Oracle.CDC)」を参照してください。
+ `ArchivedLogsOnly` を `Y` に設定しているかを確認します。このエンドポイント設定が指定されている場合、 AWS DMS はアーカイブされた REDO ログから読み取ります。これにより、 は読み取り前にオンライン REDO ログがアーカイブされるのを 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)」を参照してください。追加接続属性(ECA) `asmUsePLSQLArray` を使用して、読み取りパフォーマンスをさらに最適化できる場合もあります。`asmUsePLSQLArray` の使用の詳細については、「[のソースとして Oracle を使用する場合のエンドポイント設定 AWS DMS](CHAP_Source.Oracle.md#CHAP_Source.Oracle.ConnectionAttrib)」を参照してください。
# MySQL エンドポイントのトラブルシューティング
このセクションでは、MySQL に固有のレプリケーションシナリオについて説明します。 は MySQL バイナリログを定期的に AWS DMS スキャンして、変更をレプリケートします。このプロセスにより、次のシナリオでレイテンシーが増大する可能性があります。
**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/)」の「[The Slow Query Log](https://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html)」を参照してください。
長時間実行されるトランザクションによるレイテンシーのスパイクを回避するには、ソーストランザクションを再構築してクエリの実行時間を短縮するか、コミット頻度を増やします。
## ソースでの高ワークロード
DMS CDC はシングルスレッドであるため、トランザクション数が多いとソースのレイテンシーが増大する可能性があります。ワークロードが重いことがソースのレイテンシーの原因であるかを特定するには、レイテンシー中に生成されたバイナリログの数とサイズをレイテンシー以前に生成されたログと比較します。バイナリログと DMS CDC スレッドのステータスを確認するには、次のクエリを使用します。
```
SHOW BINARY LOGS;
SHOW PROCESSLIST;
```
CDC バイナリログのダンプスレッドの状態の詳細については、「[Replication Source Thread States](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 以降では、マスターダンプスレッドによるロック競合が低減し、スループットが向上しています。その結果、ダンプスレッドはイベントを読み取る都度バイナリログをロックすることがなくなりました。つまり、複数のダンプスレッドがバイナリログファイルを同時に読み取ることができるようになりました。これは、クライアントがバイナリログに書き込みを行っている間も、ダンプスレッドがバイナリログを読み取ることができることも意味します。ダンプスレッドの詳細については、「[Replication Threads](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 のワークロードが高い場合は、次の点を確認してレイテンシーを低減します。
+ 1 秒あたりのトランザクション (TPS) 値が高いソースデータベースからテーブルのサブセットを移行する際に `test_decoding` プラグインを使用すると、レイテンシーが増大する可能性があります。これは、`test_decoding` プラグインがデータベースのすべての変更をレプリケーションインスタンスに送信し、DMS がタスクのテーブルマッピングに基づいてフィルタリングするためです。タスクのテーブルマッピングに含まれていないテーブルのイベントは、ソースレイテンシーを増大につながる可能性があります。
+ 次のいずれかの方法を使用して TPS スループットを確認します。
+ Aurora PostgreSQL ソースの場合、`CommitThroughput` CloudWatch メトリクスを使用します。
+ Amazon RDS またはオンプレミスで実行されている PostgreSQL の場合は、バージョン 11 以降の PSQL クライアントを使用して次のクエリを実行します (クエリ中に **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、「」を参照してください[pgglogical プラグインの設定](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 Documentation](https://www.postgresql.org/docs/13/)」の「[Resource Consumption in 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 です。このパラメータは、各論理ストリーミングレプリケーションの接続で使用されるメモリの量を制限します。DMS がディスクに書き込むデコードされた変更の量を減らすために、`logical_decoding_work_mem` 値を `work_mem` 値より大幅に大きく設定することをお勧めします。
特に重い移行アクティビティやレイテンシーの場合、定期的にスピルファイルをチェックすることをお勧めします。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` 復旧モデルを使用して、タスクが処理する必要があるイベントを減らします。
+ 可能な場合は、インデックスの再構築中はタスクを停止します。または、レイテンシーのスパイクの影響を軽減するために、インデックスの再構築をピーク時以外の時間帯でスケジュールします。
+ ディスクのレイテンシーや I/O スループットなど、DMS の読み取りを遅延させるリソースのボトルネックを特定し、対処します。
## 大きいトランザクション
大量のイベントがあるトランザクションや実行時間の長いトランザクションにより、トランザクションログのサイズが増大します。これにより DMS の読み取りに時間がかかり、レイテンシーが発生します。これは、インデックスの再構築がレプリケーションのパフォーマンスに与える影響と類似しています。
ソースデータベースの一般的なワークロードに慣れていない場合、この問題を特定するのが難しい場合があります。このエラーを解決するには、次を実行します。
+ まず、`WriteThroughput` と `ReadThroughput` の 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)」を参照してください。
+ ログの切り捨てが遅延していないかを `REPLICATION` の `log_reuse_wait_desc value` で確認します。詳細については、「[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 タスクが 1 分あたり数回トランザクションログをスキャンして新しいイベントを検索します。各タスクは独立して実行されるため、各タスクは各トランザクションログを個別にスキャンします。これにより、ソースの 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)
+ [マルチ AZ、監査ログ、バックアップ](#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)」を参照してください。
ログに 2 番目のメッセージと同様のメッセージが含まれている場合は、次を実行します。
+ 多数のトランザクションまたは長時間実行される 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 ルックアップが遅い
がラージオブジェクト (LOB) 列を AWS DMS レプリケートすると、ターゲットに変更を書き込む直前にソースの検索が実行されます。通常、このルックアップによってターゲットにレイテンシーが発生することはありません。ただし、ソースデータベースでのロックでルックアップが遅延した場合、ターゲットのレイテンシーのスパイクが発生する可能性があります。
この問題を診断するのは通常、困難です。この問題のトラブルシューティングを行うには、タスクログで詳細なデバッグを有効にして、DMS LOB ルックアップコールのタイムスタンプを比較します。詳細なデバッグを有効にする方法の詳細については、「[DMS AWS タスクログの表示と管理](CHAP_Monitoring.md#CHAP_Monitoring.ManagingLogs)」を参照してください。
この問題を解決するには、次を試します。
+ ソースデータベースの SELECT クエリのパフォーマンスを向上します。
+ DMS LOB 設定を調整します。LOB 設定の調整の詳細については、「[ラージバイナリオブジェクト (LOB) の移行](CHAP_BestPractices.md#CHAP_BestPractices.LOBS)」を参照してください。
## マルチ AZ、監査ログ、バックアップ
Amazon RDS ターゲットの場合、ターゲットレイテンシーは次の期間に増大する可能性があります。
+ バックアップ
+ 複数のアベイラビリティゾーン (マルチ AZ) を有効にした後
+ 監査ログやスロークエリログなどのデータベースログ記録を有効にした後。
このような問題を診断するのは通常、困難です。このような問題のトラブルシューティングを行うには、Amazon RDS のメンテナンス期間やデータベースの負荷が高い期間に周期的にスパイクが発生しないか、レイテンシーをモニタリングします。
このような問題を修正するには、次を実行します。
+ 可能な場合、短期間の移行中は、マルチ AZ、バックアップ、またはロギングを無効にします。
+ メンテナンスの時間帯をアクティビティが少ない時間帯に再スケジュールします。