本記事について
Oracle Database から Databricks を中心としたレイクハウスへ移行方法案を共有する。レイクハウスの拡張性を失うことなく、多機能な Oracle Database のコードを Azure SQL Database へ Microsoft 社提供のデータベース移行ツール（SQL Server Migration Assistant for Oracle）を用いてコードを最低限の労力で移行するという観点で、本方法論にはユニーク性がある。本記事では、データの取り込み、データの提供（クエリ実行）を Databricks へ移行し、Oracle Database のストアードプロシージャ等のプログラムを Azure SQL Database へ移行する方法となっている。
Microsoft 社提供のデータベース移行ツールである SQL Server Migration Assistant for Oracle（SSMA）については、次の記事で Oracle Database の機能別の検証を実施している。
概要
Oracle Database のデータ分析プログラムを、Databricks を中心としたレイクハウスへ移行する方法を提示する。
本方法論の目的を、次のように想定している。
- 移行に必要となるスキルセットを最小化すること
- 移行期間を短期間化すること
- 無謀な移行をさけること
データウェアハウスの移行を実施する際に次のような事象が散見され、いわゆる無謀な移行が実施されていることがある。たとえば、Excel 形式の設計書から移行後のプログラムを作成する際には、実際のプログラムと設計書の差分があることから、想定通りの移行作業が実施できない場合がある。
- Excel 形式の設計書から、移行後のプログラムを作成すること
- 移行後のサービスを先に選定しており、移行を考慮していないこと
- 移行後のプログラムに対するテストが適切に実施されないこと
- 移行後のパフォーマンス検証を実施していないこと
- 移行作業時の成果物を適切に管理していないこと
Oracle Database の移行方針
データウェアハウスとしての Oracle Database の特徴
データウェアハウスとして Oracle Database を利用する際の PL/SQL のプログラムには次のような特徴があり、最新のデータウェアハウスサービスに移行することが困難であることが多い。行単位により処理を行うプログラミングが、大量データの処理に最適化されたデータウェアハウスサービスでは性能上のボトルネックとなることもある。Oracle Database を長年にわたり利用されていることで開発されたプログラミング数が多く、移行に多大なコストがかかる場合もある。
- 行単位でのデータ処理が実施されていること
- カーソルなどを利用したロジックが実装されていること
- パッケージ利用による多機能なプログラムが存在すること
Oracle Database プログラムの移行方法
データの取り込み、データの提供（クエリ実行）を Databricks へ移行し、Oracle Database のストアードプロシージャ等のプログラムを Azure SQL Database へ移行する。Azure SQL Database へ移行を行う際には、Microsoft 社が提供している移行ツールである SQL Server Migration Assistant for Oracle(SSMA) を利用する。
- プロビジョニング済みとサーバーレスの切り替えが可能であり、コスト最適化の実施が可能であること
- SMP型DWHとして利用されている実績があるデータベースエンジンであること
- 移行化ツールが Microsoft 社から提供されており、ツール利用に関する Azure サポートを受けられること
Azure SQL Dataabse には、次のような強みもある。
- SQL Server Management Studio (SSMS) や Azure Data Studio などの Microsoft 社提供の開発ツールが利便性が高いこと *1
- データベースプロジェクト（DACPAC）によりメタデータ管理が容易であり、CI/CD によりデプロイが標準機能で実施できること。 *2
- データベースのバージョンを考慮する必要がなく、バージョンアップ等の運用業務が最小限であること。 *3
- Databricks (Spark)とのデータ連携時の性能を最大化ができる Spark コネクターが提供されていること。 *4
- 自動チューニング機能によるパフォーマンスの最適化が実施されること。 *5
*1 次のドキュメントにて紹介されている。
- Azure SQL Database に対する接続およびクエリ - Azure Data Studio | Microsoft Learn
- SSMS: データに接続してクエリを実行する - Azure SQL Database & SQL Managed Instance | Microsoft Learn
*2 次のドキュメントにて紹介されている。
- Azure SQL Database にデプロイする - Azure Pipelines | Microsoft Learn
- SQL Database プロジェクトの拡張機能 - Azure Data Studio | Microsoft Learn
*3 ドキュメントにて次のように記載されている。
Azure SQL Database は、アップグレード、修正プログラムの適用、バックアップ、監視などのほとんどのデータベース管理機能をユーザーの介入なしで処理する、フル マネージドの PaaS (サービスとしてのプラットフォーム) データベース エンジンです。
引用元：Azure SQL Database サービスとは - Azure SQL Database | Microsoft Learn
*4 Spark コネクターについては、次のドキュメントにて記載されている。
*5 ドキュメントにて次のように記載されている。
SQL Database では、次の 2 つの自動チューニングを使用できます。
- インデックスの自動管理:データベースに追加するインデックスと削除するインデックスを識別します。
- プランの自動修正:問題のあるプランを識別し、SQL プランのパフォーマンスに関する問題を修正します。
引用元：Azure SQL Database サービスとは - Azure SQL Database | Microsoft Learn
PL/SQL のプログラムにてロジックが少なく SELECT 文をベースにした処理である場合には、SQL Server Migration Assistant for Oracle(SSMA)の移行先としてサポートしている Azure Synapse Analytics 専用 SQL プールへの移行も検討の余地がある。ただし、Microsft 社のドキュメントにて次のような記載がある通り、行ごとの処理が多数ある場合には不向きである。
- 単一行挿入の量が多い。
- 行単位の処理が必要である。
引用元： Azure Synapse Analytics: 移行ガイド - Azure Synapse Analytics | Microsoft Learn
移行対象のオブジェクト
本方法論における移行対象の Oracle Database は、次のものである。
- Oracle database のスキーマオブジェクト
- PL/SQL 形式で記述されている SQL
- SQL*Loader
次のようなオブジェクトは、本方法論の対象外とする。
- Pro*C
- Java
移行先アーキテクチャと開発環境
次のサービスを用いたアーキテクチャに移行する。
- Databricks
- Azure Storage
- Azure SQL Database
- Azure Data Factory
次の手順により、データ取り込みとデータ処理を行う。Azure SQL Database を、Oracle Database のプログラムを実行することを想定している。Azure SQL Database では、並列処理の性能を高めるために、複数のデータベースに移行することが望ましい。
- Databricks にデータを取り込む
- Databricks から Azure SQL Database に対して処理に必要なデータを連携
- Azure SQL Database にて処理（ストアードプロシージャ等）を実行して、データを生成
- Azure SQL から Databricks にデータを連携
Azure へデータ移行を実施する際には、総データサイズ、および、ネットワーク帯域等から、次のいずれかの方法を実施する。
- Azcopy
- Azure Data Factory
- Azure Data Box ファミリ
データの移行方法を検討する際には、次の記事を参考に検討する。
開発を実施する際のコアテクノロジーとしては、次のものがある。
- 開発環境（Windows Subsystem for Linux、Docker、Conda）
- コードエディター（Visual Studio Code、Azure Data Studio、Visual Studio
- Database プロジェクト
- 移行ツール（SSMA プロジェクト）
- Git（Azure Repos）
- プロジェクト管理ツール（Azure Boards）
- CI/CD パイプライン（Azure Pipelines）
移行プロセス
移行プロセス概要
次のような移行プロセス群を実施する。プロセスごとに、複数のステップを想定している。
| # | プロセス | 概要 |
|---|---|---|
| 1 | 初期評価 | 移行対象のオブジェクトを整理する。 |
| 2 | 移行スコープ検討 | 移行スコープの検討する。 |
| 3 | 移行元プログラム修正 | 移行元オブジェクトに移行に必要となる修正を実施する。 |
| 4 | 移行先プログラムへの変換 | 移行先プログラムへの変換処理を実施する。 |
| 5 | 仕様変更への対応 | 移行時に要求された仕様変更を実施する。 |
| 6 | 最適化の実施 | 移行先プログラムへの最適化を実施する。 |
| 7 | リリースと移行後作業 | 移行先システムへの移行作業と移行後作業を実施する。 |
1. 初期評価
基本的な手順
次のステップを実施する。
- 移行元システム関連資料の収集
- 移行元システムから情報の抽出
- SSMA による変換処理の実行
- 移行オブジェクトの整理
- 移行に伴う仕様変更方針の検討
- 移行プログラムの PoC（Proof Of Concept）の実施
- 成果物の管理
次のオブジェクトをレポジトリーにて保持する。
- オブジェクトのコードー
- SSMA プロジェクト
- データベースプロジェクト
次のオブジェクトについては、レポジトリーに保持する必要はないが、プロジェクトとして管理すべき成果物である。
- Database Migration Assessment 評価レポート
- 設計書
- オブジェクトステータス
- パフォーマンスログ
- Oracle Database 以外の移行元プログラム
1. 移行元システム関連資料の収集
移行元システムにおける次の資材を収集する。
- システムアーキテクチャ図
- 開発方針書（処理パターンを把握できる資料）
- システム設計書
- 運用設計書
- 移行元プログラム
- テストケースとテストデータ
次のようなシステム開発運用に関する利害関係者を特定する。
- 移行元システムの所有者
- 移行データの承認者
- 移行元システムのアプリケーション開発者
- 移行元システムの保守運用者
- 移行後システムの運用者
- 移行後システムのインタフェース実施者
次の資材の提供依頼を実施する。
- Oracle Database の過去のバージョンのインストールイメージ *1
- システム運用で利用しているテーブル（エラー一覧マスターなど）の一覧とそのデータ
*1 2023年4月1日時点では、Oracle Database 12c のイメージを、Oracle のサイトよりダウンロードできない。
データの移行に関して、次の調査を実施する。
- PoC 用データ受領方法
- 移行検証用データ受領方法
- データ移行用データ受領方法
- データセキュリティ要件（テストデータのマスキング等）の確認
オーケストレーションの移行に関して、次の調査を実施する。
- プロセスの一覧化
- プロセス間の依存関係の整理
- パラメーターの一覧化
- データ処理の要件（要求実行時間等）に関する方針書の受領
- 実行履歴
2. 移行元システムから情報の抽出
Oracle Database に対して、次の作業を実施する。
- SSMA にて、プロジェクトに Oracle Database メタデータのインポート
- Database Migration Assessment 評価レポートの生成
- Oracle Dataabase における NLS_LANG パラメーターの整理
- Oracle Database オブジェクト抽出クエリの実行
- Oracle Database オブジェクトのステータス（
VALIDorINVALID）の一覧 - Oracle Database の処理オブジェクトにて INPUT テーブルと OUTPUT テーブルの整理
- テーブルサイズに関する情報の抽出
3. SSMA による変換処理の実施
SSMA にて、移行先のデータベースへの変換とレポート作成を実施する。次ののエラーが発生した場合には、移行元コードの修正を行ったうえで変換を実施する。変換を実施した場合には、移行元コードに変換した旨のコメントを記載することが望ましい。
オブジェクトがINVALIDの状況のコードについては、移行対象外とすることを検討する。
オブジェクト不足の SSMA issues 発生した場合には、不足しているオブジェクトについては、提供依頼を実施する。
データベースリンクが利用されているため、データの実体化等の対応が必要となるため、データ連携対象への追加を検討した上でオブジェクトの提供依頼を実施する。
4. 移行オブジェクトの整理
ステップ概要
次の作業を実施する。
- コードのパターン化
- SSMA issues の整理
- SSMA の変換がサポートされていない機能の利用状況の調査
- 移行方針の検討
- 共通処理の実装
- Azure SQL Database の実装方針
- Databricks における共通処理の設計・開発・テスト
コードのパターン化
移行元コードから、開発パターンを整理する。
SSMA issues の整理
SSMA にて発生した SSMA issues (ErrorとWarning)の一覧化を実施する。
移行元コードに基づき次のステップを実施することで、移行先データベースに応じた対処方法を整理する。1つの SSMA issues には複数の要因により発生するため、実際のコードに基づき SSMA issues を再現するためのコードを作成して、対応方法を整理する。最終的な対処方法を確定することは困難であるため、移行先プログラムへの変換を完了するまで継続的な見直しを実施することが望ましい。
- 移行元コードからケースの特定
- 再現するコードを作成
- 移行先データベースに応じた対処方法の検討
SSMA issues を調査する際には、次のリンクが参考となる。
- SSMA issues に関する Microsoft 社ドキュメント
- DataMigrationTeam/SSMA issues and workarounds when migrating Oracle database.pdf at master · microsoft/DataMigrationTeam (github.com)
- SSMA for Oracle common errors and how to fix it.pdf
- SSMA Archives | ABCloudz
SSMA issues の整理記事のベースとして次の記事を投稿している。
SSMA の変換がサポートされていない機能の利用状況の調査
SSMA により変換がされていない機能の利用有無の調査を行い、対応方針を検討する。SSMA が変換をサポートしていない代表的な機能には次のものがある。
- マテリアライズド・ビュー
- データベースリンク
- UTL_FILE パッケージ
移行方針の検討
次のような移行方針を検討する。移行元検証環境にて実データを実施することが望ましいため、顧客管理下の環境で実施する。移行元検証環境を顧客側で実施できない場合には、実行する環境を検討する必要がある。
- 設計書の作成方針
- テスト実施方針
- 移行先アーキテクチャ方針
- 移行元検証環境の方針
- 開発環境の方針
- SSMA プロジェクトの設定方針
- コードのフォーマット方針
共通処理の実装
次のような共通処理を実装する。
- ワークフロー（Azure Data Factory）のテンプレート設計・開発・テスト
Azure SQL Database の実装方針
Azure SQL Database における次のような実装方針を検討する。
- 照合順序
- テーブルの圧縮の実施有無
- 自動チューニングの設定有無
Databricks における共通処理の設計・開発・テスト
Databricks における共通処理の設計・開発・テストを実施する。
- インタフェースファイルの取り込み
- データ品質チェック
- Azure SQL Database へのデータ連携
- Azure SQL Database からデータ抽出
- データレイクの構成
Azure Data Factory における共通処理の設計・開発・テスト
Azure Data Factory における共通処理の設計・開発・テストを実施する。
5. 移行に伴う変更対応方針の検討
移行に伴い、必要となる変更対応の方針を検討する。変更対応には次のようなものがある。
| # | 変更対応 | 作業を実施するプロセス |
|---|---|---|
| 1 | エラーオブジェクトの除外 | 2.移行スコープ検討 |
| 2 | 機能の廃止 | 2.移行スコープ検討 |
| 3 | 移行先データベース仕様への対応に伴う機能追加 | 4.移行プログラムへの変換 |
| 4 | 移行先データベース仕様への対応に伴わない機能追加 | 5.仕様変更への対応 |
| 5 | 最適化の実施 | 6.最適化の実施 |
6. 移行プログラムの PoC（Proof Of Concept）の実施
コードのパターンから、代表的なパターンに基づき、PoC を実施する。PoC の実施結果に基づき、方針の修正を行う。
7. 成果物の管理
移行方針の最終化の実施後、本プロセスの成果物を整理して、レポジトリー等での管理を実施する。プログラムに対しては、フォーマットを適用する。
2. 移行スコープ検討
基本的な手順
次のステップを実施する。
- 依存関係の整理
- 移行対象のセグメント化と移行スコープの検討
- 移行スコープ別成果物の作成
- 移行元検証環境、および、移行先検証環境の確認
- 成果物の管理
1. 依存関係の整理
次の手順を実施する。
- 依存関係の把握
- 不足オブジェクトの取得
- 依存関係の整理
2. 移行対象のセグメント化と移行スコープの検討
次の手順を実施する。
- 移行対象外オブジェクトの決定
- 処理対象期間とデータ保持期間方針の検討
3. 移行スコープ別成果物の作成
次の手順を実施する。移行作業は SSMA issues をベースに検討するが、追加で実施すべき作業の有無の確認が必要である。
- スコープ別移行方針の検討
- 移行対象 Oracle Database オブジェクトの整理
- SSMA プロジェクトの作成と変換
- 移行作業の整理
- データベースプロジェクトの出力
4. 移行元検証環境、および、移行先検証環境の確認
スコープ別に利用する移行元検証環境、および、移行先検証環境の確認を行う。環境が存在しない場合には、構築を行う。
5. 成果物の管理
本プロセスの成果物を整理して、レポジトリー等での管理を実施する。プログラムに対しては、フォーマットを適用する。
3. 移行元プログラム修正
基本的な手順
次のステップを実施する。
- 移行スコープの確認
- 移行元プログラムの修正
- 移行元プログラムのテスト作成
- 修正済み移行元プログラムのテスト実施
- 移行スコープでの PoC
- 移行先プログラムの修正
- 成果物の管理
1. 移行スコープの確認
次の手順を実施する。
- 移行対象のオブジェクトの確認
- テスト対象のプログラムの特定
- 移行元検証環境の確認
2. 移行元プログラムの修正
Oracle Database のプログラムの修正を実施する。このステップでは移行のための修正の実施を行い、仕様変更のための修正を実施することを想定していない。
3. 移行元プログラムのテスト作成
修正前の移行プログラムにて、テスト対象のプログラムごとにインプットデータを特定し、そのデータでプログラムでの処理を実施する。処理の完了後、インプットデータとアウトプットデータをテストデータとして管理する。
4. 修正済み移行元プログラムのテスト実施
修正実施済みプログラムに対して、修正前と同等であること、あるいは、追加機能の実装が想定通りに行えていることを確認する。
6. 移行先プログラムの修正
次の手順を実施する。
- 移行スコープでの SSMA プロジェクトを作成
- 修正済み移行元プログラムを SSMA プロジェクトに取り込む
- SSMA プロジェクトにおける変換処理
- SSMA からデータベースプロジェクトを出力 *1
- データベースプロジェクトにおけるコードのフォーマット
7. 成果物の管理
本プロセスの成果物を整理して、レポジトリー等での管理を実施する。プログラムに対しては、フォーマットを適用する。
4. 移行先プログラムへの変換
基本的な手順
次のステップを実施する。
- 移行先検証用環境の確認
- 移行先プログラムへの修正項目の整理
- 移行先プログラムの開発
- 移行スコープでの PoC
- 移行先プログラムのテストの実施
- ワークフロー実行による動作検証の実施
- 成果物の管理
1. 移行先検証用環境の確認
移行先検証用環境の確認を実施する。存在しない場合には、環境構築を実施する。
2. 移行先プログラムへの作業項目の整理
移行先プログラムへの作業項目の整理する。タスクを、多数のプログラムに対して一括で実施するものと各プログラムに対して実施するものに分けることが望ましい。
SSMA により変換するプログラムでは、SSMA issues を参考に作業の確認を実施する。実装スコープにて追加開発が必要となる Databricksの作業項目、および、Azure Data Factory の作業項目を整理する。
3. 移行先プログラムの開発
移行先プログラムの開発を実施する。
Azure SQL Database へ移行するプログラムは、SSMA により出力したデータベースプロジェクトに対して開発作業を行う。
Databricks 、および、Azure Data Factory へ移行するプログラムは、それぞれの環境でプログラムを開発作業を行う。
4. 移行スコープでの PoC
必要な場合には、移行スコープでの PoC を実施する。
5. 移行先プログラムのテストの実施
修正済み移行先プログラムに対して、前のプロセスで実施したテストを実行する。
6. ワークフロー実行による動作検証の実施
ワークフロー（Azure Data Factory）から、想定通りに実行できることを確認する。
7. 成果物の管理
本プロセスの成果物を整理して、レポジトリー等での管理を実施する。プログラムに対しては、フォーマットを適用する。
5. 仕様変更
基本的な手順
次のステップを実施する。
- 仕様変更への対応に伴う移行先プログラムの修正
- テストケースとテストデータの作成
- テストの実施
- 成果物の管理
1. 仕様変更への対応に伴う移行先プログラムの修正
移行先データベース仕様への対応に伴わない機能追加への対応を行う。
2. テストケースとテストデータの作成
仕様変更への対応に伴う修正を実施したプログラムにて、テストケースの特定を行い、テストデータ（インプットデータ、および、アウトプットデータ）の作成を行う。
3. テストの実施
仕様変更に関連するプログラムに対して、テストを実施する。
4. 成果物の管理
本プロセスの成果物を整理して、レポジトリー等での管理を実施する。プログラムに対しては、フォーマットを適用する。
6. 最適化の実施
基本的な手順
次のステップを実施する。
- 最適化対象の特定
- テストの実施
- 性能検証の実施
- 移行先システムのサイジングの実施
- 成果物の管理
1. 最適化対象の特定
最適化対象オブジェクトを特定し、最適化を実施する。
2. テストの実施
最適化を実施後のプログラムに対して、前のプロセスで実施したテストを実行する。
3. 性能検証の実施
本番環境のデータに基づき、移行先システムにて性能検証を実施する。
4. 移行先システムのサイジングの実施
移行先データベースのサイジングを実施する。
Azure SQL Database では、プロビジョニング済み <-> サーバーレス間の変更を SQL 等で簡単に実施できるため、継続的に特定のコア数で処理されることが判明している場合には変更の実施を検討する。サーバーレスでは、リソース確保が安定しない場合があるため、データ処理許容時間が短い場合にはプロビジョニング済みを選択することが望ましい。
5. 成果物の管理
本プロセスの成果物を整理して、レポジトリー等での管理を実施する。プログラムに対しては、フォーマットを適用する。
7. リリースと移行後作業
基本的な手順
次のステップを実施する。
- 移行先データベースのデータベースプロジェクトに統合
- 移行先データベースに対するテストを実行
- レポジトリーに反映
- 移行リハーサルの実施
- 本場移行の実施
- 移行後作業の実施
- 成果物の管理
1. 移行先データベースのデータベースプロジェクトに統合
リリース対象のデータベースに合わせたデータベースプロジェクトに統合する。
2. 移行先データベースに対するテストを実行
必要に応じて、統合先のデータベースプロジェクトに対するテストを実行する。
3. レポジトリーに反映
レポジトリーへ成果物を反映する。
4. 移行リハーサルの実施
実環境に基づき、移行リハーサルを実施する。
5. 本場移行の実施
実環境に基づき本場移行を実施する。
6. 移行後作業の実施
実環境に基づき本場移行を実施する。
7. 成果物の管理
最終資材を整理して、レポジトリー等での管理を実施する。