【OCI】BaseDBでDataPumpを利用する際のストレージ・サービス比較

BaseDBでData Pumpを利用する際（データ移行、バックアップ等）、避けて通れない問題がローカルディスクの容量不足です。

不要ファイルの削除等で容量不足が解決しない場合、外部ストレージの活用が選択肢となります。しかし、OCIには複数のストレージ・サービスが存在するため、どのストレージが最適か判断に迷うケースは少なくありません。マウント方法やコスト・速度のバランスなど、考慮すべき点が多いからです。

そこで本記事では、BaseDBでのData Pump入出力先としてOCIが提供する3つのストレージ・サービスを4つの視点（コスト・速度・構築難易度・運用負荷）から比較検討し、それぞれのサービス特徴と使用が推奨されるケースを解説します 。

今回の比較検証は、以下の前提条件で行います。

比較対象とするのは以下の3つのストレージ・サービスです 。

各ストレージ・サービスの詳細は以下弊社ブログをご確認ください。

比較する各ストレージのスペックは以下です。
費用はOCIの費用計算ツールCloud Cost Estimatorを使用しています。
（2025年12月18日地点）

【注意】
本記事では便宜上、「ネットワーク帯域（Gbps）」と「ディスクのスループット性能（MB/s）」を単位換算して比較していますが、厳密には同一の指標ではなく、単純に比較できるものではない点にご注意ください。また、Datapump実行から終了までの時間はスペックのみで比較出来ず、環境に依存するため、本記事はあくまで参考値として捉え、必ず実環境で検証してください。

以下では、それぞれのストレージ・サービスを使用した際の特徴 ／手順を確認していきます。

DBMS_CLOUDパッケージを利用し、オブジェクト・ストレージへ直接読み書きを行う方法です。

コストと速度の両面で優れており、初期構築作業やDBバージョンの制約さえクリアできれば、第一選択肢になりえます。

最大の魅力はコストパフォーマンスと速度です。

コスト
1TB使用した場合で約4,000円と非常に安価です 。
また、使用量に対しての課金であるため、データが存在しない場合はコストを抑えられます。

速度
プライベートエンドポイント経由の場合、標準設定で、最大約3.1GB/sという高速なスループットが期待できます 。

運用負荷
マネージド・サービスであるため、起動状態の監視やセキュリティアップデート等の管理はOCI側に任せられます。必要に応じて、ファイルのバックアップも可能です。（追加必要がかかります。）

導入手順が複雑である点がデメリットです。
後述いたしますが、オラクルのトレーニング資料では、DBMS_CLOUDパッケージのインストールのみで目安時間が約1時間30分となっており、十分な作業時間の確保が必要です。

バージョン制約
Data Pumpのデータを直接オブジェクト・ストレージに入出力するには、BaseDB 21.3以上である必要があります。

【注意点】
DBMS_CLOUD パッケージ自体は BaseDB 19.9以上から利用可能なため、「19cでもData Pumpを利用したオブジェクト・ストレージとの連携ができる」と誤解されがちです 。しかし、19cでサポートされているのはDBMS_CLOUDを使用したファイル転送（PUT_OBJECT等）のみで、Data Pumpを使用したダイレクト転送はサポートされていません 。

BaseDB 19cにてDBMS_CLOUDを使用してData Pumpを使用した場合、以下オラクル社資料の通り、エラーが発生しexpdp／impdpが失敗するので注意が必要です。

EXPDP fails with ORA-39208: Parameter KU$_FILE_TYPE_URIDUMP_FILE Is Invalid For EXPDP using OCI オブジェクト・ストレージ.
https://support.oracle.com/support/?anchorId=&kmContentId=3048725&page=sptemplate&sptemplate=km-article
※リンク先閲覧には My Oracle Support のアカウントが必要です。

構築の手間
DBMS_CLOUDを使用するには、DBMS_CLOUDパッケージインストールに始まり、Walletの作成、ACEs（Access Control Entries）の作成、ユーザへの権限付与、クレデンシャルの作成等様々な作業が必要です。そのため、今回比較する他サービスと比べ、構築が煩雑で難航する可能性があります。

多くの方にご使用いただけるよう、汎用的な構築手順を紹介いたします。

1.オブジェクト・ストレージの作成
　以下のオラクル社資料を参考にして、オブジェクト・ストレージの作成を行います。資料内の「2.コンソール画面の確認とバケットの作成」を参考にオブジェクト・ストレージを作成してください。

2.DBMS_CLOUDのインストール
　以下オラクル社トレーニング資料を参考にDBMS_CLOUDをインストールします。作成後は、問題なくBaseDBのデータがオブジェクト・ストレージに転送可能か確認を行います。

3.Data Pumpによるダイレクトインポート設定を行う
　最後の手順です。Data Pump使用時に直接オブジェクト・ストレージに転送を行えるようクレデンシャルの設定を行います。設定終了後、Data Pumpの動作確認を行います。

*Autonomous Databaseと記載がありますが、BaseDBでも同様の手順にて設定可能です。impdpの方法をご紹介していますが、expdpも問題なく使用可能です。

【注意点】
BaseDBでData Pumpを使用する場合、上記手順に加え、オブジェクト・ストアODMライブラリを別途有効化する必要があります。3の手順を実施する際は、impdpを行う前に以下の設定も行ってください。

DATA PUMP EXPORT TO OCI オブジェクト・ストレージ FAILED ORA-39001 ORA-39000 ORA-31641
https://support.oracle.com/support/?anchorId=&kmContentId=2806178&page=sptemplate&sptemplate=km-article
※リンク先閲覧には My Oracle Support のアカウントが必要です。

ファイル・ストレージをNFSを利用してBaseDBへマウントする方法です。
構築難易度が低く運用負荷も軽減できるため、最適な選択肢と言えます。ただし、費用が高額なため、運用コストを試算した上でご検討いただくことをおすすめします。

最大の魅力は安全性と手軽さです。

運用負荷
マネージド・サービスであるため、起動状態の監視やセキュリティアップデート等の管理はOCI側に任せられます。
必要に応じて、別途費用がかかりますが、スナップショットの取得やレプリケーション等、データのバックアップも可能です。

構築の手間
ファイル・ストレージ（以後、FSS）構築後は必要に応じてネットワーク設定とNFSマウントをおこなうだけでアタッチ可能なため、今回ご紹介する3サービスの中では、最も構築難易度が低いと言えます。

コストと帯域制限がネックとなります。

コスト
1TB使用した場合、Standard構成で1か月あたりの費用が約47,616円と今回比較するストレージの中では最も高額です 。
しかし、使用量に対しての課金であるため、データが存在しない場合はコストを抑えられます。

速度
Standard構成の場合、約125MB/sと他サービスに比べると低速です。
速度を上げる場合、次の選択肢としてHPMT-20構成が挙げられますが、速度が2.5GB/sとなる代わりに容量20TB以上、月単位の課金という制限が適用されるため、最低でも1か月あたりの費用が92万円となります。（既存ユーザは半額程度に安くなる特例措置あり）

【速度の注意点】
2024年8月に仕様改定があり、標準設定（Standard構成）では速度が約125MB/s (1Gbps)に制限されることが決定しました。（それまではデフォルトで600MB/s～1GB/sの速度が出ていました。）2025年12月10日時点ではまだ制限が適用されていませんが、いずれ適用されるため、コストと費用面の費用対効果を考える方にはお勧めしづらい構成となってきています。
参考：OCI技術資料 : ファイル・ストレージ 概要

FSSの作成からData Pump（impdp）実行までの作業手順を 流れが画像付きで記載しています。以下URLよりブログ手順をご確認下さい。

コンピュート・インスタンスを構築し、ブロック・ボリュームをアタッチしてNFSサーバー化する方法です。
FSSと同等の性能を低価格で実現できるためコストを重視する場合、選択肢となりえます。
ただし、NFSサーバー自体の管理と保守（パッチ適用や起動状態の死活監視等）は利用者側で行う必要があるため注意が必要です。

コストの安さとオブジェクト・ストレージ（DBMS_CLOUD）と比べ簡単な構築手順が魅力です。

コスト
1TBを使用する場合、1か月間インスタンスを常時起動し、速度240MB/sを確保したとしても月約1.2万円程度で運用可能です。
また、仮に速度を480MB/s確保したとしても約2万/月で運用可能であるため、状況に応じて、速度とコストを変更することが可能です。
ただし、使用したデータ量に対しての課金ではなく、構築したディスクサイズに対して費用がかかる点は注意が必要です。

速度
FSSと比べ、金額に対して速度パフォーマンスが良いことに加え、柔軟に速度調節を行えることが魅力です。
大まかに考えると速度は以下の計算式で決定されます。ディスク側のスループットに加え、インスタンス側の速度（帯域）も確保が必要な点は注意が必要です。

・インスタンス側の速度: 1OCPUあたり約125MB/s
・ディスク側の速度: パフォーマンスレベル（VPU）あたりの速度（1GBあたり） × ディスクサイズ（GB）
※どちらも構成により速度の最大値が存在します。

構築の手間
コンピュート・インスタンス作成後、ブロックボリュームをコンピュート・インスタンスにアタッチし、NFSサーバー化します。その後、BaseDBへNFSマウントを行う流れになります。FSSより構築難易度は上がりますが、オブジェクト・ストレージ（DBMS_CLOUD）と比較すると構築は簡単です。

NFSサーバーとして利用するコンピュート・インスタンスのマシン管理を利用者側で行う必要がある点がデメリットです。

運用負荷
アンマネージド・サービスであるため、マシン起動状態の監視や、メンテナンス作業（OSパッチ／セキュリティパッチ等の適用）などは、利用者側で対応する必要があります。
また、インスタンスに障害が発生した場合等の対応も利用者側で行う必要があるため、コストを抑えられる反面、インスタンスを問題なく管理できる運用スキルが必要です。

以下に構築方法をご紹介します。

1.コンピュート・インスタンスの作成
　以下手順に従い、コンピュート・インスタンスを作成します。

2.ブロックボリュームのアタッチ
　作成したコンピュート・インスタンスに対して、ブロックボリュームをアタッチします。
　以下、オラクル社の手順を参考に、ブロックボリュームの構築とアタッチを行ってください。

3.NFSマウント
　以下弊社ブログの「3.BaseDBにFSSをマウント」を参考にNFSをBaseDBにマウントします。手順ではFSSと記載がございますが、ブロック・ボリュームも同手順にてアタッチ可能です。

今回は、BaseDBに使用可能な3つのストレージ・サービスを、4つの観点（コスト速度／運用負荷／構築難易度）の観点から比較検討しました。

各サービスのまとめは以下です。

各ストレージ・サービスのポイントは以下です。

オブジェクト・ストレージ （DBMS_CLOUD）
DBバージョン要件（21.3以上）を満たしており、構築の手間を許容できる場合、低コストであり速度も高速であるためおすすめです。

ファイル・ストレージ （NFS）
コストよりも構築の容易性や運用負荷の低減を重視したい場合、おすすめです。ただし、将来的に速度が約125MB/sに制限される点は注意が必要です。

ブロック・ボリューム（NFS）
FSSよりコストを抑え、速度を確保したい場合におすすめです。ただし、NFSサーバ自体の管理と保守（パッチ適用や起動状態の死活監視等）は利用者側で行う必要があるため注意が必要です。

BaseDBのローカルディスク容量不足は、運用担当者を悩ませる切実な課題です。しかし、今回ご紹介した3つの選択肢を適切に使い分けることで、コストの呪縛やパフォーマンスの不安から解放され、ご意向にそった運用が期待できます。

本記事が、BaseDBにて外部ストレージを作成する場合の一助となれば幸いです。