翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 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` 復旧モデルを使用して、タスクが処理する必要があるイベントを減らします。
+ 可能な場合は、インデックスの再構築中はタスクを停止します。または、レイテンシーのスパイクの影響を軽減するために、インデックスの再構築をピーク時以外の時間帯でスケジュールします。
+ ディスクのレイテンシーや I/O スループットなど、DMS の読み取りを遅延させるリソースのボトルネックを特定し、対処します。

## 大きいトランザクション
<a name="CHAP_Troubleshooting_Latency_Source_SQLServer_Largetransactions"></a>

大量のイベントがあるトランザクションや実行時間の長いトランザクションにより、トランザクションログのサイズが増大します。これにより 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 ポーリング間隔が適切に設定されていない
<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)」を参照してください。
+ ログの切り捨てが遅延していないかを `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 タスク
<a name="CHAP_Troubleshooting_Latency_Source_SQLServer_MultipleCDC"></a>

フルロードフェーズでは、パフォーマンス向上、依存テーブルの論理的分離、タスク障害の影響の軽減のために、テーブルをタスク間で分割することをお勧めします。ただし、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 のトランザクションログのバックアップ処理
<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 がネイティブの開始時刻を指定するときに個々のログのバックアップをスキャンするのではなく、システムテーブルに依存してネイティブの開始位置の開始ポイントを特定するためです。