初めに
オブジェクト・ストレージから、Oracle DB 或いは Autonomous DB へデータをロードするのに、いろいろな手段がありますけど、よく使われている方法を取りまとめ、紹介したいと思います。
いつ何を使うか迷っている方は、もしこの記事を見て適切な方法ができたら幸いです。
OCIオブジェクト・ストレージを例に紹介しますが、利用方法によりほかのデータ・ソース（AWS S3, Azure Blob など）にも対応します。
なお、今回はオラクルのオフィシャル製品とサービスを中心に紹介します。下記方法以外、ほかのサードパーティー・ツールをありますけど、選択肢が多くて割愛させてください。
目次
1. オブジェクト・ストレージから、データを Oracle DB/ADB にロード
1-1. ローカルにコピーしてから、Oracle DBへ
ネットワーク構成について
- Oracle DBインスタンスが、パブリック/プライベート・サブネットのどちらに存在してもこの方法が適用する。（下記他方法も同様）
- パブリック・サブネット：Internet GWを経由しオブジェクト・ストレージへアクセスする。
- プライベート・サブネット：NAT GWか、Service GWを経由する。
- Oracle DBがプライベート・サブネットに格納されるのは一般的であり、Service GWを経由し、OCI オブジェクト・ストーレジにアクセスのは、推奨です。
作業ステップ
- STEP-1. データをローカルに転送。
- OCI Object Storageからの場合：OCI CLIの利用を推奨 (最新版のOracle Base DBに実装済、前のバージョンのDBインスタンスにもインストール可能)
- AWS S3, Azure Blobからの場合：例 rcloneを利用
- STEP-2. ローカルからDBへロード （従来通りのやり方）
- 2-1) テキストファイル：例 SQL Loader
- 2-2) DUMPファイル：impdp
メリット
✅ ローカルにコピーした後、従来通りのやり方と同じで、他ツール・サービスを利用しなくてもよい。
✅ DBMS_CLOUDと比べて、Oracle DB のバージョン制限がない。
✅ OCI CLIはOracle Base DBに実装済で、データ転送は便利。
デメリット
- ローカルへの一時保存は必要で、Block Volumeの容量が少ない時、収まらない可能性がある。
1-2. オブジェクト・ストレージをローカルにマウントし、Oracle DBへ
作業ステップ
- STEP-1: オブジェクト・ストレージをDBインスタンスにマウントする （例：s3fs-fuseを利用）
- STEP-2: マウントポイントからデータDBへロード（従来通りのやり方）
- 2-1) テキストファイル：例 SQL Loader
- 2-2) DUMPファイル：impdp
メリット
✅ マウントの設定は、比較的に簡単。マウント後、従来通りのやり方と同じ。
✅ DBMS_CLOUDと比べて、Oracle DB のバージョン制限がない。
✅ ローカルへの一時保存は不要で、容量不足の問題を解消できる。
注意点
DBインスタンス再起動後、マウント・ポイントが切れないように再マウントするか/etc/fstabを編集してください。
1-3. DBMS_CLOUD プロシージャの利用
Oracle DB の場合
作業ステップ
- STEP-1. Oracle DBに、DBMS_CLOUDプロシージャをインストールし、関連設定を実施。
- STEP-2. クレデンシャルの作成 ( DBMS_CLOUD.CREATE_CREDENTIAL )
- STEP-3. データロード
- 3-1) テキストファイル： DBMS_CLOUD.COPY_DATAを利用
- 3-2) DUMPファイル：
impdp User/Password credential=XXXX dumpfile= https://<Object_File_URL>
Oracle DBの実施例は、次のステップ・バイ・ステップの手順を提供していますので、ご参考ください。（下記記事のSTEP-1からSTEP-8までは、DBMS_CLOUDのインストールと関連設定の作業に当たる。）
Autonomous DB の場合
DBMS_CLOUDプロシージャは、ADBに既に実装済で、クレデンシャルの作成から実施すればOKです。
メリット
✅ DBMS_CLOUDでクレデンシャルを作成したら、直接にオブジェクト・ストレージにアクセスできる。（ローカルへの一時保存もマウントも不要）
✅ この方法は、Oracle DB と Autonomous DB 両方に適用。
✅ OCI Object Storage以外、AWS S3, Azure Blob などのデータ・ソースも対応。マルチクラウドのユーザに向く。
デメリット
- Oracle DB の場合、DBMS_ClOUDのインストールと権限まわりの設定は必要、手順はやや複雑。
- Oracle DB のバージョン制限がある (19c, 21c のみ)。
1-4. DBMS_CLOUD_PIPELINE プロシージャを利用し、ADBへ
これは、2022年12月にリリースされたAutonomous DB の新機能です。機能の詳細は、ドキュメントをご参照ください。
作業流れ
メリット
✅ 指定間隔で実行し、新しいデータが来たら、直ぐにソースとターゲット間の連携は可能。
✅ オブジェクト・ストレージからADBへのロードだけではなく、ADBからオブジェクト・ストレージへのエクスポートも可能。
✅ OCI Object Storage以外、AWS S3, Azure Blob などのデータ・ソースも対応。マルチクラウドのユーザに向く。
利用制限
- 現在(2023年1月)、ADB特有な機能で、Oracle DBを対応していない。
1-5. ODI Marketplace の利用
ネットワーク構成について
- ODI MPインスタンスを作成する時、必ずVCNの指定は必要。ターゲットDBと同じVCNにするか、別々のVCNにするかどちらでもOK。
- ODI MPは、Autonomous LinuxベースのComputeインスタンスで、クライアント側からVNCツールで接続すれば、GUIが利用できる。
作業ステップ
- STEP-1. Marketplaceから、ODI インスタンスを立てる
- STEP-2. VNCツールでOCI MPに接続し、ODI Studioを起動
- STEP-3. レポジトリDBの作成 (ターゲットDBと同じでもよい)
- STEP-4. ソースとターゲットへの物理接続を立てる
- STEP-5. モデルの作成 (物理接続を論理化に)
- STEP-6. プロジェクトとマッピングの作成
- STEP-7. マッピング実行及びモニタリング
メリット
✅ OCIオブジェクト・ストレージ、Oracle DB/ADBだけではなく、たくさんの種類のデータ・ソースを対応している。
✅ データ編集、複数ファイルのマージなど、複雑なデータフローを作成できる。
✅ スケジューリング実行は可能、管理・監視の機能は豊富。
✅ コスト面のメリットがある。( Classic版は、無料で使える。Software price per OCPU $0.00 )
デメリット
- レポジトリDBの設定は必須である。
- マッピングが実施できるまでの設定は複雑。（初心者がなれるまでの時間を考慮しないと）
1-6. OCI Data Integration の利用
ネットワーク構成について
- OCI DIのワークスペースは、VCN内部か外部の2種類があり、デフォルトはVCN内部で作成する。
- VCN内部で作成する場合、オブジェクト・ストレージとDBインスタンスに接続するため、関連セキュリティ・リスト及びルート表の設定は必要である。
Egress ルールの参考例：
Object Storage 接続用： 宛先 0.0.0.0/0 TCP 443
DB 接続用： 宛先 DBのプライベートIP TCP 1521
作業ステップ
- STEP-1. OCI DI のワークスペースの作成
- STEP-2. データ・アセットの作成 （ソースとターゲット両方）
- STEP-3. プロジェクトとデータフローの作成
- STEP-4. 統合タスクとアプリケーションの作成
- STEP-5. アプリケーションへのタスクの公開
- STEP-6. タスク実行およびモニタリング
※、OCI DI ワークスペースは、機能的に ODI Studio (On-P or MP) と相当します。
Oracle DBの実施例は、次のステップ・バイ・ステップの手順をご参考ください。
メリット
✅ OCI マネージド サービスで、従来のODI On-P、ODI Marketplaceと比べて、使いやすくなる。（レポジトリDBの管理は不要）
✅ OCIオブジェクト・ストレージ、Oracle DB/ADBだけではなく、たくさんの種類のデータ・ソースを対応している。（対応一覧は、こちらへ）
✅ データ編集、複数ファイルのマージなど、複雑なデータフローを作成できる。
✅ スケジューリング実行は可能、管理・監視の機能は豊富。
✅ OCI DIからOCI Functionsの呼び出しも可能。
デメリット
- 他方法と比べて、サービス料金がかかる。(内訳は以下の通り)
- ワークスペース料金 (時間単位)
- データ処理料金 (時間×GB単位)
- パイプライン・オペレーターの実行料金 (時間単位)
パイプライン・オペレーターの部分はオプションです。それが発生しない前提で、毎月の概算見積もりは、次のようです。（１個ワークスペースのみ、１時間あたり１GBのデータを処理すると想定）
2. 各種方法の比較
上記各種方法のメリットとデメリットを抜粋して、一覧表を作りましたので、ご参考ください。
サマリー
- 各方法は、それぞれの適用場面と制限があります。ユーザケースにより、いつ何を使うのかを判断するのは重要です。データ転送量、転送頻度(一時か定期か)、データ編集要否、データ・ソースのタイプと場所、DBバージョン、コスト面（製品・サービス価格、学習時間）など、重要の考慮項目です。
- ODI On-P版も技術的に実現可能ですが、今回のケース（ソースとターゲット両方はクラウド上）にはベスト・プラクティスではないので、候補案から外します。
以上です。
関連記事
オラクル・クラウド関連の個人ブログ
オブジェクト・ストレージからOracle DB 19c/21cにデータを導入する
マウント・ポイントを経由して、データ・ポンプ・ファイルをOracle DBCSからオブジェクト・ストレージにエクスポートする
OCI Data Integrationを利用し、オブジェクト・ストレージからOracle DBにデータをロードする
ODI On-PとODI MarketplaceとOCI Data Integrationの比較
オフィシャル・リンク
OCI Data Integration サービス・ホームページ (価格表、見積もりを含める)
OCI Data Integration ドキュメント・ホームページ