Oracle から Microsoft Fabric へ ― 4 段階ロードマップ
13 Nov 2026|10 Min Read|
0|
0
0| 0
目次
Oracle から Microsoft Fabric へ ― 4 段階ロードマップ
― 「全部移す」でも「何もしない」でもない ― 4 段階ロードマップと移行準備チェックリスト
このガイドのねらい
- Oracle のうち「何を移し、何を残すか」を判断できるようにする
- リスクを抑えた 4 段階の移行ロードマップを理解する
- 移行前に確認すべき項目をチェックリストで漏れなく押さえる
- Pulse Convert で PL/SQL の変換と突合を自動化する（初期自動変換精度 70%～90%）
- お問い合わせ：Admin@innovationalofficesolution.com
1. 移行の前提：Oracle をやめる話ではない
Oracle Database 19c は Premier Support が2029年12月31日、Extended Support が2032年12月31日まで提供されます。期限に追われて移行するケースは多くありません。
それでも見直しが進むのは、次のような課題があるからです。
- 基幹 DB の上で重い集計レポートを動かしており、月末にオンライン処理が遅くなる
- 分析のために CPU を増やすと、ライセンスと保守費用もそれに応じて増える
- PL/SQL の夜間バッチを理解している担当者が限られている
- Power BI や機械学習で使うデータを、毎回 CSV で抜き出している
基幹のトランザクション処理は Oracle に残し、分析の負荷と処理だけを Fabric に移す ― これが、多くの企業にとって現実的な答えです。
2. 4 段階のロードマップ
| 段階 | 期間の目安 | やること | 得られる効果 |
|---|---|---|---|
| 第1段階：診断 | 2～3 週間 | AWR と実行履歴で負荷の内訳を調べ、PL/SQL と依存関係を棚卸し | 何を移せば効果が出るかが明確になる |
| 第2段階：負荷の切り離し | 2～4 週間 | Oracle ミラーリングで OneLake に複製し、重いレポートの参照先を切り替え | 基幹 DB の負荷が下がる。コード変換前に効果が出る |
| 第3段階：処理の移行 | 6～12 週間 | PL/SQL の集計・加工処理を T-SQL / PySpark に変換 | 夜間バッチの短縮、属人化の解消 |
| 第4段階：最適化と廃止 | 2～4 週間 | 並行稼働・突合の後、Oracle 側の分析用オブジェクトと複製 DB を廃止 | 分析用リソースとライセンスの見直し |
Microsoft Fabric の Oracle ミラーリングは、Oracle の LogMiner による変更ログを使い、オンプレミスデータゲートウェイ経由でデータを OneLake にほぼリアルタイムで複製します。Microsoft によると、レプリケーションに使うコンピュートは課金されず、OneLake のストレージも容量のサイズに応じた範囲までは無償です。第2段階でこの仕組みを使うことで、コードの変換を待たずに基幹 DB の負荷を下げられます。
3. 移行準備チェックリスト
□ ピーク時間帯に基幹 DB の負荷を生んでいるレポート・クエリの上位を特定したか
□ PL/SQL パッケージ・プロシージャ・トリガー・ジョブの一覧と依存関係を出したか
□ 1年以上実行されていないオブジェクトを廃止候補として業務部門に確認したか
□ LogMiner を利用できる設定か（アーカイブログの有無など）を DBA と確認したか
□ オンプレミスデータゲートウェイを置くサーバーとネットワーク経路を決めたか
□ 文字コード（JA16SJISTILDE など）と UTF-8 への変換方針を決めたか
□ 空文字と NULL、DATE 型の時刻部分の扱いを検証項目に入れたか
□ 並行稼働の期間と、突合の合格基準（差異ゼロ、または説明済み）を業務部門と合意したか
4. PL/SQL 変換の考え方
| PL/SQL のパターン | Fabric での書き換え |
|---|---|
| カーソル FOR ループ＋1 行ずつ UPDATE | 集合演算の MERGE |
| BULK COLLECT / FORALL | 集合処理 / Spark DataFrame |
| EXECUTE IMMEDIATE（動的 SQL） | パラメーター付きノートブック |
| ROWNUM / CONNECT BY | ROW_NUMBER / 再帰 CTE |
| DECODE / NVL | CASE / COALESCE |
| シーケンス | IDENTITY / 代理キー生成 |
| マテリアライズドビュー | Gold 層テーブル / Direct Lake セマンティックモデル |
| DBMS_SCHEDULER | Data Factory パイプライン |
| VPD | 行レベルセキュリティ |
一行ずつ処理するカーソルループは、Fabric では集合演算に書き換えることで、処理時間が大きく短くなることがほとんどです。
5. 結果を変えてしまうデータ型の違い
- 空文字：Oracle では '' が NULL と同じ扱いになります。T-SQL や Spark では別物のため、件数がずれる最大の原因になります。
- DATE 型：Oracle の DATE は時刻も持っています。日単位で集計すると、深夜0時前後の扱いでずれが出ることがあります。
- 精度指定のない NUMBER：Fabric では DECIMAL の精度と桁数を明示します。金額の丸め誤差に注意が必要です。
- 文字列の長さ：SUBSTRB や LENGTHB などバイト単位の関数は、文字単位の関数に書き換え、意図を業務部門に確認します。
6. 参考事例：Emulus Consulting
Emulus Consulting は、このロードマップに沿って、精密機器メーカーの Oracle を対象に移行を進めました。
- 第2段階で主要テーブル 860 本をミラーリングし、月末の基幹 DB の CPU 使用率のピークを 92% から 58% に低減
- 第3段階で PL/SQL 470 本を初期自動変換精度 85% で変換
- 夜間バッチ：5 時間 10 分 → 55 分
- プロジェクト期間 16 週間、分析用途の Oracle リソースと関連費用を 36% 削減
7. Pulse Convert でできること
- PL/SQL の解析：依存関係、実行頻度、複雑度を自動で一覧化
- 自動変換：T-SQL・PySpark・パイプラインを生成。初期自動変換精度 70%～90%
- 移行順序の提案：依存関係と効果の大きさから、段階ごとの対象を提案
- PulseQA：件数、合計値、NULL、日付の境界を新旧で自動比較
- 専門家による仕上げ：残り 10%～30% を当社の専門家が仕上げる
よくある質問（FAQ）
A.第4段階で分析用途のオブジェクトと複製 DB を廃止した後、必要なリソースを見直すのが一般的です。
A.変更ログを使うため影響は小さく、現在の重いレポートが本番 DB にかけている負荷よりはるかに軽くなります。
A.いいえ。分析・集計に関わる処理だけが対象で、基幹の処理は Oracle に残します。
A.多くの場合、4 段階全体で 12～20 週間です。
A.選んでいただいた PL/SQL またはワークフロー5本を変換し、突合結果をお渡しします。
まずは診断から
- 無料PoC：innovationalofficesolution.comAnyBI-To-PowerBI-and-AnyETL-To-Fabric/' target='_blank' rel='noopener noreferrer' class='text-teal-600 hover:underline font-medium'>無料PoC（Pulse Convert）
- Webサイト：innovationalofficesolution.com
- メール：Admin@innovationalofficesolution.com
無料PoC（概念実証）
Microsoft Solution Partner
Oracle から Microsoft Fabric への移行
基幹 DB はそのままに、分析・集計処理を Microsoft Fabric へ移す 4 段階ロードマップ。PL/SQL を Fabric Warehouse や PySpark へ初期自動変換精度 70%～90% で移行します。
初期自動変換精度 70%～90%代表的な PL/SQL 5 本で無料 PoCミラーリングを活用した本番負荷ゼロのデータ連携マイクロソフト認定 Data & AI ソリューションパートナー
提供：Office Solution AI Labs（マイクロソフト認定 Data & AI ソリューションパートナー）
#日本語#Oracle#Microsoft Fabric#PL/SQL#OneLake#ロードマップ#ケーススタディ
