Oracle を使い続けながら Fabric に分析基盤を寄せたいなら、今回の Fabric の Oracle database mirroring の一般提供はかなり大きな更新です。Microsoft の新着情報では 2026 年 3 月に GA が案内され、Oracle Autonomous Database（Oracle 自律データベース）などのサポート更新も明示されました。しかも Mirroring は、Oracle データの読み取り専用コピーを OneLake に作り、ほぼリアルタイムで更新できます。 (Microsoft Learn)
ただし、ここで期待値を間違えると失敗します。Fabric の Oracle database mirroring は、Oracle をそのまま Fabric に“移行”する機能ではなく、あくまで分析用の継続レプリケーションです。だからこそ、既存 Oracle を残したまま Power BI、Spark、SQL 分析へつなぐ用途には強い一方で、業務アプリの置き換えや複雑な DB 機能の代替をそのまま担うものではありません。 (Microsoft Learn)
この記事では、Fabric の Oracle database mirroring で何が同期できるのか、Oracle 利用企業の移行余地はどこまで広がるのか、どこから先は別手段を選ぶべきかを、実務目線で整理します。
Fabric の Oracle database mirroring が GA で変わったこと
一般提供で意味を持つのは「対応範囲」と「本番検討のしやすさ」
今回の一般提供で重要なのは、Oracle から Fabric への取り込みが、単なるプレビュー確認ではなく本番前提で比較・検討しやすくなったことです。新着情報では Oracle Autonomous Database などのサポート更新を含む GA が案内され、制限事項ページでもサポート環境として Oracle 自律データベースが明記されています。対応環境は Oracle 10 以降かつ LogMiner 有効を前提に、オンプレミス、OCI、Oracle Database@Azure、Exadata まで含まれます。 (Microsoft Learn)
つまり、Oracle を全面刷新しなくても、既存の DB 資産を OneLake 側へ継続複製して、Power BI や Spark、ノートブック、SQL 分析に載せるルートが明確になったと言えます。Fabric の Mirroring は、外部データを OneLake に継続レプリケートし、Fabric の各サービスで使える形にする設計です。 (Microsoft Learn)
Fabric の Oracle database mirroring で実際に同期できるもの
同期の中心は通常テーブルと分析用コピー
Fabric の Oracle database mirroring で作られるのは、OneLake 上のミラー化データベースと、分析用の SQL 分析エンドポイントです。ミラー化された Oracle データは読み取り専用コピーとして OneLake に入り、SQL 分析エンドポイントからテーブル参照、ノーコード クエリ、SQL ビューやインライン テーブル関数、ストアド プロシージャ作成、アクセス制御、他の Warehouse や Lakehouse との接続まで行えます。 (Microsoft Learn)
Mirroring で入ったデータは OneLake の Delta Lake テーブル形式で継続レプリケートされるため、SQL だけでなく Spark 側からも扱いやすいのが実務上の強みです。Oracle の運用系データを、分析・BI・AI のための共通データ面に載せたい企業には、この構成がかなり噛み合います。 (Microsoft Learn)
取り込み単位は全表か個別かを選べる
セットアップ時は、自動モードですべてのテーブルをミラー化することも、手動で必要なオブジェクトだけを選ぶこともできます。さらに、ミラー化データベースではソース スキーマ階層が保持されるため、SQL 分析エンドポイント、Spark Notebook、セマンティック モデル側で同じ論理構造を扱いやすいのも利点です。 (Microsoft Learn)
一方で、現時点でレプリケート対象になるのは通常テーブルが中心です。公式のトラブルシューティングでは、ビューは現在サポートされず、レプリケーション対象は通常テーブルのみとされています。Oracle 上でビューを厚く使っている場合は、そのまま持ち込める前提で設計しない方が安全です。 (Microsoft Learn)
Oracle 連携の現実性を見極める 3 つの選択肢
まずは目的で切り分ける
Oracle 連携を実務で考えると、手段は大きく 3 つです。目的で切り分けないと、Mirroring に期待しすぎたり、逆に Copy ベースで余計な運用を抱えたりします。 (Microsoft Learn)
| 手段 | 向く用途 | 強み | 先に知るべきこと |
|---|---|---|---|
| Fabric の Oracle database mirroring | 近リアルタイム分析、OneLake 統合、Power BI / Spark 活用 | ゼロ ETL で読み取り専用コピーを継続同期しやすい | OPDG 前提。ビューや一部 DDL に制約 |
| Data Factory の Oracle コネクタ | バッチ連携、変換、フルロード / 追記、個別パイプライン | Dataflow Gen2、コピー アクティビティ、コピー ジョブを選べる | ゲートウェイに OCMT が必要 |
| Open mirroring + Oracle GoldenGate 23ai など | 既存 CDC 基盤の活用、ハイブリッド / マルチクラウド | パートナー経由でリアルタイム統合の余地が広い | 製品選定とアーキテクチャ設計が前提 |
一番相性がよいのは「Oracle は残し、分析を Fabric へ」
Fabric の Oracle database mirroring が特に刺さるのは、「Oracle はまだ基幹で使うが、分析は Fabric に寄せたい」ケースです。逆に、変換ロジック主体なら Data Factory、すでに GoldenGate 系の CDC を持っているなら Open mirroring を併用する方が現実的です。今回の GA で進みやすくなったのは「Oracle 離脱」そのものより、「Oracle 資産の分析活用を Fabric 側へ寄せる」計画だと考えるとズレにくいです。 (Microsoft Learn)
コストの見方もここで変わります。Oracle ミラーリングの公式説明では、OneLake へのレプリケーションに使う計算と、容量サイズに基づく OneLake ストレージには課金せず、主に SQL・Power BI・Spark でクエリするときの計算が課金対象と案内されています。初期導入の見積もりでは、「同期そのものの費用」より「利用側ワークロードの増え方」を見る方が実務的です。 (Microsoft Learn)
導入前に必ず確認したい制約と前提条件
- Oracle 側の対応可否は、Oracle 10 以降 + LogMiner、有効な Fabric ワークスペース、そして OPDG という 3 点が最低ラインです。対応環境にはオンプレミス、OCI、Oracle Database@Azure、Exadata、Oracle Autonomous Database が含まれ、Fabric 側は Trial もしくは Premium 容量が必要です。 (Microsoft Learn)
- 接続方式は、現時点では Oracle への接続に On-Premises Data Gateway が前提です。制限事項ページでは OPDG 3000.282.5 以降が必要とされ、チュートリアルでも最新の OPDG を毎月更新することが推奨されています。クラウド上の Oracle でも「ゲートウェイ不要」とは考えない方が安全です。 (Microsoft Learn)
- Oracle 側では、ARCHIVELOG を有効のまま維持し、データベース レベルとテーブル レベルの補足ログを有効にする必要があります。システムが自動適用を試みる場合もありますが、Oracle ユーザーに ALTER DATABASE と ALTER TABLE 権限がないと、DBA が介入して設定する必要があります。同期ユーザーには CREATE SESSION、SELECT ANY TABLE、LOGMINING などの権限も求められます。 (Microsoft Learn)
- テーブル設計の相性確認も必須です。公式に列挙されているのは VARCHAR2、NVARCHAR2、NUMBER、FLOAT、DATE、RAW、ROWID、CHAR / NCHAR、TIMESTAMP WITH LOCAL TIME ZONE、INTERVAL 系などで、DDL 変更は列追加・削除・名前変更の一部対応にとどまり、列型の変更は未サポートです。PK がなくても一意インデックスがあれば対象にできますが、PK も一意インデックスもないテーブルは対象外で、テーブル名は長さ 30 未満である必要があります。ドキュメントに載っていない型を多用するなら、先に PoC で確認した方が確実です。 (Microsoft Learn)
- スケール条件も見落としやすいポイントです。Oracle mirroring は、現時点で 1 ワークスペースあたり 1 Oracle サーバー、1 OPDG インスタンス、1 Oracle ミラー成果物という整理で、ミラー化できるテーブル数は最大 1,000 です。さらに一般的なミラー化データベースの制限として、1 日あたり最大 1 TB の変更データ キャプチャが案内されています。大規模更新系は事前検証が無難です。 (Microsoft Learn)
- 同期後の権限設計まで含めて考えると、Fabric 側で行レベル セキュリティ、列レベル セキュリティ、動的データ マスキングを使えるのは大きな利点です。Oracle 側で閉じていたデータを広く見せるほど、この設計が効いてきます。 (Microsoft Learn)
失敗しやすいポイント
技術面でつまずきやすいところ
最初から自動モードで全表を流すのは、PoC ではあまりおすすめできません。自動モードは便利ですが、ビュー非対応、DDL 制約、データ型差異、PK / 一意インデックス条件、1,000 テーブル上限といった論点を同時に踏み抜きやすいからです。最初は価値の高いテーブルだけを手動選択する方が、問題の切り分けが速くなります。 (Microsoft Learn)
もうひとつ多いのが、「OneLake にデータはあるのに SQL 分析エンドポイントで見えない」というパターンです。公式ドキュメントでは、OneLake に着地していても SQL 分析エンドポイント側のメタデータ同期遅延が原因になることがあるため、監視ページの確認とメタデータの手動更新が案内されています。同期できていないと決めつける前に、表示レイヤーの遅延を疑うべきです。 (Microsoft Learn)
運用面でつまずきやすいところ
PoC を Trial 容量のまま放置すると、継続運用の前提が崩れます。トラブルシューティングでは、Fabric 容量の一時停止でミラーリングが停止し、再開後は手動でレプリケーションを再開する必要があること、長時間停止では再シードが起こり得ること、試用版容量の期限切れでミラーリングが停止することが案内されています。PoC をやるなら、容量と停止手順まで先に決めておくべきです。 (Microsoft Learn)
さらに見落としがちなのが所有者依存です。ミラー化データベースは現時点で所有権変更をサポートしておらず、所有者が無効になると再作成が必要になります。個人アカウントで作って終わりにせず、運用主体を最初から決めておく方が安全です。 (Microsoft Learn)
PoC を始めるならこの順番
テーブル選定から始める
最初の対象に向くテーブル
最初の PoC で向いているのは、受注、在庫、出荷、会員、購買など、変化が分かりやすく、かつビュー依存が少ないテーブルです。逆に、複雑なビュー束ねや頻繁な型変更を前提にした領域は、最初の題材にしない方が失敗しにくいです。これは Mirroring が通常テーブル中心で、DDL 変更にも制約があるためです。 (Microsoft Learn)
- まず 5〜20 テーブル程度に絞り、PK または一意インデックスの有無、型の相性、テーブル名の長さ、ビュー依存の有無を確認します。ここで通るかどうかが、その後の展開速度をほぼ決めます。 (Microsoft Learn)
- DBA と一緒に、ARCHIVELOG、有効な補足ログ、同期ユーザーの権限を整えます。特に補足ログは「後でやる」では進みません。 (Microsoft Learn)
- OPDG を最新にし、Oracle に到達できるネットワークとファイアウォールを確認します。ミラーリング側のチュートリアルでも、必要に応じてクラウド ファイアウォールの変更が必要と案内されています。 (Microsoft Learn)
- Fabric では
New > Mirrored Oracleから開始し、サーバー指定は TNS エイリアス、接続記述子、Easy Connect Plus のいずれかを使います。認証は基本認証で接続し、最初は手動モードで対象テーブルだけを選びます。 (Microsoft Learn) - 作成後は監視ページでレプリケーション状態を見ながら、OneLake 側にデータが着地しているか、SQL 分析エンドポイント側に見えているかを切り分けます。SQL 側だけ遅い場合は、メタデータ更新を疑います。 (Microsoft Learn)
- PoC が通ったら、Fabric 側で行レベル・列レベルのセキュリティや動的データ マスキングを設計し、そのまま Mirroring を拡張するのか、Data Factory や Open mirroring を併用するのかを決めます。ここで初めて「本番化の形」が見えてきます。 (Microsoft Learn)
まとめ
今回の GA で、Fabric の Oracle database mirroring は「Oracle を捨てずに Fabric に取り込む」選択肢としてかなり現実的になりました。特に Oracle Autonomous Database を含む対応範囲の明確化は大きいです。ただし本質は分析用の継続レプリケーションなので、まずは重要テーブルを手動で選ぶ小さな PoC を組み、ログ設定・データ型・キー有無・運用アカウントを確認してから本格展開するのが最短です。Oracle 資産の分析活用を早く前に進めたいなら、ここから着手するのがいちばん失敗しにくい進め方です。 (Microsoft Learn)
コメント