変更データ キャプチャとその他の機能
適用対象: 
SQL Server Azure SQL Managed Instance
この記事では、次の機能で SQL Server および Azure SQL Managed Instance の変更データ キャプチャとやり取りする方法について説明します。 Azure SQL Database については、「Azure SQL Database での CDC」を参照してください。
変更の追跡
変更データ キャプチャと 変更の追跡 は、同じデータベースで有効にすることができます。 特に注意が必要な点はありません。 詳細については、「変更の追跡のしくみ」を参照してください。
データベース ミラーリング
変更データ キャプチャが有効になっているデータベースをミラー化できます。 フェールオーバー後にキャプチャとクリーンアップが自動的に行われるようにするには、次の手順を実行します。
新しいプリンシパル サーバー インスタンスで SQL Server エージェントが実行されていることを確認します。
新しいプリンシパル データベース (以前のミラー データベース) にキャプチャ ジョブとクリーンアップ ジョブを作成します。 ジョブを作成するには、 sp_cdc_add_job ストアド プロシージャを使用します。
クリーンアップまたはキャプチャ ジョブの現在の構成を表示するには、新しいプリンシパル サーバー インスタンスで sys.sp_cdc_help_jobs ストアド プロシージャを使用します。 特定のデータベースに対し、キャプチャ ジョブの名前は cdc.database_name_capture に、クリーンアップ ジョブの名前は cdc.database_name_cleanup になります ( database_name はデータベースの名前)。
ジョブの構成を変更するには、 sys.sp_cdc_change_job ストアド プロシージャを使用します。
データベース ミラーリングの詳細については、「データベース ミラーリング (SQL Server)」を参照してください。
トランザクション レプリケーション
変更データ キャプチャとトランザクション レプリケーションは、同じデータベースで共存できます。ただし、両方の機能が有効になっている場合、変更テーブルが異なる方法で作成されます。 変更データ キャプチャとトランザクション レプリケーションでは、トランザクション ログから変更を読み取る際に、常に同じプロシージャ ( sp_replcmds) が使用されます。 変更データ キャプチャのみが有効になっている場合は、SQL Server エージェント ジョブによって sp_replcmds.が呼び出されます。 同じデータベースで両方の機能が有効になっている場合は、ログ リーダー エージェントによって sp_replcmdsが呼び出されます。 このエージェントは、変更テーブルとディストリビューション データベース テーブルの両方を作成します。 詳細については、「 Replication Log Reader Agent」を参照してください。
AdventureWorks2022 データベースで変更データ キャプチャが有効になっており、2 つのテーブルでキャプチャが有効になっているシナリオについて考えてみます。 変更テーブルを作成するために、キャプチャ ジョブによって sp_replcmdsが呼び出されます。 データベースでトランザクション レプリケーションが有効になり、パブリケーションが作成されます。 次に、ログ リーダー エージェントがデータベースに対して作成され、キャプチャ ジョブが削除されます。 ログ リーダー エージェントは、変更テーブルにコミットされた最後のログ シーケンス番号からログのスキャンを続行します。 これにより、変更テーブル内のデータの一貫性が確保されます。 このデータベースでトランザクション レプリケーションが無効になっている場合、ログ リーダー エージェントが削除され、キャプチャ ジョブが再作成されます。
Note
変更データ キャプチャとトランザクション レプリケーションの両方でログ リーダー エージェントを使用している場合、レプリケートされた変更が最初にディストリビューション データベースに書き込まれます。 次に、キャプチャされた変更が変更テーブルに書き込まれます。 両方の操作は同時にコミットされます。 ディストリビューション データベースへの書き込みの際に遅延が生じた場合、変更テーブルに変更が表示される前に、それに対応する遅延が発生します。
変更データ キャプチャが有効にされている場合、トランザクション レプリケーションの proc exec オプションは使用できません。
データベースの復元またはアタッチ
SQL Server は、データベースが復元またはアタッチされた後に変更データ キャプチャを有効のままにするかどうかを、次のロジックに従って判断します。
データベースを同じサーバーに同じデータベース名で復元した場合、変更データ キャプチャは有効のままです。
データベースを別のサーバーに復元した場合、既定では変更データ キャプチャが無効になり、関連するメタデータがすべて削除されます。
変更データ キャプチャを保持するには、データベースを復元する際に KEEP_CDC オプションを使用します。 このオプションの詳細については、「 RESTORE」を参照してください。
データベースをデタッチしてから、同じサーバーまたは別のサーバーにアタッチした場合、変更データ キャプチャは有効のままです。
KEEP_CDC オプションを使用してデータベースを Standard、Enterprise、または SQL Managed Instance 以外のエディションにアタッチまたは復元しようとすると、操作がブロックされます。これは変更データ キャプチャを使用するには、SQL Server Standard、Enterprise、または SQL Managed Instance のエディションが必要であるためです。 エラー メッセージ 934 が表示されます。
SQL Server cannot load database '%.*ls' because change data capture is enabled. The currently installed edition of SQL Server does not support change data capture. Either restore database without KEEP_CDC option, or upgrade the instance to one that supports change data capture.
sys.sp_cdc_disable_db を使用すると、復元またはアタッチされたデータベースから変更データ キャプチャを削除できます。
Azure SQL Managed Instance でデータベースを復元した後も、CDC は有効なままですが、スキャン ジョブとクリーンアップ ジョブが追加され、実行されている必要があります。 ジョブを手動で追加するには、sys.sp_cdc_add_job を実行します。
包含データベース
変更データ キャプチャは、包含データベースでサポートされていません。
可用性グループ
Always On 可用性グループを使用する場合、セカンダリ レプリカに対して変更の列挙を行うことにより、プライマリへのディスク負荷を減らす必要があります。
列ストア インデックス
クラスター化列ストア インデックスを持つテーブルで、変更データ キャプチャを有効にすることはできません。 SQL Server 2016 以降では、非クラスター化列ストア インデックスを持つテーブルで有効にすることができます。
計算列
計算列が永続化として定義されている場合でも、CDC では計算列の値はサポートされません。 キャプチャ インスタンスに含まれる計算列の値は、常に NULL になります。 この動作は、バグではなく、意図されたものです。
Linux
CDC は、SQL Server 2017 on Linux (CU18 以降) と SQL Server 2019 on Linux でサポートされています。