【AWS】オンプレミスOracle DBをAWS RDS for Oracleに移行する | 2つの移行方法を徹底比較

AWS

今回は、オンプレミス環境で稼働しているOracle DatabaseをAWS RDS for Oracleに移行する手順について解説します。

AWS DMSとData Pumpという2つの主要な移行方法の違いや、セキュリティ設定の考慮事項、実際に起こりがちなトラブルとその対処法まで、実践的な内容を記載しました。

  1. なぜRDS for Oracleへの移行を検討するのか？
  2. 移行前の準備・確認事項
    1. 1. データベースのバージョン確認
    2. 2. データベースサイズの確認
    3. 3. 使用している機能の確認
      1. ⚠ 注意事項
  3. 移行方法の選択：AWS DMSとData Pumpの比較
      1. 💡 選択のポイント
  4. 方法1：AWS DMSを使った移行手順
    1. Step 1: レプリケーションインスタンスの作成
    2. Step 2: ソースエンドポイントの設定
    3. Step 3: ターゲットエンドポイントの設定
    4. Step 4: レプリケーションタスクの作成
    5. Step 5: タスクの開始と監視
  5. 方法2：Oracle Data Pumpを使った移行手順
    1. Step 1: ディレクトリオブジェクトの作成（ソースDB）
    2. Step 2: Data Pumpエクスポートの実行
      1. 💡 パラメータ説明
    3. Step 3: ダンプファイルのS3へのアップロード
    4. Step 4: RDS for OracleでS3統合の設定
    5. Step 5: Data Pumpインポートの実行
  6. セキュリティ設定の考慮事項
      1. 🔒 1. ネットワークセキュリティ
      2. VPC設定
      3. 🔒 2. 暗号化の設定
      4. 保管時の暗号化
      5. 転送時の暗号化
      6. 🔒 3. アクセス制御
      7. IAM Database Authentication
      8. 最小権限の原則
      9. 🔒 4. 監査とログ
  7. トラブルシューティング事例
    1. ケース1: AWS DMSでレプリケーションが遅延する
      1. 症状
    2. ケース2: Data Pumpインポート時に表領域エラーが発生
      1. 症状
    3. ケース3: 接続タイムアウトエラー
      1. 症状
    4. ケース4: 文字コード変換エラー
      1. 症状
      2. 💡 予防策
  8. 移行後の検証と切り替え
    1. データ整合性の確認
    2. パフォーマンステスト
    3. 切り替え手順
  9. まとめ
      1. 📚 参考リソース

なぜRDS for Oracleへの移行を検討するのか？

オンプレミスのOracleデータベースをAWS RDS for Oracleに移行することで、以下のようなメリットが得られます。

  • 運用負荷の軽減：バックアップ、パッチ適用、ハードウェア障害対応などがAWS側で自動化されます
  • 可用性の向上：Multi-AZ構成により、自動フェイルオーバーが可能になります
  • スケーラビリティ：需要に応じてスペックを柔軟に変更できます
  • 災害対策：リージョン間でのレプリケーションやスナップショット機能が利用できます

移行前の準備・確認事項

移行作業に入る前に、以下の項目を必ず確認しておきましょう。

1. データベースのバージョン確認

RDS for Oracleがサポートしているバージョンを確認します。2024年1月時点では、Oracle Database 19cおよび21cがサポートされています。

SELECT * FROM V$VERSION;

2. データベースサイズの確認

移行するデータ量を把握し、適切なRDSインスタンスタイプを選定します。

SELECT
SUM(bytes)/1024/1024/1024 AS size_gb
FROM dba_segments;

3. 使用している機能の確認

RDSでは一部のOracle機能が制限されています。以下の機能を使用している場合は、代替策を検討する必要があります。

  • データベースリンク（一部制限あり）
  • Oracle RACは使用不可（Multi-AZで代替）
  • ASM（Automatic Storage Management）は使用不可
  • RMAN（Recovery Manager）の一部機能制限

⚠ 注意事項

移行前に必ず本番環境のフルバックアップを取得してください。また、移行作業は必ず検証環境で事前テストを実施しましょう。

移行方法の選択：AWS DMSとData Pumpの比較

オンプレミスのOracle DBをRDSに移行する際、主に2つの方法があります。それぞれの特徴を理解して、自社の要件に合った方法を選択しましょう。

比較項目 AWS DMS Oracle Data Pump
ダウンタイム 最小化可能（継続的レプリケーション対応） ダウンタイムが必要（データ量に比例）
データ量 大規模データに対応 中小規模に適している
移行速度 中程度（ネットワーク帯域に依存） 高速（直接ファイル転送）
複雑さ 設定がやや複雑 シンプルで理解しやすい
コスト DMSインスタンス料金が発生 インスタンス料金なし（転送料金のみ）
適しているケース 本番稼働中で停止できない場合 メンテナンスウィンドウがある場合

💡 選択のポイント

AWS DMSを選択する場合：本番環境で継続稼働が必要、ダウンタイムを最小限にしたい、異種間移行も視野に入れている

Data Pumpを選択する場合：データ量が比較的少ない、メンテナンスウィンドウを確保できる、シンプルな移行を希望する

方法1：AWS DMSを使った移行手順

AWS Database Migration Service（DMS）は、データベースの移行を支援するマネージドサービスです。継続的なレプリケーションにも対応しており、ダウンタイムを最小化できます。

Step 1: レプリケーションインスタンスの作成

まず、データ移行を実行するためのレプリケーションインスタンスを作成します。

aws dms create-replication-instance \
–replication-instance-identifier oracle-migration-instance \
–replication-instance-class dms.c5.xlarge \
–allocated-storage 100 \
–vpc-security-group-ids sg-xxxxxxxxx \
–replication-subnet-group-identifier my-subnet-group \
–publicly-accessible false

Step 2: ソースエンドポイントの設定

オンプレミスのOracle DBへの接続情報を設定します。

aws dms create-endpoint \
–endpoint-identifier source-oracle-db \
–endpoint-type source \
–engine-name oracle \
–username admin \
–password YourPassword123 \
–server-name 192.168.1.100 \
–port 1521 \
–database-name ORCL \
–extra-connection-attributes “useLogminerReader=N;useBfile=Y”

Step 3: ターゲットエンドポイントの設定

RDS for Oracleへの接続情報を設定します。

aws dms create-endpoint \
–endpoint-identifier target-rds-oracle \
–endpoint-type target \
–engine-name oracle \
–username admin \
–password YourRDSPassword123 \
–server-name mydb.xxxxxx.ap-northeast-1.rds.amazonaws.com \
–port 1521 \
–database-name ORCL

Step 4: レプリケーションタスクの作成

実際のデータ移行を実行するタスクを作成します。

aws dms create-replication-task \
–replication-task-identifier oracle-migration-task \
–source-endpoint-arn arn:aws:dms:ap-northeast-1:123456789012:endpoint:source-oracle-db \
–target-endpoint-arn arn:aws:dms:ap-northeast-1:123456789012:endpoint:target-rds-oracle \
–replication-instance-arn arn:aws:dms:ap-northeast-1:123456789012:rep:oracle-migration-instance \
–migration-type full-load-and-cdc \
–table-mappings file://table-mappings.json

table-mappings.jsonの例：

{
“rules”: [
{
“rule-type”: “selection”,
“rule-id”: “1”,
“rule-name”: “1”,
“object-locator”: {
“schema-name”: “MYSCHEMA”,
“table-name”: “%”
},
“rule-action”: “include”
}
]
}

Step 5: タスクの開始と監視

# タスクの開始
aws dms start-replication-task \
–replication-task-arn arn:aws:dms:ap-northeast-1:123456789012:task:oracle-migration-task \
–start-replication-task-type start-replication# タスクの状態確認
aws dms describe-replication-tasks \
–filters “Name=replication-task-arn,Values=arn:aws:dms:ap-northeast-1:123456789012:task:oracle-migration-task”

方法2：Oracle Data Pumpを使った移行手順

Oracle Data Pumpは、Oracleネイティブのデータ移行ツールです。シンプルで高速な移行が可能ですが、ダウンタイムが発生します。

Step 1: ディレクトリオブジェクトの作成（ソースDB）

— ソースDBで実行
CREATE DIRECTORY export_dir AS ‘/backup/export’;
GRANT READ, WRITE ON DIRECTORY export_dir TO system;

Step 2: Data Pumpエクスポートの実行

オンプレミス環境でデータをエクスポートします。

expdp system/password@ORCL \
DIRECTORY=export_dir \
DUMPFILE=mydb_export_%U.dmp \
LOGFILE=export.log \
SCHEMAS=MYSCHEMA \
PARALLEL=4 \
COMPRESSION=ALL \
FILESIZE=2G

💡 パラメータ説明

  • PARALLEL=4：並列度を4に設定（CPUコア数に応じて調整）
  • COMPRESSION=ALL：全データを圧縮してファイルサイズを削減
  • FILESIZE=2G：ダンプファイルを2GBごとに分割

Step 3: ダンプファイルのS3へのアップロード

エクスポートしたファイルをAmazon S3にアップロードします。

# AWS CLIでS3にアップロード
aws s3 cp /backup/export/ s3://my-migration-bucket/oracle-dump/ \
–recursive \
–storage-class STANDARD_IA

Step 4: RDS for OracleでS3統合の設定

RDSからS3にアクセスできるようにIAMロールを設定します。

# IAMロールの作成（信頼ポリシー）
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Principal”: {
“Service”: “rds.amazonaws.com”
},
“Action”: “sts:AssumeRole”
}
]
}# S3アクセスポリシー
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“s3:GetObject”,
“s3:ListBucket”
],
“Resource”: [
“arn:aws:s3:::my-migration-bucket”,
“arn:aws:s3:::my-migration-bucket/*”
]
}
]
}

RDS DBインスタンスにIAMロールを関連付けます。

aws rds add-role-to-db-instance \
–db-instance-identifier mydb \
–feature-name S3_INTEGRATION \
–role-arn arn:aws:iam::123456789012:role/rds-s3-integration-role

Step 5: Data Pumpインポートの実行

RDS for Oracleでインポートを実行します。

— RDS for Oracleで実行
BEGIN
rdsadmin.rdsadmin_s3_tasks.download_from_s3(
p_bucket_name => ‘my-migration-bucket’,
p_directory_name => ‘DATA_PUMP_DIR’,
p_s3_prefix => ‘oracle-dump/’
);
END;
/– インポート実行
DECLARE
v_hdnl NUMBER;
BEGIN
v_hdnl := DBMS_DATAPUMP.OPEN(
operation => ‘IMPORT’,
job_mode => ‘SCHEMA’,
job_name => ‘IMPORT_JOB’
);DBMS_DATAPUMP.ADD_FILE(
handle => v_hdnl,
filename => ‘mydb_export_01.dmp’,
directory => ‘DATA_PUMP_DIR’,
filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_DUMP_FILE
);

DBMS_DATAPUMP.ADD_FILE(
handle => v_hdnl,
filename => ‘import.log’,
directory => ‘DATA_PUMP_DIR’,
filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_LOG_FILE
);

DBMS_DATAPUMP.METADATA_FILTER(
handle => v_hdnl,
name => ‘SCHEMA_EXPR’,
value => ‘IN (”MYSCHEMA”)’
);

DBMS_DATAPUMP.START_JOB(handle => v_hdnl);
DBMS_DATAPUMP.DETACH(handle => v_hdnl);
END;
/

セキュリティ設定の考慮事項

データベースの移行において、セキュリティは非常に重要な要素です。以下の項目を必ず確認しましょう。

🔒 1. ネットワークセキュリティ

VPC設定

  • RDSインスタンスはプライベートサブネットに配置する
  • パブリックアクセスは無効化する（Publicly accessible: No）
  • 適切なセキュリティグループを設定する
# セキュリティグループのインバウンドルール例
# アプリケーションサーバーからのみ接続許可
aws ec2 authorize-security-group-ingress \
–group-id sg-xxxxxxxxx \
–protocol tcp \
–port 1521 \
–source-group sg-app-servers

🔒 2. 暗号化の設定

保管時の暗号化

  • RDS作成時に必ず暗号化を有効にする
  • AWS KMS（Key Management Service）でカスタマーマネージドキーを使用することを推奨
# 暗号化を有効にしたRDSインスタンスの作成
aws rds create-db-instance \
–db-instance-identifier mydb \
–db-instance-class db.r5.xlarge \
–engine oracle-ee \
–master-username admin \
–master-user-password YourPassword123 \
–allocated-storage 100 \
–storage-encrypted \
–kms-key-id arn:aws:kms:ap-northeast-1:123456789012:key/xxxxxxxx

転送時の暗号化

  • SSL/TLS接続を必須にする
  • オプショングループでSSL設定を有効化

🔒 3. アクセス制御

IAM Database Authentication

パスワードではなくIAM認証を使用することで、セキュリティを強化できます。

# IAMデータベース認証の有効化
aws rds modify-db-instance \
–db-instance-identifier mydb \
–enable-iam-database-authentication \
–apply-immediately

最小権限の原則

  • アプリケーション用ユーザーには必要最小限の権限のみを付与
  • 管理用アカウントとアプリケーション用アカウントを分離
  • パスワードポリシーを厳格に設定

🔒 4. 監査とログ

  • CloudWatch Logsへのログ出力を有効化
  • 監査ログ（AUDIT_TRAIL）を有効にする
  • 定期的にログを確認し、異常なアクセスパターンを検知
— RDSで監査ログを有効化
BEGIN
rdsadmin.rdsadmin_util.set_configuration(
name => ‘audit trail’,
value => ‘DB,EXTENDED’
);
END;
/

トラブルシューティング事例

実際の移行作業でよく発生するトラブルと、その対処法をご紹介します。

ケース1: AWS DMSでレプリケーションが遅延する

症状

CDC（Change Data Capture）モードでレプリケーションを開始したが、ソースDBの変更がターゲットに反映されるまでに大きな遅延が発生する。

原因：

  • レプリケーションインスタンスのスペック不足
  • ネットワーク帯域の制約
  • ソースDBのアーカイブログの生成速度が速すぎる

対処法：

  1. レプリケーションインスタンスのサイズを大きくする（例：c5.xlargeからc5.2xlargeへ）
  2. BatchApplyEnabled設定を有効にする
  3. ParallelApplyThreads数を増やす
# タスク設定でバッチ適用を有効化
{
“TargetMetadata”: {
“BatchApplyEnabled”: true,
“ParallelApplyThreads”: 8,
“ParallelApplyBufferSize”: 1000
}
}

ケース2: Data Pumpインポート時に表領域エラーが発生

症状

インポート実行時に「ORA-00959: tablespace does not exist」エラーが発生する。

原因：

ソースDBとターゲットRDSで表領域の構成が異なっている。

対処法：

  1. 事前にRDSで必要な表領域を作成する
  2. または、REMAP_TABLESPACE オプションを使用してデフォルト表領域にマッピング
— 表領域のリマップ
DBMS_DATAPUMP.METADATA_REMAP(
handle => v_hdnl,
name => ‘REMAP_TABLESPACE’,
old_value => ‘USERS_OLD’,
value => ‘USERS’
);

ケース3: 接続タイムアウトエラー

症状

DMSエンドポイント接続テストで「Test connection failed」というエラーが発生する。

原因：

  • セキュリティグループの設定不備
  • ネットワークACLの制限
  • ソースDBのファイアウォール設定

対処法：

  1. DMSレプリケーションインスタンスのセキュリティグループを確認
  2. ソースDBへの接続元IPアドレスをホワイトリストに追加
  3. VPCピアリングまたはVPN/Direct Connect経由の接続を確認
# セキュリティグループの確認
aws ec2 describe-security-groups \
–group-ids sg-xxxxxxxxx# ネットワーク接続のテスト（EC2から実行）
telnet source-db-server.example.com 1521

ケース4: 文字コード変換エラー

症状

日本語データが文字化けする、または「ORA-12899: value too large for column」エラーが発生。

原因：

ソースDBとターゲットRDSの文字コード（NLS_CHARACTERSET）が異なる。

対処法：

  1. 移行前に文字コードを統一する
  2. RDS作成時に正しい文字コードを指定
  3. データ移行後に文字コード変換を実施（最終手段）
— 文字コードの確認
SELECT value FROM nls_database_parameters WHERE parameter = ‘NLS_CHARACTERSET’;– RDS作成時の文字コード指定例
aws rds create-db-instance \
–db-instance-identifier mydb \
–engine oracle-ee \
–character-set-name AL32UTF8 \
…

💡 予防策

文字コード問題を避けるため、移行前に必ずソースDBとターゲットRDSの文字コードを確認し、統一しておきましょう。一般的には「AL32UTF8」（UTF-8）を推奨します。

移行後の検証と切り替え

データ移行が完了したら、以下の検証を必ず実施しましょう。

データ整合性の確認

— レコード件数の比較
SELECT
table_name,
num_rows
FROM dba_tables
WHERE owner = ‘MYSCHEMA’
ORDER BY table_name;– チェックサム比較（重要テーブル）
SELECT
COUNT(*),
SUM(ORA_HASH(column1 || column2 || column3)) as checksum
FROM important_table;

パフォーマンステスト

  • 主要なSQLクエリの実行時間を測定
  • アプリケーションからの接続テスト
  • 負荷テストツール（JMeter等）での検証

切り替え手順

  1. メンテナンスモードへの移行を通知
  2. アプリケーションの停止
  3. 最終データ同期（DMSの場合は自動）
  4. 接続文字列の変更（RDSエンドポイントへ）
  5. アプリケーションの起動
  6. 動作確認
  7. 監視体制の確立

まとめ

オンプレミスのOracle DatabaseをAWS RDS for Oracleに移行する方法として、AWS DMSとOracle Data Pumpの2つの手法を詳しく解説してきました。

AWS DMSは、ダウンタイムを最小化したい場合や継続的なレプリケーションが必要な場合に適しており、Data Pumpは、メンテナンスウィンドウを確保できる場合にシンプルで高速な移行を実現できます。

どちらの方法を選択する場合でも、以下のポイントを忘れずに：

  • 必ず検証環境で事前テストを実施する
  • 本番環境のフルバックアップを取得しておく
  • セキュリティ設定を適切に構成する
  • 移行後のデータ整合性確認を徹底する
  • ロールバック手順を事前に準備しておく

クラウドリフトは一見複雑に見えますが、適切な準備と手順を踏めば、安全かつ確実に実施できます。本記事が皆さんのAWS移行プロジェクトの一助となれば幸いです。

【注意】

このブログは技術に関する知識や経験を共有することを目的としており、情報の正確性に努めていますが、その内容の正確性や完全性を保証するものではありません。ブログの情報を利用する場合は、自己の責任において行動してください。ブログの内容に基づいて行った行動や決定によって生じた損害や被害について、筆者は一切の責任を負いません。

 

記事の内容の一部は、生成AIで作成しています。

AWSITナレッジ
AWSRDS移行クラウドリフト
この記事の作者
StarTeller

30歳で異業種からITエンジニアへ転身し、10年以上にわたりインフラエンジニアとして様々な現場でシステム構築・運用に携わってきました。
得意分野はLinux/Windowsのサーバー構築・運用で、ネットワークやAWSなども実務で活用しています。このブログでは、これまでの業務で培った経験を基に、日々の業務で遭遇した問題の解決方法や、システム構築の具体的な手順を解説。現場のエンジニアが実際に「困ったとき」に参照できる情報を意識して投稿していこうと思っています。
※サーバ運用費がかかっているので、広告を掲載させて頂いてます。

StarTellerをフォローする
シェアする
StarTellerをフォローする
StarTeller
タイトルとURLをコピーしました