変更データキャプチャ (CDC) とは

[アーティクル]
04/26/2023

適用対象:SQL Server Azure SQL Database Azure SQL Managed Instance

この記事では、テーブルや行が変更されたときにデータベースでのアクティビティを記録する変更データキャプチャ (CDC) について学習します。変更データキャプチャは、Azure SQL Database、SQL Server、Azure SQL Managed Instanceで一般提供されています。

概要

変更データキャプチャ (CDC) によって、SQL Server エージェントが使用され、テーブルに適用する挿入、更新、削除の各アクティビティが記録されます。変更の詳細を、利用しやすいリレーショナル形式で格納します。変更された行に対応する列情報が、その変更をターゲット環境に適用するために必要なメタデータと共にキャプチャされ、追跡対象となるソーステーブルの列構造がミラー化された変更テーブルに格納されます。コンシューマーは、用意されているテーブル値関数を使用して、変更データに体系的にアクセスできます。

この技術の対象となるデータコンシューマーの好例が、抽出、変換、読み込み (ETL) アプリケーションです。 ETL アプリケーションは、 SQL Server のソーステーブルからデータウェアハウスやデータマートに変更データをインクリメンタルに読み込みます。データウェアハウス内のソーステーブルの表現にはソーステーブルの変更が反映されている必要がありますが、ソースのレプリカを更新するエンドツーエンドのテクノロジは適切ではありません。ここで必要となるのは、対象となる異質なデータ表現に対して適用できるように構成された変更データの確実なストリームです。 SQL Server の変更データキャプチャはこの技術を提供します。

CDC & Azure SQL データベース

Azure SQL Database では、ストアドプロシージャを呼び出して変更データキャプチャテーブルの定期的なキャプチャとクリーンアップを開始する SQL Server エージェントの代わりに、変更データキャプチャスケジューラが使用されます。スケジューラは SQL Database 内で自動的にキャプチャとクリーンアップを実行し、信頼性やパフォーマンスに関して外部の依存関係はありません。その場合でも、ユーザーは、必要に応じて手動でキャプチャとクリーンアップを実行できます。

変更データキャプチャの詳細については、次のデータ公開エピソードを参照することもできます。

パフォーマンスに関する考慮事項

Azure SQL Database で変更データキャプチャを有効にした場合のパフォーマンスへの影響は、SQL Server または Azure SQL Managed Instance で CDC を有効にした場合のパフォーマンスへの影響と同程度です。 CDC を有効にした場合のパフォーマンスへの影響を左右するいくつかの側面を次に示します。

追跡対象の CDC が有効なテーブルの数
追跡対象テーブルでの変更の頻度
CDC 成果物 (CT テーブル、cdc_jobs など) は同じデータベースに格納されるため、ソースデータベースで使用できる領域
データベースが単独か、プールされているか。エラスティックプール内のデータベースの場合、CDC が有効になっているテーブルの数を考慮するだけでなく、それらのテーブルが属しているデータベースの数にご注意ください。プール内のデータベースの間でリソースが共有されるため (ディスク領域など)、複数のデータベースで CDC を有効にすると、エラスティックプールのディスクサイズの最大サイズに達するリスクがあります。 CPU、メモリ、ログスループットなどのリソースを監視してください。

より具体的なパフォーマンス最適化ガイダンスを顧客に提供するには、各顧客のワークロードに関する詳細が必要です。ただし、TPCC ワークロードで実行されたパフォーマンステストに基づいて、いくつかの一般的なガイダンスを次に示します。

Azure SQL Database で CDC が有効になる前と同じパフォーマンスレベルを確保するには、仮想コアの数を増やすか、上位のデータベース層 (Hyperscale など) に移行することを検討してください。
運用環境のデータベースで CDC を有効にする前に、領域の使用状況を注意深く監視し、ワークロードを十分にテストします。
ログ生成率を監視します。詳細については、こちらを参照してください。
スキャン/クリーンアップは、ユーザーワークロードの一部です (ユーザーのリソースが使用されます)。変更テーブルに行全体が追加され、更新操作の場合はプリイメージも含まれるため、パフォーマンスに大きな影響が及ぶことがあります。
エラスティックプール - 待機時間の増加を回避するために、CDC 対応データベースの数がプールの仮想コア数を超えないようにする必要があります。高密度エラスティックプールでのリソース管理の詳細については、こちらを参照してください。
クリーンアップ – お客様のワークロードに基づいて、保持期間を既定の 3 日間よりも小さくして、クリーンアップが変更テーブルのすべての変更に確実に追いつくことをお勧めします。一般に、リテンション期間を低く保ち、データベースサイズを追跡することをお勧めします。
変更が変更テーブルに設定されるときには、サービスレベルアグリーメント (SLA) は提供されません。秒未満の待機時間もサポートされていません。

データフロー

次の図は、変更データキャプチャの主なデータフローを示しています。

変更データキャプチャデータフロー

変更データキャプチャの変更データのソースは SQL Server トランザクションログです。追跡対象のソーステーブルに対して挿入、更新、削除の各操作が適用されると、それらの変更を記述するエントリがこのログに追加されます。このログは、キャプチャプロセスへの入力として機能します。このプロセスによってログが読み取られ、変更に関する情報が、追跡対象のテーブルに関連付けられている変更テーブルに追加されます。用意されている関数を使用すると、指定した範囲にこの変更テーブルに追加された変更を列挙できます。この情報は、フィルター処理された結果セットの形式で返されます。通常は、このフィルター処理された結果セットを使用して、アプリケーションプロセスによって外部環境のソースの表現が更新されます。

[キャプチャインスタンス]

データベース内の個々のテーブルの変更を追跡するには、まずそのデータベースで変更データキャプチャを明示的に有効にする必要があります。これは、 sys.sp_cdc_enable_dbストアドプロシージャを使用して実行します。データベースを有効にした後、 sys.sp_cdc_enable_tableストアドプロシージャを使用して、ソーステーブルを追跡対象テーブルとして指定できます。テーブルに対して変更データキャプチャを有効にすると、関連付けられたキャプチャインスタンスが作成されます。これにより、ソーステーブルの変更データの伝播がサポートされます。キャプチャインスタンスは、1 つの変更テーブルと、最大 2 つのクエリ関数で構成されます。キャプチャインスタンスの構成の詳細を記述するメタデータは、変更データキャプチャのメタデータテーブル ( cdc.change_tables、 cdc.index_columns、および cdc.captured_columns) に保持されます。この情報を取得するには、 sys.sp_cdc_help_change_data_captureストアドプロシージャを使用します。

キャプチャインスタンスに関連付けられているオブジェクトはすべて、有効にされたデータベースの変更データキャプチャスキーマに作成されます。キャプチャインスタンス名の要件は、有効なオブジェクト名であり、データベースキャプチャインスタンス全体で一意であることです。既定では、名前は<ソーステーブルのスキーマ名_テーブル名>です。関連付けられている変更テーブルの名前は、キャプチャインスタンス名の末尾に _CT を付けた名前になります。すべての変更のクエリを実行する関数の名前は、キャプチャインスタンス名の先頭に fn_cdc_get_all_changes_ を付けた名前になります。キャプチャインスタンスが net 変更をサポートするように構成されている場合は、 net_changes クエリ関数も作成され、キャプチャインスタンス名の前 にfn_cdc_get_net_changes_ によって名前が付けられます。

変更テーブル

変更データキャプチャの変更テーブルの最初の 5 つの列は、メタデータ列です。これらは、記録された変更に関係する追加情報を提供します。残りの列には、識別されたソーステーブルのキャプチャ対象列の名前 (および通常は型) が反映されます。これらの列は、ソーステーブルから収集されたキャプチャ対象列のデータを保持します。

ソーステーブルに適用された挿入または削除の各操作は、変更テーブル内の 1 つの行として表されます。挿入操作の結果となる行のデータ列には挿入後の列の値が含まれ、削除操作の結果となる行のデータ列には削除前の列の値が含まれます。更新操作では、更新前の列の値を識別する 1 つ目の行エントリと、更新後の列の値を識別する 2 つ目の行エントリが必要になります。

変更テーブルの各行には、変更アクティビティの解釈に使用される追加のメタデータも含まれています。 __$start_lsn 列は、変更に割り当てられたコミットログシーケンス番号 (LSN) を識別します。コミット LSN では、同じトランザクション内でコミットされた変更が識別されるだけでなく、それらのトランザクションが順序付けられます。 __$seqval 列は、同じトランザクション内で発生したさらに多くの変更を順序付けるために使用できる列です。 __$operation 列は、変更に関連付けられている操作を記録します (1 = 削除、2 = 挿入、3 = 更新 (前イメージ)、4 = 更新 (後イメージ))。 __$update_mask 列は、キャプチャ対象列ごとに 1 つのビットを定義する可変ビットマスクです。挿入と削除のエントリでは常にすべてのビットが設定されます。更新の行では、変更された列に対応するビットのみが設定されます。

有効期間

データベースの変更データキャプチャの有効期間とは、キャプチャインスタンスが変更データを利用できる期間です。この有効期間は、データベーステーブルに対して最初のキャプチャインスタンスが作成されたときに始まり、現在まで続きます。

データベース

定期的かつ体系的にデータを排除しないと、変更テーブルに格納されたデータは管理不能に拡張されます。このため、変更データキャプチャのクリーンアッププロセスにより、保有期間に基づくクリーンアップポリシーが適用されます。このプロセスでは、まず、時間制限を満たすように有効期間の下端が移動されます。次に、有効期限が切れた変更テーブルエントリが削除されます。既定では、3 日分のデータが保持されます。

上端では、キャプチャプロセスによって変更データの新しいバッチがコミットされるたびに、変更テーブルのエントリを持つ各トランザクションに対応する新しいエントリが cdc.lsn_time_mapping に追加されます。このマッピングテーブルでは、コミットログシーケンス番号 (LSN) とトランザクションのコミット時間の両方 (columns start_lsn と tran_end_time) が保持されます。 cdc.lsn_time_mapping 内で最も大きい LSN 値は、データベースの有効期間の上限を表します。それに対応するコミット時間は、保有期間に基づくクリーンアップの新しい下限を計算するための基礎として使用されます。

キャプチャプロセスではトランザクションログから変更データが抽出されるため、変更がソーステーブルにコミットされる時間と、関連付けられている変更テーブル内に変更が表示されるまでの間に、組み込みの待機時間が発生します。この待機時間は通常は短くなりますが、キャプチャプロセスで関連するログエントリが処理されるまで変更データは使用できないことに注意することが重要です。

[キャプチャインスタンス]

データベースの有効期間と個々のキャプチャインスタンスの有効期間が一致するのは一般的ですが、これは常に当てはまるとは限りません。キャプチャインスタンスの有効期間は、キャプチャプロセスがそのキャプチャインスタンスを認識して、関連する変更のログをその変更テーブルに記録し始めたときに始まります。その結果、キャプチャインスタンスが別々の時間に作成された場合は、最初は各キャプチャインスタンスがそれぞれ異なる下端を持つことになります。定義されている各キャプチャインスタンスの現在の下端は、 sys.sp_cdc_help_change_data_capture によって返される結果セットの start_lsn 列で確認できます。クリーンアッププロセスによって変更テーブルのエントリがクリーンアップされると、すべてのキャプチャインスタンスの start_lsn 値が、使用可能な変更データの新しい下限を反映して調整されます。調整されるのは、その時点で start_lsn 値が新しい下限より小さいキャプチャインスタンスだけです。通常は、新しいキャプチャインスタンスが作成されなければ、時間が経つにつれて、すべてのインスタンスの有効期間がデータベースの有効期間と一致するようになります。

有効期間は変更データのコンシューマーにとって重要です。これは、要求の抽出範囲が、キャプチャインスタンスの現在の変更データキャプチャの有効期間によって完全にカバーされている必要があるからです。抽出範囲の下端が有効期間の下端より左にある場合は、積極的なクリーンアップによって変更データが失われる可能性があります。抽出間隔の高いエンドポイントが有効期間の高いエンドポイントの右側にある場合、キャプチャプロセスは抽出間隔で表される期間を通じてまだ処理されておらず、変更データが欠落している可能性もあります。

関数 sys.fn_cdc_get_min_lsn はキャプチャインスタンスの LSN の現在の最小値の取得に使用し、 sys.fn_cdc_get_max_lsn は LSN の現在の最大値の取得に使用します。変更データのクエリを実行するときに、指定された LSN 範囲がこれら 2 つの LSN 値内に存在しない場合、変更データキャプチャクエリ関数は失敗します。

ソーステーブルに対する変更の処理

追跡対象となるソーステーブルの列の変更への対応は、下流のコンシューマーにとって困難な課題になります。ソーステーブルで変更データキャプチャを有効にしても、このような DDL 変更が発生するのを防ぐわけではありませんが、変更データキャプチャは、API を通じて返される配信された結果セットが、基になるソーステーブルの列構造が変更されても変更されないようにすることで、コンシューマーへの影響を軽減するのに役立ちます。この固定された列構造は、定義済みのクエリ関数がアクセスする基になる変更テーブルにも反映されます。

固定列構造変更テーブルに対応するために、変更テーブルの設定を担当するキャプチャプロセスでは、ソーステーブルが変更データキャプチャに対して有効になっているときにキャプチャ用に識別されない新しい列は無視されます。追跡対象の列が削除されると、後続の変更エントリの列に null 値が指定されます。ただし、既存の列のデータ型が変更されると、変更は変更テーブルに反映され、キャプチャメカニズムによって追跡される列にデータ損失が発生しないようにします。また、追跡されているテーブルの列構造の変更が検出されると、その変更が cdc.ddl_history テーブルに書き込まれます。下流のアプリケーションで調整を加える必要がある場合に通知されるようにするには、 sys.sp_cdc_get_ddl_historyストアドプロシージャを使用します。

通常は、関連付けられているソーステーブルに DDL の変更が適用されても、現在のキャプチャインスタンスの構造はそのまま保持されます。ただし、新しい列構造を反映するテーブルの 2 つ目のキャプチャインスタンスを作成することもできます。これにより、同じソーステーブルに対する変更が、それぞれ異なる列構造を持つ 2 つの個別の変更テーブルに記録されるようになります。その結果、一方の変更テーブルで現在実行中のプログラムに引き続きデータを提供しながら、もう一方の変更テーブルを開発環境で使用して新しい列データの組み込みに取り組むことができます。このようにキャプチャメカニズムで両方の変更テーブルに並行してデータを書き込むことができれば、一方の変更テーブルからもう一方の変更テーブルに、変更データを失うことなく移行できるようになります。これは、2 つの変更データキャプチャタイムラインが重複するときであればいつでも発生する可能性があります。移行に影響が出ているときは、古いキャプチャインスタンスを削除できます。

Note

1 つのソーステーブルに同時に関連付けることのできるキャプチャインスタンスは最大 2 つです。

ログリーダーエージェントとの関係

変更データキャプチャプロセスのロジックは、ストアドプロシージャの sp_replcmdsに組み込まれています。これは、sqlservr.exe の一部として作成された内部サーバー関数で、トランザクションレプリケーションでトランザクションログから変更を取得するためにも使用されます。 SQL Server と Azure SQL Managed Instance では、データベースで有効になっているのが変更データキャプチャだけの場合、sp_replcmds を呼び出すための手段として、変更データキャプチャの SQL Server エージェントキャプチャジョブを作成します。レプリケーションも存在する場合は、トランザクションログリーダーを使用するだけで、両方のコンシューマーの変更データのニーズを満たすことができます。これにより、同じデータベースでレプリケーションと変更データキャプチャの両方が有効になっている場合にログの競合を大幅に削減できます。

変更データをキャプチャするためのこれら 2 つの操作モード間の切り替えは、変更データキャプチャが有効なデータベースのレプリケーション状態に変更が発生するたびに自動的に発生します。

Note

SQL Server と Azure SQL Managed Instance では、キャプチャロジックのどちらのインスタンスも、プロセスを実行するために SQL Server エージェントが実行されている必要があります。

キャプチャプロセスの主なタスクは、ログをスキャンして、列データとトランザクション関連の情報を変更データキャプチャの変更テーブルに書き込むことです。キャプチャプロセスでは、データを書き込むすべての変更データキャプチャ変更テーブルでトランザクション的に一貫した境界を確保するために、各スキャンサイクルで独自のトランザクションを開いてコミットします。新たに変更データキャプチャが有効にされたテーブルがあるとそれが検出されて、ログの変更エントリをアクティブに監視するテーブルのセットにそのテーブルが自動的に追加されます。同様に、変更データキャプチャが無効にされた場合にもそれが検出されて、変更データをアクティブに監視するテーブルのセットからそのソーステーブルが削除されます。ログのセクションの処理が完了すると、サーバーログ切り捨てロジックに情報が送られて、切り捨ての対象となるログエントリが識別されます。

Note

データベースの変更データキャプチャが有効になっている場合は、復旧モードが単純復旧に設定されていても、キャプチャ対象としてマークされた変更がすべてキャプチャプロセスで収集されるまで、ログの切り捨て位置が進められることはありません。キャプチャプロセスが実行されておらず、収集対象の変更がある場合は、CHECKPOINT を実行してもログが切り捨てられることはありません。

キャプチャプロセスは、追跡対象のテーブルに対する DDL の変更の履歴を保持するためにも使用されます。変更データキャプチャが有効になっているデータベースまたはテーブルが削除されたり、変更データキャプチャが有効になっているテーブルの列が追加、変更、または削除されたりするたびに、変更データキャプチャに関連付けられている DDL ステートメントのエントリがデータベーストランザクションログに作成されます。これらのログエントリがキャプチャプロセスによって処理されると、関連する DDL イベントが cdc.ddl_history テーブルに書き込まれます。追跡対象のテーブルに影響を与えた DDL イベントに関する情報を取得するには、 sys.sp_cdc_get_ddl_historyストアドプロシージャを使用します。

警告

特定のパブリケーションデータベースが変更データキャプチャとレプリケーションの両方で有効になっている場合、ログリーダーエージェントの MaxCmdsInTran パラメーターはサポートされません。この構成で MaxCmdsInTran を使用すると、CDC 変更テーブルでデータが失われる可能性があります。

エージェントジョブ

変更データキャプチャが有効になっているデータベースには、通常、2 つの SQL Server エージェントジョブが関連付けられています。1 つはデータベース変更テーブルへの書き込みに使用されるジョブ、もう 1 つは変更テーブルのクリーンアップを行うジョブです。どちらのジョブも、Transact-SQL コマンドを実行する 1 つのステップで構成されます。呼び出される Transact-SQL コマンドは、ジョブのロジックを実装する変更データキャプチャ定義ストアドプロシージャです。これらのジョブは、データベースの最初のテーブルの変更データキャプチャを有効にしたときに作成されます。クリーンアップジョブは常に作成されます。キャプチャジョブは、データベースに定義済みのトランザクションパブリケーションがない場合にのみ作成されます。データベースで変更データキャプチャとトランザクションレプリケーションの両方が有効になっている場合に、データベースに定義済みのパブリケーションがなくなったためにトランザクションログリーダージョブが削除されたときにも作成されます。

キャプチャジョブとクリーンアップジョブはどちらも既定のパラメーターを使用して作成されます。キャプチャジョブはすぐに開始され、継続的に実行されます。各スキャンサイクルで最大 1000 のトランザクションが処理されます。サイクル間の待ち時間は 5 秒です。クリーンアップジョブは毎日午前 2 時に実行されます。変更テーブルエントリは 4320 分または 3 日間保持され、1 つの delete ステートメントで最大 5,000 エントリが削除されます。

変更データキャプチャのエージェントジョブは、データベースで変更データキャプチャが無効にされると削除されます。また、変更データキャプチャとトランザクションレプリケーションの両方が有効になっている場合に、データベースに最初のパブリケーションが追加されたときに削除されることもあります。

内部では、 sys.sp_cdc_add_job ストアドプロシージャと sys.sp_cdc_drop_jobストアドプロシージャをそれぞれ使用して、変更データキャプチャのエージェントジョブが作成および削除されます。これらのストアドプロシージャは、管理者がこれらのジョブの作成および削除を制御できるように公開されています。

変更データキャプチャのエージェントジョブについて、既定の構成を管理者が明示的に制御することはできませんが、既定の構成パラメーターを変更できるように sys.sp_cdc_change_job ストアドプロシージャが用意されています。さらに、 sys.sp_cdc_help_jobs ストアドプロシージャを使用すると、現在の構成パラメーターを表示できます。キャプチャジョブとクリーンアップジョブの構成パラメーターは、どちらも起動時に msdb.dbo.cdc_jobs テーブルから抽出されます。 sys.sp_cdc_change_jobを使用してこれらの値に加えられた変更は、ジョブが停止して再起動されるまで有効になりません。

変更データキャプチャのエージェントジョブを開始および停止できるように、さらに 2 つのストアドプロシージャ ( sys.sp_cdc_start_job と sys.sp_cdc_stop_job) が用意されています。

Note

キャプチャジョブを開始したり停止したりしても、変更データが失われることはありません。変更テーブルに格納される変更エントリについて、アクティブにログがスキャンされなくなるだけです。要求のピーク時にキャプチャジョブを停止して、ピーク時を過ぎたら再開することにより、ログスキャンの負荷をピーク時に合理的に取り除くことができます。

この 2 つの SQL Server エージェントジョブはどちらも、変更データキャプチャ環境の基本的なニーズに対応できるように十分な柔軟性と構成可能性を備えていますが、コア機能を提供する基になるストアドプロシージャが公開されているため、さらなるカスタマイズも可能です。

データベースエンジンサービスまたは SQL Server エージェントサービスが NETWORK SERVICE アカウントで実行されている場合、変更データキャプチャが正しく機能しません。この結果、エラー 22832 が発生します。

Note

Azure SQL Database では、エージェントジョブは、キャプチャとクリーンアップを自動的に実行するスケジューラに置き換えられます。

Azure SQL Database での CDC キャプチャとクリーンアップ

Azure SQL Database では、ストアドプロシージャを呼び出して変更データキャプチャテーブルの定期的なキャプチャとクリーンアップを開始する SQL Server エージェントの代わりに、変更データキャプチャスケジューラが使用されます。

スケジューラは SQL Database 内で自動的にキャプチャとクリーンアップを実行し、信頼性やパフォーマンスに関して外部の依存関係はありません。ユーザーは、オンデマンドで sp_cdc_scan と sp_cdc_cleanup_change_tables プロシージャを使用して、キャプチャとクリーンアップを手動で実行するオプションを引き続き使用できます。 CDC キャプチャジョブは 20 秒ごとに実行され、クリーンアップジョブは 1 時間ごとに実行されます。

Azure SQL Database には、変更データキャプチャの監視に役立つ 2 つの動的管理ビュー、sys.dm_cdc_log_scan_sessions と sys.dm_cdc_errors が用意されています。

照合順序の違い

データベースと変更データキャプチャ用に構成されたテーブルの列の間に異なる照合順序がある状況に注意することが重要です。 CDC は、中間記憶域を使用して、サイドテーブルを設定します。テーブルにデータベースの照合順序とは異なる照合順序を持つ CHAR または VARCHAR 型の列があり、これらの列に非 ASCII 文字 (2 バイト DBCS 文字など) が格納される場合、CDC は変更されたデータとベーステーブル内のデータの整合性を維持できない可能性があります。これは、中間ストレージ変数に照合順序を関連付けることができないためです。

変更キャプチャデータとベーステーブルの整合性を保つには、次のいずれかの方法を検討してください。

非 ASCII データを格納する列には NCHAR または NVARCHAR データ型を使用します。
または、列とデータベースに同じ照合順序を使用します。

たとえば、SQL_Latin1_General_CP1_CI_ASの照合順序を使用するデータベースが 1 つある場合は、次の表を考えてみます。

CREATE TABLE T1( 
     C1 INT PRIMARY KEY, 
     C2 VARCHAR(10) collate Chinese_PRC_CI_AI)

列 C2 の照合順序が異なるので (Chinese_PRC_CI_AI)、この列に対するバイナリデータの CDC は失敗する可能性があります。この問題を回避するには、NVARCHAR を使用します。

CREATE TABLE T1( 
     C1 INT PRIMARY KEY, 
     C2 NVARCHAR(10) collate Chinese_PRC_CI_AI --Unicode data type, CDC works well with this data type
     )

必要なアクセス許可

SQL Server または Azure SQL Managed Instance で変更データキャプチャを有効にするには、sysadmin アクセス許可が必要です。 Azure SQL Database で変更データキャプチャを有効にするには、db_owner ロールが必要です。

一般的なガイドライン

データキャプチャ (CDC) を適切に機能させるには、CDC スキーマ、変更テーブル、CDC システムストアドプロシージャ、既定 cdc のユーザーアクセス許可 (sys.database_principals) やユーザー名の変更 cdc などの CDC メタデータを手動で変更しないでください。

プロパティがに1設定されている sys.objects 内のオブジェクトis_ms_shippedは変更しないでください。

SELECT    name AS object_name   
        ,SCHEMA_NAME(schema_id) AS schema_name  
        ,type_desc  
        ,is_ms_shipped  
FROM sys.objects 
WHERE is_ms_shipped= 1 AND SCHEMA_NAME(schema_id) = 'cdc'

既知の制限事項と問題

これは、変更データキャプチャ (CDC) に関する既知の制限事項と問題の一覧です。

Linux
CDC は現在、SQL Server 2017 on Linux (CU18 以降) と SQL Server 2019 on Linux でサポートされています。

列ストアインデックス
クラスター化列ストアインデックスを持つテーブルで変更データキャプチャを有効にすることはできません。 SQL Server 2016 以降では、非クラスター化列ストアインデックスを持つテーブルで有効にすることができます。

変数を使用したパーティションの切り替え
変更データキャプチャ (CDC) を使用したデータベースまたはテーブルでのパーティション切り替えでの変数の使用は、ステートメントでは ALTER TABLE ... SWITCH TO ... PARTITION ... サポートされていません。詳細については、パーティション切り替えの制限事項に関するセクションを参照してください。

Azure SQL データベースでの CDC の可用性
CDC は、データベース層 S3 以降でのみ有効にすることができます。サブコア (Basic、S0、S1、S2) Azure SQLデータベースは CDC ではサポートされていません。

現在、CDC が有効になっている S3 より上のデータベース層からサブコア SLO への Dbcopy では CDC 成果物が保持されますが、CDC 成果物は今後削除される可能性があります。

Azure SQL データベースでのカスタマイズのキャプチャとクリーンアップ
Azure SQL データベースで CDC のキャプチャとクリーンアッププロセスの頻度を構成することはできません。キャプチャとクリーンアップは、スケジューラによって自動的に実行されます。

計算列
CDC では、計算列が永続化として定義されている場合でも、計算列の値はサポートされません。キャプチャインスタンスに含まれる計算列の値は常にです NULL。この動作は、バグではなく、意図されたものです。

ポイントインタイムリストア (PITR)
データベースで CDC をMicrosoft Azure Active Directory (Azure AD) ユーザーとして有効にした場合、ポイントインタイムリストア (PITR) をサブコア SLO にすることはできません。データベースをソース以上の SLO と同じに復元し、必要に応じて CDC を無効にすることをお勧めします。

Microsoft Azure Active Directory (Azure AD)
Azure SQL Database でMicrosoft Azure Active Directory (Azure AD) ユーザーとしてデータベースを作成し、それに対して変更データキャプチャ (CDC) を有効にした場合、SQL ユーザー (sysadmin ロールなど) は CDC 成果物を無効または変更できません。ただし、別の Azure AD ユーザーは、同じデータベースで CDC を有効または無効にできます。

同様に、sql ユーザーとして Azure SQL Database を作成した場合、Azure AD ユーザーとして変更データキャプチャを有効または無効にすることはできません。

ログの積極的切り捨て
Azure SQL Database または SQL Server で変更データキャプチャ (CDC) を有効にしているときに、高速データベース復旧 (ADR) の積極的なログ切り捨て機能が無効になっていることに注意してください。これは、CDC スキャンによりデータベーストランザクションログにアクセスするためです。アクティブなトランザクションは、トランザクションがコミットされ、CDC スキャンがキャッチアップするか、トランザクションが中止されるまで、トランザクションログの切り捨てを保持し続けます。これにより、トランザクションログが通常よりも多くなる可能性があるため、トランザクションログが満杯にならないようにモニターする必要があります。

ALTER COLUMN から VARCHAR および VARBINARY の後に CDC が失敗する
CDC 対応テーブルの列のデータ型がから TEXT または IMAGE にVARCHARVARBINARY変更され、既存の行が行外の値に更新された場合。更新後、CDC スキャンによってエラーが発生します。

Microsoft Azure Active Directory (Azure AD) で作成された復元Azure SQL DB で CDC の有効化が失敗する
Microsoft Azure Active Directory (Azure AD) ユーザーとしてデータベースを Azure SQL Database に作成し、CDC を有効にしなかった場合、CDC の有効化は失敗し、復元されたデータベースでデータベースを復元して CDC を有効にします。

この問題を解決するには、次の手順に従ってください。

サーバーの Azure AD 管理者としてサインインする
データベースで ALTER AUTHORIZATION コマンドを実行します。

ALTER AUTHORIZATION ON DATABASE::[<restored_db_name>] TO [<azuread_admin_login_name>];

EXEC sys.sp_cdc_enable_db

データベースに事前に指定 cdc されたカスタムスキーマまたはユーザーが存在する場合、CDC を有効にしようとすると失敗します
データベースで CDC を有効にすると、という名前 cdcの新しいスキーマとユーザーが作成されます。そのため、システム用に予約されているため、という名前 cdcのカスタムスキーマまたはユーザーを手動で作成することはお勧めしません。
CDC に関連しないカスタムスキーマまたは名前付き cdc ユーザーをデータベースで手動で定義した場合、システムストアドプロシージャ sys.sp_cdc_enable_db は以下のエラーメッセージでデータベースで CDC を有効にできません。

'cdc' という名前のデータベース <database_name> ユーザーまたは 'cdc' という名前のスキーマが現在のデータベースに既に存在するため、変更データキャプチャに対してデータベースを有効にすることはできません。これらのオブジェクトは、Change Data Capture 専用に必要です。ユーザーまたはスキーマを削除するか名前を変更してから、操作を再試行してください。

この問題を解決するには、次の手順を実行します。

空の cdc スキーマと cdc ユーザーを手動で削除します。その後、データベースで CDC を正常に有効にすることができます。

データ層のインポート/エクスポートおよび抽出/発行操作を使用してデータベースをインポートする
CDC 対応 SQL データベースの場合、SqlPackage、SSDT、またはその他の SQL ツールを使用してインポート/エクスポートまたは抽出/発行を行うと、 cdc スキーマとユーザーは新しいデータベースで除外されます。 Import/Export および Extract/Deploy 操作に含まれない追加の CDC オブジェクトには、sys.objects でとして is_ms_shipped=1 マークされたテーブルが含まれます。

CDC が有効になっていない場合でも、新しいデータベースをインポート/セットアップするためのインポート/エクスポートおよび抽出/配置操作でも除外される、データベースにという名前 cdc のカスタムスキーマまたはユーザーを定義しています。

変更データキャプチャ (CDC) とは

概要

CDC & Azure SQL データベース

パフォーマンスに関する考慮事項

データフロー

[キャプチャインスタンス]

変更テーブル

有効期間

データベース

[キャプチャインスタンス]

ソーステーブルに対する変更の処理

ログリーダーエージェントとの関係

エージェントジョブ

Azure SQL Database での CDC キャプチャとクリーンアップ

照合順序の違い

必要なアクセス許可

一般的なガイドライン

既知の制限事項と問題

関連項目

その他のリソース

その他のリソース

変更データ キャプチャ (CDC) とは

概要

CDC & Azure SQL データベース

パフォーマンスに関する考慮事項

データ フロー

[キャプチャ インスタンス]

変更テーブル

有効期間

データベース

[キャプチャ インスタンス]

ソース テーブルに対する変更の処理

ログ リーダー エージェントとの関係

エージェント ジョブ

Azure SQL Database での CDC キャプチャとクリーンアップ

照合順序の違い

必要なアクセス許可

一般的なガイドライン

既知の制限事項と問題

関連項目

その他のリソース

その他のリソース

変更データキャプチャ (CDC) とは

データフロー

[キャプチャインスタンス]

[キャプチャインスタンス]

ソーステーブルに対する変更の処理

ログリーダーエージェントとの関係

エージェントジョブ