Microsoft Fabric にて Azure SQL Database からデータを取得する際のミラーリングおよびコピージョブの利用指針

Last updated at 2026-02-12Posted at 2026-02-11

概要

Microsoft Fabric にて Azure SQL Database からデータを取得する際の、ミラーリングおよびコピージョブの利用指針を整理します。コピージョブは増分取り込みの方式として、CDC をベースにした方法とウォーターマーク列をベースとした方法に大別でき、以下の 3 つの方法として整理できます。

ミラーリング
CDC が有効なテーブルをベースとしたコピージョブ（CDC + コピージョブ）
テーブルのウォーターマーク列をベースとしたコピージョブ（ウォーターマーク列 + コピージョブ）

実装方法については下記の記事にて紹介しています。

本記載内容は 2026年2月11日時点での情報となっており、最新の情報をドキュメントにて確認するようにしてください。

基本的な利用指針

大枠の結論（選定の軸）は下記の通りです。各方式にはメリット/デメリットがあり、要件（レイテンシ、DELETE 反映、ソース側制約、運用体制、コスト）に応じて選定する必要があります。

“ほぼリアルタイム”で OneLake に同期し続けたい、かつ「Fabric 側でそのまま分析用レプリカが欲しい」場合はミラーリング。ただし、CDC と共存不可、制約が多い、ソース権限制御が OneLake に反映されない点は設計上の注意が必須です。
“バッチ（スケジュール）同期”でよく、DELETE も含めて正確に増分反映したい場合は「CDC + コピージョブ」。ただし Azure SQL 側に CDC を有効化する副作用（ログ/リソース/運用） が最も大きい点に留意が必要です。
ソースに CDC を入れられない（権限/運用/性能/方針） 場合は「ウォーターマーク列 + コピージョブ」。ただし原則として DELETE/TRUNCATE を検出できないため、要件次第では「ソフトデリート化」「差分突合」「全件再連携」など別対策が必要になります。

観点	1. ミラーリング	2. CDC + コピージョブ	3. ウォーターマーク + コピージョブ
レイテンシ	低め）	ジョブ実行間隔次第	ジョブ実行間隔次第
DELETE レコードの特定	〇	〇	×
セカンダリーでの実施可否	×	〇	〇
テーブルごとの再取り込み	不可	GUI で可	GUI で可
Azure SQL Database 側の前提	書き込み可能なプライマリの監視	CDC を有効化	更新日時/連番など「ウォーターマーク列」が必要
主な注意事項	1 DB で 1つのミラーリングのみで、最大 500 テーブル	全テーブルに対して CDC の有効化が必須	DELETE/TRUNCATE を検出不可、ウォーターマーク列の設計/更新品質に依存、DDL 変更は自動追従しない

方法論の詳細

1. ミラーリング

仕組み/特徴（前提）

Fabric でミラー化データベースを作ると、OneLake（Delta）へ継続的にレプリケートされます。データは OneLake 上に格納され、ミラーリングであるためコンピューティングのコストはかからず、ストレージのコストは容量ごとに無料枠が提供されます。

Pros

ETL を実装せずに継続同期できるため、ジョブ管理の開発／運用コストを最小化できる。
ミラーリングによるコストメリットを享受できる。
DML（INSERT/UPDATE/DELETE/UPSERT）反映の確認が容易。
CDC の有効化などのデータベースの設定変更が不要（ただし、CDC が有効だとミラーリング自体できない）。
ウォーターマーク列（UpdatedAt など）の考慮が不要。

Cons

1 つのミラーリングしか設定できないこと。 *1
上限 500 テーブル。 *2
CDC 有効化 DB ではミラーリング不可（CDC / Synapse Link 有効済みだと不可）。 *3
基本的には停止が不可（停止した場合に再リシードの発生リスク）。 *4
VNet Data Gateway 経由でデータを取得する場合に停止できないことがコスト増加要因になり得る。 *5
Azure SQL Database にてログ監視が必須。 *6
初期スナップショット時に CPU/IOPS が増加する可能性がある。 *7
ログ逼迫時の自動再シードによりリソースへ高負荷がかかる可能性がある。 *8
手動でテーブルごとに再リシードする方法がない。 *9
運用上不要となったデータが削除された場合(例: 過去3年分のみトランザクションデータを管理する運用)にデータへアクセスできなくなる。 *10
その他の制限事項がある *11

*1 ドキュメントにて下記のように記載あり。

データベースが別の Fabric ワークスペースに既にミラー化されている場合、Azure SQL Database をミラー化できません。

出所： Azure SQL Database からのファブリックミラー化データベースの制限事項と動作 - Microsoft Fabric | Microsoft Learn

*2 ドキュメントにて下記のように記載あり。

Fabric にミラー化できるテーブルの最大数は 500 テーブルです。現在、500 の制限を超えるテーブルはレプリケートできません。

出所： Azure SQL Database からのファブリックミラー化データベースの制限事項と動作 - Microsoft Fabric | Microsoft Learn

*3 ドキュメントにて下記のように記載あり。

データベースで Change Data Capture (CDC)、Azure Synapse Link for SQL が有効になっている場合、またはデータベースが別の Fabric ワークスペースに既にミラー化されている場合、Azure SQL Database をミラー化できません。

出所： Azure SQL Database からのファブリックミラー化データベースの制限事項と動作 - Microsoft Fabric | Microsoft Learn

*4 ドキュメントにて下記の記載あり。

レプリケーションを停止し、レプリケーションを開始します。すべてのテーブルが再シードされ

出所：Azure SQL Database からのファブリックミラー化データベースの制限事項と動作 - Microsoft Fabric | Microsoft Learn

*5 停止するとすべてのテーブルが再シードされるため、停止は不可と判断。

*6 プライマリーデータベースでのみサポートされているため既存システムへの影響の監視が重要であると判断。

Azure SQL Database のファブリックミラーリングは、書き込み可能なプライマリデータベースでのみサポートされます。

出所： Azure SQL Database からのファブリックミラー化データベースの制限事項と動作 - Microsoft Fabric | Microsoft Learn

*7 ドキュメントにて下記の記載あり。

初期スナップショット中は、CPU と IOPS の両方 (ページを読み取るための 1 秒あたりの入力/出力操作) に対して、ソースデータベースのリソース使用率が高くなる可能性があります。

出所： Azure SQL Database からの Microsoft Fabric ミラー化データベース - Microsoft Fabric | Microsoft Learn

*8 ドキュメントにて下記の記述あり。

重要な OLTP トランザクションの書き込みエラーからオペレーショナルデータベースを保護するために、Azure SQL Database と Azure SQL Managed Instance のミラーリングでは、トランザクションログを切り捨てて、Fabric へのデータベースミラーリングを再初期化できる自動復元機能が使用されます。

出所： Azure SQL Database からのファブリックミラー化データベースの自動再シード - Microsoft Fabric | Microsoft Learn

*9 自動リシード機能があるが、手動で再取り込みする機能を未確認。

Azure SQL Database からのファブリックミラー化データベースの自動再シード - Microsoft Fabric | Microsoft Learn

*10 DELETE が反映されるため想定通りの動作。2026年2月11月時点で Change Data Feeds 機能がサポートされていないことから、 DELETE レコードを特定することは困難。

Enable Change Data Feed (CDF) on a Mirror Database - Microsoft Fabric Community

*11 下記のドキュメントにて記載。

Azure SQL Database からのファブリックミラー化データベースの制限事項と動作 - Microsoft Fabric | Microsoft Learn

向いているケース

ほぼリアルタイム寄りの継続同期が欲しい
CDC を使えない/使いたくない（ただし CDC 有効だとミラー自体不可）
ソースのテーブル/型/機能がミラー制約に収まる
ログ監視/再シード前提の運用を受け入れられる

2. CDC + コピージョブ

仕組み/特徴（前提）

Copy job の CDC は「挿入・更新・削除されたレコードを含む変更データを自動的にレプリケートする。設定上は「最初はフルロード、その後 CDC で増分コピー」が基本です。

Pros

スケジュールで 取り込み頻度/コストを制御できる。
Copy job は “最後に成功した状態を自動追跡” し、失敗しても状態は変わらず、成功した地点から再開する。
CDC により DELETE も扱える。
書き込み先のテーブルを柔軟に作成できる。 *1
Azure SQL Database にてセカンダリー DB を参照可能。 *2
リセットによりテーブルごとに再連携が可能。 *3

*1 下記にて検証を実施。

Microsoft Fabric のコピージョブ利用時において Lakehouse のテーブルを事前作成できるかの検証結果 #MicrosoftFabric - Qiita

*2 下記にて検証を実施。

Microsoft Fabric のコピージョブにてレプリカ先の Azure SQL Database から CDC が有効なテーブルをソースとする方法 #MicrosoftFabric - Qiita

*3 GUI にてリセットできることを確認。

Cons

CDC/非CDCテーブルを同じジョブで選ぶと、全部がウォーターマーク扱いになる。 *1
カスタムキャプチャインスタンス非対応。 *2
コピージョブと書き込み先のデータストア（Lakehouse 等）のコストがかかる。 *3
Azure SQL Database にて CDC 有効化という DB 変更が必須。 *4
トランザクションログ増加・切り捨て遅延が発生するリスクがある。 *5
CDC 有効化に伴う制約（TRUNCATE TABLE が不可）。 *6
保持期間とジョブ間隔の整合が必須。 *7
DDL 変更は Copy job 側が自動追従しない。 *8
オンラインインデックス操作が不可となる *9
列ストアインデックスが設定不可となる *10
その他の制限事項がある *11

*1 ドキュメントにて下記の記載あり。

コピージョブで CDC 対応と非 CDC 対応の両方のソーステーブルが選択されている場合、すべてのテーブルが透かしベースの増分コピーとして扱われます。

出所：コピージョブにおける変更データキャプチャ (CDC) - Microsoft Fabric | Microsoft Learn

*2ドキュメントにて下記の記載あり。

カスタムキャプチャインスタンスはサポートされていません。既定のキャプチャインスタンスのみがサポートされます。

出所：コピージョブにおける変更データキャプチャ (CDC) - Microsoft Fabric | Microsoft Learn

*3 書き込み先のデータストアのコンピューティングが必要となるため。

*4 CDC はテーブルごとに設定する必要あり。

*5 ドキュメントにて下記の記載あり。

CDC を有効にすると、トランザクションログの使用率が高くなる場合があります。

出所： Azure SQL Database を使用した変更データキャプチャ (CDC) - Azure SQL Database | Microsoft Learn

*6 ドキュメントにて下記の記載あり。

テーブル '%.*ls' は、レプリケーションでパブリッシュされているか、Change Data Capture が有効になっているため、切り捨てることができません。

出所：イベントとエラーのデータベースエンジン (4000 ~ 4999) - SQL Server | Microsoft Learn

*7 ドキュメントにて下記の記載あり。

CDC ログの保持期間が、スケジュールされた実行の間隔よりも長くなることを確認してください。そうしないと、保持期間内に処理されないと、CDC によってキャプチャされた変更されたデータが失われる可能性があります。

出所：コピージョブにおける変更データキャプチャ (CDC) - Microsoft Fabric | Microsoft Learn

*8 ドキュメントにて下記の記載あり。

コピージョブでは、DDL はまだサポートされていません。

出所： [コピージョブにおける変更データキャプチャ (CDC) - Microsoft Fabric | Microsoft Learn](https://learn.microsoft.com/ja-jp/fabric/data-factory/cdc-copy-job#known-l imitations)

*9 ドキュメントにて下記の記載あり。

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

出所： Azure SQL Database を使用した変更データキャプチャ (CDC) - Azure SQL Database | Microsoft Learn

*10 ドキュメントにて下記の記載あり。

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

出所：変更データキャプチャとその他の機能 - SQL Server | Microsoft Learn

*11 下記のドキュメントにて記載あり。

向いているケース

同期は “準リアルタイムではなく定期（5分/1時間/日次など）” で良い
ハード DELETE を反映したい
ソースに CDC を入れられる（db_owner 付与、change table 増、TRUNCATE 禁止を許容）
可能ならレプリカから読む設計でプライマリ負荷を抑えたい

3. ウォーターマーク + コピージョブ

仕組み/特徴（前提）

`前回の実行とウォーターマーク列（タイムスタンプや ID など）を比較して変更を検出し、追加またはマージする。

Pros

CDC なしで増分取り込みができる。
Copy job の “状態管理（最後に成功した実行から再開）” の恩恵は CDC と同様に得られる。
書き込み先のテーブルを柔軟に作成できる。
DB 変更コストが比較的小さい。
必要権限も最低限 SELECT で足りる運用にしやすい（Qiita 記事でも最低限 SELECT 付与の記載）。
リセットによりテーブルごとに再連携が可能。

Cons

DELETE を捕捉できない。 *1
TRUNCATE TABLE を捕捉できない。 *2
ウォーターマーク列の設計/更新が必須。 *3
DDL 変更は Copy job 側が自動追従しない。 *4

*1 DELETE されたレコードはウォーターマーク列が更新されないため差分データとして抽出不可。

*2 TRUNCATE TABLE されたレコードはウォーターマーク列が更新されないため差分データとして抽出不可。

*3 ウォーターマーク列が更新されない場合などに差分データを抽出できずソースとの不整合が発生。

*4 ドキュメントにて下記の記載あり。

コピージョブでは、DDL はまだサポートされていません。

出所：コピージョブにおける変更データキャプチャ (CDC) - Microsoft Fabric | Microsoft Learn

向いているケース

ハード DELETE/TRUNCATE を Fabric 側に反映する必要がない（論理削除で代替できる）
DB 側の設定変更（CDC）を避けたい
UpdatedAt/連番など信頼できるウォーターマーク列が既にある/容易に追加できる

監視関連ドキュメント

注意事項

ChatGTP にて提示されたリンクを記載しており、誤っている可能性があります。

Microsoft Fabric ミラーリング利用時の監視関連

Azure SQL 側の運用監視

Change Data Caputer 利用時の監視関連

監視に関するドキュメント

変更データキャプチャの管理と監視 - SQL Server | Microsoft Learn

CDC の監視（DMV）

トランザクションログの監視

sys.dm_db_log_space_usage（ログ使用量/逼迫の確認）)

Geo レプリカ利用時の監視関連

レプリケーション状態・遅延（DMV）

フェールオーバー前提の同期完了チェック

sys.sp_wait_for_database_copy_sync（planned failover 前の同期待ち）)

まとめ

ミラーリング：

ログ切り捨て抑止（長時間トランザクション＋追従遅延）を起点に障害化し得るため、ログ監視と “再シード前提” の運用が必要。
初期スナップショットの CPU/IOPS が上がる可能性がある。
CDC と共存不可（将来 CDC を使う計画があるなら要注意）。

CDC＋コピージョブ：

CDC による追加オブジェクト/ログスキャン/保持期間設計が必要。
CDC 設定による運用変更が必要となる可能性がある。
保持期間 < ジョブ間隔だと変更取り逃しリスクがある。

ウォーターマーク＋コピージョブ：

DB 機能追加は最小だが、DELETE/TRUNCATE を拾えないため、要件次第で設計として不成立となり得る。
ウォーターマーク列の更新品質がそのまま同期品質になる（過去にウォーターマーク列のバグにより差分連携が不可となった体験がある）。

Microsoft Fabric にて Azure SQL Database からデータを取得する際のミラーリングおよびコピージョブの利用指針

概要

基本的な利用指針