2025年8月29日

【Google Cloud】第3回:Oracle Database@Google Cloudを利用してみよう~Data Pump移行編~


Content
こんにちは。Google Cloud研究開発チームです。 今回の内容は、

「Oracle Database@Google Cloud」

を利用して、既存のOracleデータベースを実際にData Pumpで移行してみよう!!という検証です。 前回のOracle Database@Google Cloudサービスについての記事も是非、読んでみてください。

今回実施する内容

実施内容

既存OracleデータベースをOracle Database@Google Cloud 上に構築したAutonomous Databaseに移行します。 今回はデータベースの移行ツールとして、Data Pumpを利用します。 実際にかかった移行時間なども最後に掲載しています。

前提

  • 移行元データベースとしてGoogle Compute Engine(以降GCE)上にOracleデータベースを構築
    • データベースは以下で作成
      • テーブル::IKOU,IKOU_ST
      • スキーマ::HR
      • 表領域::TEST
      • Oracleバージョン::19c
  • 移行先は前回検証で作成したAutonomous Databaseを利用
    • バージョン::23ai
    • (前回検証でAutonomous Databaseへの接続設定は実施済み)
  • Data Pumpのダンプファイル(DMP)の一時保管場所としてGoogle Cloud Storage(以降GCS)を利用

イメージ

まず、DataPumpとは何か

Data Pump は、Oracle Database が提供する論理バックアップおよびデータ移行用のユーティリティです。データベース全体、特定のスキーマ、テーブル単位など、柔軟な粒度でエクスポート/インポートが可能です。 操作には以下のコマンドラインツールを使用します:

  • expdp:データのエクスポート(Export Data Pump)

  • impdp:データのインポート(Import Data Pump)

エクスポートしたデータは、ダンプファイル(.dmp) として出力され、必要に応じて他の環境に取り込むことができます。 特に、Oracle Database のサーバリプレースやバージョンアップに伴うデータ移行時に、信頼性と効率性に優れたツールとして広く活用されています。

想定されるData Pump移行ケース

Data Pumpを利用した移行は、以下のような状況で特に有効です。

1. システム停止(ダウンタイム)を計画的に確保できる場合

Data Pumpはデータのエクスポート/インポート処理が必要なため、処理時間=ダウンタイムです。
そのため、週末や夜間、祝日など、ある程度の停止時間が許容される場面での移行に向いています。

  • 例:大型連休や年末メンテナンス期間に合わせ社内業務システムを移行

  • 例:DRサイト切り替えと合わせて計画停止を伴う移行

2. オンプレミスや旧バージョンからのクラウド移行

Oracle Database 10g以降の古いOracle Databaseから、Autonomous Databaseへ段階的に移行したいケースに適しています。特にStandard Edition を利用している環境等、機能制限がある場合にもData Pumpは活用可能です。

3. 環境間でスキーマ単位・テーブル単位の移行を行いたい場合

Data Pumpはスキーマやオブジェクト単位でのエクスポートが可能です。
このため、本番環境の一部データのみをテスト環境や開発環境に移したい場合や、移行対象を限定したい場合にも有効です。

  • 例:ユーザー管理用スキーマのみをステージング環境に移行

  • 例:不要なデータ(ログテーブルなど)を除外した移行

4. 他の移行ツールに比べてシンプルな構成で済ませたい場合

GoldenGateやRMANなどの移行手法と比較して、Data Pumpはネットワークや同期設定が不要で構成がシンプルです。
特に、複雑な運用が不要なワンタイム移行やPoC(概念実証)では使い勝手の良さが際立ちます。

以上がData Pumpの簡単な解説です。次項からは実際に行った検証内容を説明します。

既存OracleデータベースからData Pumpでエクスポート

ここからは、実際にData Pumpでデータ移行を実施していきます。 まずは移行元Oracleデータベースに接続し、スキーマのデータをData Pumpを使用してエクスポートします。

  1.  スキーマ単位のエクスポートコマンドを実施します
    • 例:
      expdp HR/oracle@ORCLPDB DIRECTORY=DATA_PUMP_DIR DUMPFILE=GCE.dmp LOGFILE=GCP.log SCHEMAS=HR
      • HR/oracle→エクスポートを実行するユーザー名/パスワード
      • ORCLPDB→移行元PDBの接続識別子
      • DIRECTORY=DATA_PUMP_DIR→インストール時に自動生成されるダンプファイルを配置用ディレクトリオブジェクト
      • DUMPFILE=GCE.dmp→ダンプファイル名称
      • LOGFILE=GCP.log→ログファイル名称
      • SCHEMAS=HR→移行スキーマ
  2. GCSにエクスポートしたファイルをアップロードします
    • バケットの作成
      1. 「GCS」のコンソール画面に行き、「バケット」から「作成」を選択
      2. ストレージ名を設定

      3. データ保存場所を設定、今回はAutonomous Databaseと同じリージョン(us-east4)を指定

      4. ストレージクラスはデフォルトの「スタンダード」を選択

      5. 公開アクセスの防止で「パブリックアクセスを禁止」にチェック
      6. アクセス制御を「均一」を選択

      7. 「オブジェクトデータを保護する方法を選択する」項目はデフォルトのまま

      8. 作成完了

    • GCE上のアクセススコープの変更
      デフォルトのアクセススコープでGCEを作成した場合、GCSのバケットへのアクセスが読み取り権限のみとなってしまうため、ダンプファイルを書き込むため書き込み権限を付与する。

      1. サーバが起動状態だとアクセススコープの変更ができないため、サーバを停止させる
      2. サーバ停止後、GCEのVMインスタンス詳細から「編集」を選択する
      3. GCE設定の内、アクセススコープの設定を「APIごとにアクセス権を設定」に変更し、ストレージの項目を「読み取り/書き込み」を選択する

      4. 「保存」を選択し、GCEを起動する
    • バケットへ権限の付与
      1. 作成したバケットの詳細を開き、権限タブを開く
      2. 「アクセスを許可」ボタンを押下

      3. プリンシパルを設定
        • GCEのVMインスタンス詳細を開き、「APIとIDの管理」項目内のサービスアカウントIDをコピーし、貼り付け

      4. 「ロールを割り当てる」内でロールを設定する
        • 「Cloud Storageレガシー」の「Storageレガシーバケット書き込み」を選択(今回は書き込みのみにしています。)

    •  エクスポートしたダンプファイルをバケットにアップロード
      1. GCEから以下のコマンドでGCSへアップロード
        • 例:
          gsutil cp /u01/app/oracle/admin/orcl/dpdump/3266C1AC4FA467E5E0630600920A16BD/GCE.dmp gs://iaas-to-paas-dmpstorage/GCE.dmp
          • /u01/app/oracle/admin/orcl/dpdump/3266C1AC4FA467E5E0630600920A16BD/GCE.dmpがアップロード対象のパス
          • gs://iaas-to-paas-dmpstorage/GCE.dmpがアップロード先のパス
      2. アップロード完了したらGCSのコンソールから確認

Oracle Database@Google Cloud上の環境にダンプファイルをインポート

次に移行先となるOracle Database@Google Cloud上のAutnomous Databaseにデータをインポートします。

  1. GCSでアクセスキーを作成
      1. GCSのコンソールを開く
      2. 左側の設定の項目を表示
      3. 「相互運用性」という項目を選択
      4. 一番下の「ユーザーアカウントのアクセスキー」の「鍵を作成」を押下
      5. アクセスキーが自動作成される

  2. GCEから新環境のデータベースに接続する
  3. 証明書の登録をする
      1. 以下のコマンドで登録
        set define off
        begin
        DBMS_CLOUD.CREATE_CREDENTIAL(
        credential_name => 'GOOGLE_CRED_NAME',
        username => 'GOOG5EHJMST2ADSMAKADUCCM',
        password => '************************'
        );
        END;
        /
      • credential_name → 一意の識別子を設定
      • username → GCSで作成したアクセスキーの自動作成されたusername
      • password → GCSで作成したアクセスキーの自動作成されたシークレット
  4. 完了すると「プロシージャーが正常に完了しました。」と表示されます。
  5. 以下のコマンドでダンプファイルがあることを確認
    • 例:
      SELECT * FROM DBMS_CLOUD.LIST_OBJECTS('GOOGLE_CRED_NAME', 'https://storage.googleapis.com/iaas-to-paas-dmpstorage/' );
  6.  インポートのコマンドを実行
    • 以下のコマンドを実施
      impdp admin/1Qazxsw21Qazxsw2@orclad_high \
      directory=data_pump_dir \
      credential=GOOGLE_CRED_NAME \
      dumpfile=https://storage.googleapis.com/iaas-to-paas-dmpstorage/GCE.dmp \
      logfile=GCEimp.log \
      remap_tablespace=TEST:DATA
      • directory→ デフォルトで作成されたオブジェクトディレクトリ
      • credential→ 3の証明書登録時に設定した値
      • dumpfile→ GCSに保存されているdmpファイルのパス
      • logfile→ 任意の名前
      • remap_tablespace→ Autonomous Database側に表領域が作成できないため、既存のDATA表領域に移行元のTESTをリマップしている
  7. インポートが完了した旨のメッセージが表示される
  8. データが移行されているかSELECT文などで確認

 

以上がData Pumpを用いてデータ移行する手順です。

インポートにかかる時間について、データ量を増加させてインポート時間を比較してみました。 ネットワークやディスク性能により大きく左右されるため、あくまで参考値として捉えてください。

データ件数(レコード件数) 容量(データサイズ) 時間
1000+1000 12.8KB+24KB 12秒
3550000+3550000 31.2MB+68.3MB≒100MB 18秒
40000000+40000000 796MB+377MB≒1GB 47秒
360000000+360000000 7GB+3.3GB≒10GB 4分6秒

まとめ

Oracle Database@Google Cloud上に作成したOracle Database にもGCS経由しData Pumpを使用することで簡単に移行することができました。
実際には、Data Pump操作自体よりもダンプファイルをGCSに転送するためのアクセス権限の付与や、Autonomous Database接続時の証明書登録といった設定に時間を費やしました。Data Pump自体は複雑な設定が不要な簡易ツールなため、様々な場面での活躍が期待できます。
今回のGoogle Cloud上にOracle Databaseを容易に作成できるようになったことで、今後同様のデータ移行作業に携わる機会も増えることが増えるかと思いますので本検証が参考になれば幸いです。

2025年8月29日 【Google Cloud】第3回:Oracle Database@Google Cloudを利用してみよう~Data Pump移行編~

Category Google Cloud

ご意見・ご相談・料金のお見積もりなど、
お気軽にお問い合わせください。

お問い合わせはこちら