Azure SQL データベースを使用した変更データ キャプチャ (CDC)

適用対象: Azure SQL Database

この記事では、テーブルや行が変更されたときに、変更データ キャプチャ (CDC) がどのようにAzure SQL データベースで実装され、アクティビティを記録するか説明します。 CDC 機能の詳細 (SQL Server と Azure SQL Managed Instance での実装方法など) については、「SQL Server を使用した CDC」を参照してください。

概要

Azure SQL Database では、ソース テーブルの変更データのキャプチャとクリーンアップを行う SQL Server エージェント機能が、変更データ キャプチャ スケジューラに置き換えられます。 スケジューラはデータベースの範囲内で自動的にキャプチャとクリーンアップ プロセスを実行します。信頼性とパフォーマンスに関して外部の依存関係はありません。 ユーザーは、必要に応じてキャプチャプロセスとクリーンアッププロセスを手動で開始するオプションを保持します。

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

Azure SQL データベースでの変更データ キャプチャの詳細については、この Data Exposed エピソードを参照することもできます。

データ フロー

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

前提条件

アクセス許可

Azure SQL Database で変更データ キャプチャを有効にするには、db_owner ロールが必要です。

Azure SQL Database のコンピューティング要件

単一データベースとエラスティック プールのどちらに対しても、仮想コアベースの購入モデル内の任意のサービス レベルで、Azure SQL Database で CDC を有効にすることができます。

DTU 購入モデルのデータベースの場合、CDC は S3 レベル以上のデータベースでサポートされています。 サブコア (Basic、S0、S1、S2) は、CDC ではサポートされていません。

Azure SQL データベースの CDC を有効にする

個々のテーブルに対してキャプチャ インスタンスを作成する前に、データベースで Azure SQL データベースでの CDC を有効にする必要があります。

CDC を有効にするには、Azure Data Studio または SQL Server Management Studio (SSMS) から Azure SQL データベース に接続します。 新しいクエリ ウィンドウを開き、次の T-SQL を実行して CDC を有効にします。

EXEC sys.sp_cdc_enable_db;
GO

データベースで変更データ キャプチャを有効にすると、cdc schema、cdc user、メタデータ テーブル、およびほかのシステム オブジェクトがデータベースに作成されます。 cdc schema には、変更データ キャプチャのメタデータ テーブルが含まれています。ソース テーブルで変更データ キャプチャを有効にした後には、変更データのリポジトリとして機能する個々の変更テーブルも含まれます。 cdc schemaには変更データのクエリの実行に使用する関連のシステム関数も含まれています。

CDC をテーブルに対して有効にする

Azure SQL Database の CDC を有効にした後、1 つ以上のテーブルを選択してデータの変更を追跡することで、テーブル レベルで CDC を有効にすることができます。 ストアド プロシージャ sys.sp_cdc_enable_tableを使用して、個々のソース テーブルのキャプチャ インスタンスを作成します。

テーブルに対して CDC を有効にするには、次の T-SQL を実行します。

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = NULL;
GO

キャプチャするソース テーブルの列。

既定では、ソース テーブルのすべての列がキャプチャ対象列として識別されます。 プライバシーまたはパフォーマンス上の理由で、列のサブセットのみを追跡する場合は、@captured_column_list パラメーターを使用して列のサブセットを指定します。

テーブル内の列の特定の一覧に対して CDC を有効にするには、次の T-SQL を実行します。

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = NULL,
    @captured_column_list = N'Column1, Column2, Column3';
GO

変更テーブルへのアクセスを制御するためのロール。

名前付きのロールの目的は、変更データへのアクセスを制御することです。 指定されるロールは、既存の固定サーバー ロールの場合もデータベース ロールの場合もあります。 指定のロールがまだ存在しない場合は、その名前のデータベース ロールが自動的に作成されます。 ユーザーは、ソース テーブルのすべてのキャプチャ対象列に対する SELECT 権限が必要です。 さらに、ロールが指定されている場合、 sysadmin ロールと db_owner ロールのいずれのメンバーでもないユーザーも、指定のロールのメンバーである必要があります。

ゲーティング ロールを指定するテーブルに対して CDC を有効にするには、次の T-SQL を実行します。

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = N'RoleName'
GO

ゲーティング ロールを使用しない場合は、@role_name パラメーターを明示的に NULL に設定する必要があります。

差分変更を照会するための関数。

キャプチャ インスタンスには、定義した期間内に発生したすべての変更テーブル エントリを返すためのテーブル値関数が常に含まれています。 この関数の名前は、cdc.fn_cdc_get_all_changes_ の後ろにキャプチャ インスタンス名を付加したものです。 詳細については、cdc.fn_cdc_get_all_changes を参照してください。

@supports_net_changes パラメーターを 1 に設定すると、キャプチャ インスタンスに対して差分変更関数も生成されます。 この関数では、呼び出しで指定した期間内に変更された各行についてそれぞれ 1 つの変更のみが返されます。 詳細については、cdc.fn_cdc_get_net_changes を参照してください。

差分変更のクエリをサポートするには、行を一意に識別するための主キーまたは一意のインデックスがソース テーブルに必要です。 一意のインデックスを使用する場合は、 @index_name パラメーターを使用してインデックスの名前を指定する必要があります。 主キーまたは一意のインデックスで定義した列は、キャプチャするソース列の一覧に含まれている必要があります。

net 変更をサポートするテーブルに対して CDC を有効にするには、次の T-SQL を実行します。

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = NULL,
    @supports_net_changes = 1
GO

既存の主キーのあるテーブルで変更データ キャプチャが有効化され、代替となる一意なインデックスの識別に @index_name パラメーターが使用されていない場合、変更データ キャプチャ機能では主キーが使用されます。 その後は、テーブルの変更データ キャプチャを無効にしてからでなければ、主キーに変更を加えることはできません。 これは、変更データ キャプチャの構成時に差分変更のクエリのサポートが要求されたかどうかには関係ありません。

変更データ キャプチャが有効化された時点でテーブルに主キーがない場合、その後追加された主キーは変更データ キャプチャでは無視されます。 変更データ キャプチャでは、テーブルで変更データ キャプチャが有効化された後で作成された主キーは使用しないので、キーおよびキー列は制限なく削除できます。

sys.sp_cdc_enable_table ストアド プロシージャの引数の詳細については、「sys.sp_cdc_enable_table (Transact-SQL)」を参照してください。

Azure SQL Database の CDC を無効にする

Azure SQL Database の CDC を無効にすると、関連付けられているすべての変更データ キャプチャ メタデータ (cdc user、cdc schema、外部スケジューラ キャプチャ、クリーンアップ プロセスを含む) が削除されます。 ただし、変更データ キャプチャによって作成されたゲーティング ロールは自動的には削除されないので、明示的に削除する必要があります。

データベースで CDC を無効にする前に個々のテーブルの CDC を無効にする必要は "ありません"。

データベース レベルで CDC を無効にするには、次の T-SQL を実行します。

EXEC sys.sp_cdc_disable_db;
GO

CDC の管理

Azure SQL Database では、CDC はデータベース テーブルの変更を追跡および管理するための重要な機能です。 従来の SQL Server 環境とは異なり、Azure SQL Database では、SQL Server エージェント ジョブに依存するのではなく、CDC タスクを処理する変更データ キャプチャ スケジューラが採用されています。 このスケジューラは、データベース内の CDC テーブルの定期的なキャプチャおよびクリーンアップ プロセスを自動的に開始し、外部の依存関係なしで信頼性とパフォーマンスを確保します。

CDC の自動キャプチャとクリーンアップ

Azure SQL Database の CDC キャプチャ ジョブはシームレスに動作し、20 秒ごとに実行され、変更を効率的に追跡します。 同時に、クリーンアップ ジョブは 1 時間ごとに実行され、CDC テーブルが最適化されていることを確認します。 ユーザーの手動による介入なしで CDC 管理が自動的に行われるのでご安心ください。

手動 CDC コントロール

CDC は自動的に実行されますが、ユーザーの必要に応じて手動の CDC 操作を柔軟に実行することもできます。 sp_cdc_scan および sp_cdc_cleanup_change_tables プロシージャを使用すると、必要に応じてキャプチャタスクとクリーンアップ タスクをトリガーできます。

CDC の監視

Azure SQL Database には、CDC アクティビティを監視するための重要なツールが用意されています。 sys.dm_cdc_log_scan_sessions と sys.dm_cdc_errors の 2 つの動的管理ビューでは、CDC プロセスに関する分析情報が提供され、データの変更を完全に可視化できます。

CDC のカスタマイズ

Azure SQL Database では CDC 管理が効率化されますが、いくつかの制限事項があります。

• CDC キャプチャ ジョブとクリーンアップ ジョブの頻度はカスタマイズできません。
• Azure SQL データベース では、キャプチャ ジョブと クリーンアップ ジョブには、pollinginterval とcontinuous の値は使用されません。
• cdc.cdc_jobs テーブルからキャプチャ ジョブ エントリを削除しても、バックグラウンド キャプチャ ジョブは停止しません。
• クリーンアップ ジョブ の入力を削除すると、クリーンアップ ジョブが停止されます。
• cdc.cdc_jobs テーブルは cdc スキーマに存在し、msdb には存在しません。

これらの制限はありますが、次のオプションのカスタマイズは引き続き実行できます。

• cdc.cdc_jobs テーブルにクエリを実行して、現在の構成情報の詳細を確認します。
• sp_cdc_change_jobストアド プロシージャを使用して、maxtrans および maxscans のオプションを調節します。
• 必要に応じて sp_cdc_drop_job と sp_cdc_add_job を利用し、ジョブを管理します。

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

Azure SQL Database で変更データ キャプチャを有効にすると、SQL Server または Azure SQL Managed Instance で CDC を有効にした場合と同等のパフォーマンスへの影響があります。 ただし、CDC を有効にしたときのパフォーマンスの影響には、次のようないくつかの要因が影響します。

• Azure SQL Database 内の CDC 対応テーブルの数。

• 追跡対象テーブルの変更頻度、またはトランザクションの量。 アクティブなトランザクションがあると、トランザクションがコミットされ、CDC スキャンが追いつくか、トランザクションが中止されるまで、トランザクション ログの切り捨てが行われません。 これにより、トランザクション ログが通常よりも多くなる可能性があるため、トランザクション ログが満杯にならないようにモニターする必要があります。

• CDC の成果物 (CT テーブル、cdc_jobs など) は同じデータベースに格納されるため、ソース データベースに使用可能な領域があることを確認してください。

• 単一のデータベースを持っているか、エラスティック プールの一部であるか。

• エラスティック プール内のデータベースの間でリソースが共有されるため (ディスク領域など)、複数のデータベースで CDC を有効にすると、エラスティック プールのディスク サイズの最大サイズに達するリスクがあります。 CPU、メモリ、ログ スループットなどのリソースを監視してください。 詳細については、「高密度エラスティック プールでのリソース管理」を参照してください。

• エラスティック プール内のデータベースを処理する場合は、CDC 対応テーブルの数と、それらのテーブルが属するデータベースの数を考慮することが重要です。 ワークロードを評価し、エラスティック プールのスケーリングなどの必要な対策を講じることをお勧めします。 詳細については、「Azure SQL Database でエラスティック プールのリソースをスケーリングする」を参照してください。

Azure SQL Database で CDC を使用する場合は、次のベスト プラクティスを検討してください。

• 運用環境のデータベースで CDC を有効にする前に、ワークロードを十分にテストしてください。ワークロードに適した SLO を判断するのに役立ちます。 Azure SQL Database のコンピューティング サイズの詳細については、「サービス レベル」をご覧ください。

• Azure SQL Database で CDC が有効になったら、仮想コアの数をスケーリングするか、Hyperscale などの上位のデータベース層に移行して以前のパフォーマンス レベルを維持することを検討してください。 詳細については、「仮想コア購入モデル - Azure SQL Database」と「Hyperscale サービス レベル」を参照してください。

• 領域使用率を注意深く監視します。 詳細については、「Manage file space for databases in Azure SQL Database」(Azure SQL Database でデータベースのファイル スペースを管理する) を参照してください。

• ログ生成率を監視してください。詳細については、「ユーザー ワークロードと内部プロセスによるリソース使用量」を参照してください。

• CDC スキャンとクリーンアップ プロセスは、通常のデータベース ワークロードの一部です (リソースも消費します)。 テーブルを変更するために行全体が追加され、また更新操作のために事前イメージ化も含まれ、スキャンプロセスとクリーンアップ プロセスがワークロードに追いつかないため、トランザクションの量によってはパフォーマンスが大幅に低下する可能性があります。 ワークロードを評価し、前の推奨事項に従って必要な対策を講じることをお勧めします。 詳細については、この記事の「CDC の管理」セクションを参照してください。

• 待機時間の増加を防ぐために、CDC 対応データベースの数がエラスティック プールに割り当てられた仮想コアの数を超えないようにしてください。 詳細については、「高密度 Elastic Pool でのリソース管理」をご覧ください。

• ワークロードとパフォーマンス レベルに基づき、CDC 保有期間を既定の 3 日間より小さい数に変更して、クリーンアップ プロセスが変更テーブルの変更に確実に対応できるようにすることもご検討ください。 データベース サイズに問題がないことを監視しつつ、保持期間を短縮することをお勧めします。

• 変更が変更テーブルに設定されるときには、サービス レベル アグリーメント (SLA) は提供されません。 1 秒未満の待機時間もサポートされません。

既知の問題と制限事項

ログの積極的切り捨て

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

CDC を有効にする場合は、インデックスを作成またはリビルドする際に [再開可能なインデックス] オプションを使用することをお勧めします。 再開可能なインデックスは、実行時間の長いトランザクションを開いたままにしません。この操作の間はログの切り捨てが可能で、ログ領域をよりよく管理することができます。 詳細については、「オンライン インデックス操作のガイドライン - 再開可能なインデックスに関する考慮事項」を参照してください 。

Azure SQL Database サービス レベル

CDC は仮想コアベースの購入モデル内の任意のサービス レベルのデータベースとエラスティック プールでサポートされていますが、DTU の購入モデルでは、S3 より低いデータベース (Basic、S0、S1、S2 など) はサポートされていません。

Azure SQL Database ログの制限

高速データベース復旧と CDC は、Azure SQL Database では互換性がありません。 これは、CDC スキャンがデータベース トランザクション ログにアクティブにアクセスしてインタラクトするためです。これは、ADR の積極的なログ切り捨て動作と競合する可能性があります。

スケーラビリティと領域管理の問題を回避するには、Azure SQL Database を注意深く監視し、より高いデータベース層へのスケーリングを検討し、ワークロードのニーズに応じてトランザクション ログを拡張できるようにします。

オンライン DDL ステートメントはサポートされていません

データベースで変更変更データ キャプチャが有効になっている場合、オンライン DDL ステートメント はサポートされません。

カスタマイズのキャプチャとクリーンアップ

Azure SQL Database で CDC のキャプチャの頻度とクリーンアップ プロセスを構成することはできません。 スケジューラは、キャプチャとクリーンアップを自動的に実行します。

Azure SQL Database のフェールオーバー

ローカルまたは GeoDR のフェールオーバー シナリオが発生した場合、データベースで CDC が有効になっていれば、フェールオーバーが行われた後、新しいプライマリ データベースでデータ変更をキャプチャしてクリーンするプロセスが自動的に行われます。

Microsoft Entra ID

Microsoft Entra ユーザーとして Azure SQL データベースを作成し、そのデータベースで CDC を有効にした場合、SQL ユーザー (sysadmin ロールのユーザーも含む) は CDC 成果物を無効にしたり変更したりすることはできません。 ただし、別の Microsoft Entra ユーザーは、同じデータベースで CDC を有効または無効にできます。

同様に、SQL ユーザーとして Database を作成する場合、Microsoft Entra ユーザーとして CDC を有効または無効にすることはできません。

Microsoft Entra ユーザーとして Azure SQL Database にデータベースを作成し、CDC を有効にせず、データベースの復元後に CDC を有効にしようとすると、CDC の有効化は失敗します。

この問題を解決するには、Microsoft Entra 管理者アカウントを使用してデータベースに接続し、次の T-SQL を実行します。

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

EXEC sys.sp_cdc_enable_db;

ポイントインタイム復元 (PITR)

Azure SQL Database で SQL ユーザーとして CDC を有効にした場合、ポイントインタイム リストア (PITR) は、サブコア SLO に復元されない限り、復元された データベース に CDC を保持します。 サブコア SLO に復元された場合、CDC アーティファクトは使用できません。

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

トラブルシューティング

このセクションでは、Azure SQL Database 上の CDC に関連するガイダンスとトラブルシューティングの手順について説明します。 CDC 関連のエラーは、キャプチャ プロセスの適切な機能を妨げ、データベース トランザクション ログの拡張につながる可能性があります。

これらのエラーを調べるには、動的管理ビュー のsys.dm_cdc_errors クエリを実行します。 sys.dm_cdc_errors 動的管理ビューでエラーが返される場合は、次のセクションを参照して軽減策の手順を理解してください。

このセクションに含まれるさまざまなトラブルシューティング カテゴリを次に示します。

カテゴリ	説明
変更されたメタデータ	追跡対象のテーブルが変更または削除されたときに CDC に関連した問題を軽減する方法についての情報が含まれています。
データベース領域の管理	データベース領域が使い果たされた際の問題を軽減する方法についての情報が含まれています。
CDC の制限	CDC の制限に起因する問題を軽減する方法についての情報が含まれています。

変更されたメタデータ

エラー 200/208 - 無効なオブジェクト名

• 原因: CDC メタデータが削除されたときに、このエラーが発生する可能性があります。 CDC が正常に機能するためには、手動で CDC schema、変更テーブル、CDC システム ストアド プロシージャ、既定の cdc user のアクセス許可 (sys.database_principals) などの CDC メタデータの変更または cdc user の名前の変更を行ってはいけません。

• 推奨事項: この問題に対処するには、データベースの CDC を無効にして、再度有効にする必要があります。 データベースで変更データ キャプチャを有効にすると、 cdc スキーマ、cdc ユーザー、メタデータ テーブル、その他のシステム オブジェクトがデータベースに作成されます。 データベースに対して CDC が有効になった後、個々のテーブルに対して CDC を手動で再度有効にする必要があります。

エラー 1202 - データベース プリンシパルが存在しないか、ユーザーがメンバーではありません。

• 原因: CDC ユーザーが削除されたときに、このエラーが発生する可能性があります。 CDC が正常に機能するためには、手動で CDC schema、変更テーブル、CDC システム ストアド プロシージャ、既定の cdc user のアクセス許可 (sys.database_principals) などの CDC メタデータの変更または cdc user の名前の変更を行ってはいけません。

• 推奨事項: cdc ユーザーがデータベースに存在し、なおかつ db_owner ロールに割り当てられていることを確認します。 cdc ユーザーを作成するには、「cdc ユーザーの作成とロールの割り当て」の例を参照してください。

エラー 15517 - プリンシパルが存在しないため、データベース プリンシパルとして実行できません

• 原因: この種類のプリンシパルを偽装できないか、アクセス許可がありません。 このエラーは、CDC メタデータが削除された場合、または db_owner ロールの一部ではなくなった場合に発生する可能性があります。 CDC が正常に機能するためには、手動で CDC schema、変更テーブル、CDC システム ストアド プロシージャ、既定の cdc user のアクセス許可 (sys.database_principals) などの CDC メタデータの変更または cdc user の名前の変更を行ってはいけません。

• 推奨事項: cdc ユーザーがデータベースに存在し、なおかつ db_owner ロールに割り当てられていることを確認します。 cdc ユーザーを作成するには、「cdc ユーザーの作成とロールの割り当て」の例を参照してください。

エラー 18807 - レプリケーション システム テーブルのオブジェクト ID が見つかりません

• 原因: このエラーは、SQL Server でレプリケーション システム テーブル '%s' が見からないか、それにアクセスできない場合に発生します。 これは、このテーブルが見つからないか、到達できないことが原因となっている可能性があります。 CDC が正常に機能するためには、手動で CDC schema、変更テーブル、CDC システム ストアド プロシージャ、既定の cdc user のアクセス許可 (sys.database_principals) などの CDC メタデータの変更または cdc user の名前の変更を行ってはいけません。

• 推奨事項: テーブルに対して直接クエリを実行し、システム テーブルが存在していて、アクセスできることを確認してください。 sys.objects システム カタログにクエリを実行し、述語句を is_ms_shipped=1 および schema_name=cdc に設定し、CDC 関連のすべてのオブジェクトを一覧表示します。 クエリでオブジェクトが返されない場合は、データベースの CDC を無効にしてから再度有効にする必要があります。 データベースで変更データ キャプチャを有効にすると、cdc schema、cdc user、メタデータ テーブル、その他のシステム オブジェクトがデータベースに作成されます。 データベースに対して CDC が有効になった後、個々のテーブルに対して CDC を手動で再度有効にする必要があります。

エラー 21050 - sysadmin、または固定サーバーロールが db_ownerのメンバーだけがこの操作を実行できます。

• 原因: cdc ユーザーが db_owner データベース ロールから、または sysadmin サーバー ロールから削除されました。

• 推奨事項: cdc ユーザーに db_owner ロールが割り当てられていることを確認します。 cdc ユーザーを作成するには、「cdc ユーザーの作成とロールの割り当て」の例を参照してください。

データベース領域の管理

エラー 1105 - ファイル グループがいっぱいなので、データベースにオブジェクトの領域を割り当てられませんでした

• 原因: このエラーは、データベースのプライマリ ファイル グループの領域が不足し、SQL Database がそのファイル グループ内のオブジェクト (テーブルやインデックスなど) に割り当てることができない場合に発生します。

• 推奨事項: この問題を解決するには、データベース内の不要なデータを削除して領域に空きを作ります。 安全に削除できるファイル グループ内の未使用のテーブル、インデックス、その他のオブジェクトを識別します。 領域使用率を注意深く監視し、詳細については「Azure SQL Database でデータベースのファイル領域を管理する」を参照してください。

  不要なデータ/オブジェクトを削除することができない場合は、上位のデータベース層にスケーリングすることを検討してください。

エラー 1132 - エラスティック プール が記憶域の上限に達しました。

• 原因: このエラーは、エラスティック プールのストレージ使用量が割り当てられた制限を超えた場合に発生します。

• 推奨事項: この問題を解決するには、エラスティック プールの一部であるデータベースに必要なデータのみを保持するように、データのアーカイブと消去のストラテジを実装します。 領域使用率を注意深く監視します。 詳細については、「Manage file space for databases in Azure SQL Database」(Azure SQL Database でデータベースのファイル スペースを管理する) を参照してください。

  データのアーカイブや不要なデータ/オブジェクトの削除ができない場合は、上位のデータベース層にスケーリングすることを検討してください。

CDC の制限

エラー 2628 - テーブル内の文字列またはバイナリ データが切り捨てられます

• 原因: DDL ステートメントを使用して CDC 対応テーブルの列のサイズを変更すると、後続の CDC キャプチャ プロセスで問題が発生する可能性があります。 sys.dm_cdc_errors 動的管理ビュー (DMV) は、エラー番号 2628 および 8115 など、報告された問題に対して CDC をチェックするために役立ちます。

• 推奨事項: 列サイズを変更する前に、変更に CDC 変更テーブルの既存のデータと互換性があるかどうかを評価する必要があります。 この問題に対処するには、データベースの CDC を無効にして再度有効にする必要があります。 データベースまたはテーブルに対して CDC を有効にする方法の詳細については、この記事の「Azure SQL Database の CDC を有効にする」および「テーブルの CDC を有効にする」セクションを参照してください。

エラー 22830 - このバージョンの SQL Server では、組み込み関数 'SUSER_SNAME' を権限借用コンテキストで使用することはできません。

• 原因: このエラーは、CDC の有効化中に、SUSER_SNAME() で create_table への呼び出しがあるデータベースにユーザー トリガーが存在する場合に発生します。 次の Transact-SQL スクリプトを使用してトリガーを一覧表示できます。 このコマンドは、オブジェクト トリガーと、対応する object_id の詳細を提供します。

  SELECT name,
      object_id
  FROM sys.triggers
  WHERE parent_class_desc = 'DATABASE'
      AND is_disabled = 0;
  

  トリガー定義を取得したら、次のスクリプトを使用して SYSTEM_USER に行われている呼び出しを検索できます。

  SELECT OBJECT_DEFINITION(object_id) AS trigger_definition;
  

• 推奨事項: この問題を解決するには、前のスクリプトから取得したユーザー トリガーごとに次の手順に従います。

  • トリガーを無効にする
  • CDC を有効にする
  • トリガーを再度有効にする

詳細については、「DISABLE TRIGGER (Transact-SQL)」を参照してください。

エラー 913 - システム CLR データ型のテーブルの変更を処理する際に CDC キャプチャ ジョブが失敗します

• 原因: このエラーは、システム CLR データ型のテーブルで CDC を有効にして、DML を変更した後、CDC キャプチャ ジョブで他のテーブルに関連した変更を処理している間に同じテーブルで DDL の変更が行われる場合に発生します。

• 推奨事項: 推奨される手順は、テーブルに対する DML を休止し、変更を処理するキャプチャ ジョブを実行して、テーブルの DDL を実行し、DDL の変更を処理するキャプチャ ジョブを実行してから、DML の処理を再度有効にすることです。 詳細については、「変更を処理するときに CDC キャプチャ ジョブが失敗する」を参照してください。

ユーザーを作成してロールを割り当てる

cdc userが削除された場合は、ユーザーを手動で追加し直すことができます。

次の T-SQL スクリプトを使用して、ユーザー (cdc) を作成し、適切なロール (db_owner)を割り当てます。

IF NOT EXISTS (
    SELECT *
    FROM sys.database_principals
    WHERE NAME = 'cdc'
)
BEGIN
    CREATE USER [cdc] WITHOUT LOGIN
    WITH DEFAULT_SCHEMA = [cdc];
END

EXEC sp_addrolemember 'db_owner', 'cdc';

ロール メンバーシップを確認して追加する

cdc ユーザーが sysadmin または db_owner のいずれかのロールに属しているかどうかを確認するには、次の T-SQL クエリを実行します。

EXECUTE AS USER = 'cdc';

SELECT is_srvrolemember('sysadmin'), is_member('db_owner');

cdc ユーザーがどちらのロールにも属していない場合は、次の T-SQL クエリを実行して、cdc ユーザーに ロールを追加db_ownerします。

EXEC sp_addrolemember 'db_owner' , 'cdc';

関連するコンテンツ

• 変更データの処理
• データ変更の追跡
• 変更データ キャプチャの管理と監視
• テンポラル テーブル