【AWS】AWS DMSを使ってオンプレOracleをRDS for Oracleに移行する方法【設定手順・注意点まとめ】

今回は、AWS Database Migration Service（以下、DMS）を使って、オンプレミス環境のOracleデータベースをAmazon RDS for Oracleへ移行する手順と注意点を解説します。クラウド移行プロジェクトが増えている昨今、「オンプレのOracleをどうやってAWSに移すか」という課題に直面するインフラエンジニアも多いのではないでしょうか。本記事では、移行全体のフローからDMSの具体的な設定、そして見落としがちな注意点まで、実務で使えるレベルで丁寧に説明します。

AWS DMSとは
移行全体のフロー
フェーズ①：事前準備
1. オンプレOracle側の設定
2. AWS側の事前準備
フェーズ②：レプリケーションインスタンスの作成
フェーズ③：エンドポイントの設定
1. ソースエンドポイント（オンプレOracle）
2. ターゲットエンドポイント（RDS for Oracle）
フェーズ④：タスクの作成・実行
フェーズ⑤：移行後の検証と切り替え
移行時の注意点
まとめ

AWS DMSとは

AWS DMS（Database Migration Service）は、データベースをAWSへ安全かつ迅速に移行するためのフルマネージドサービスです。移行中もソースデータベースを稼働させたまま移行を進められるため、ダウンタイムを最小限に抑えられるのが最大の特長です。主な特徴は以下のとおりです。

Oracle、MySQL、PostgreSQL、SQL Serverなど多様なDBエンジンに対応
ホモジニアス移行（同種DB間）とヘテロジニアス移行（異種DB間）の両方をサポート
全量ロード（Full Load）と継続的レプリケーション（CDC）を組み合わせた移行が可能
移行の進捗やエラーをAWSコンソールから監視できる

今回はOracleからRDS for Oracleへのホモジニアス移行のケースを扱います。同種DB間の移行であるため、スキーマ変換は原則不要ですが、設定面での注意点はいくつか存在します。

移行全体のフロー

AWS DMSを用いた移行は、大きく以下の5つのフェーズで構成されます。

フェーズ	作業内容
① 事前準備	移行元・移行先DBの設定確認、IAMロール・VPC・セキュリティグループの準備
② レプリケーションインスタンスの作成	DMSのレプリケーションインスタンスをAWSコンソールから作成
③ エンドポイントの設定	ソース（オンプレOracle）とターゲット（RDS for Oracle）のエンドポイントを作成・接続テスト
④ タスクの作成・実行	移行タスクを設定し、Full Load または Full Load + CDCを実行
⑤ 移行後の検証	データ整合性の確認、アプリケーション接続テスト、切り替え判断

各フェーズを順番に解説します。

フェーズ①：事前準備

オンプレOracle側の設定

CDC（継続的データキャプチャ）を使うには、ソースOracleでアーカイブログモード（ARCHIVELOG）が有効になっている必要があります。以下のコマンドで確認できます。

-- アーカイブログモードの確認
SELECT LOG_MODE FROM V$DATABASE;

LOG_MODEがARCHIVELOGであればOKです。NOARCHIVELOGの場合は、データベースをマウント状態にしてから変更が必要です。次に、DMS用のデータベースユーザーを作成します。最低限以下の権限が必要です。

-- DMS用ユーザー作成（例）
CREATE USER dms_user IDENTIFIED BY "your_password";
GRANT CREATE SESSION TO dms_user;
GRANT SELECT ANY TABLE TO dms_user;
GRANT SELECT ON V_$DATABASE TO dms_user;
GRANT SELECT ON V_$ARCHIVED_LOG TO dms_user;
GRANT SELECT ON V_$LOG TO dms_user;
GRANT SELECT ON V_$LOGFILE TO dms_user;
GRANT SELECT ON V_$LOGMNR_LOGS TO dms_user;
GRANT SELECT ON V_$LOGMNR_CONTENTS TO dms_user;
GRANT LOGMINING TO dms_user;  -- Oracle 12c以降
GRANT EXECUTE ON DBMS_LOGMNR TO dms_user;
GRANT EXECUTE ON DBMS_LOGMNR_D TO dms_user;

また、Supplemental Loggingを有効にしてください。CDCに必要な変更ログを正確にキャプチャするために必須です。

-- データベースレベルのSupplemental Logging有効化
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

-- テーブルレベルでの設定（対象テーブルが多い場合）
ALTER TABLE スキーマ名.テーブル名 ADD SUPPLEMENTAL LOG DATA ALL COLUMNS;

AWS側の事前準備

VPC・サブネット：レプリケーションインスタンスを配置するVPCとサブネットを確認する。オンプレとの接続にはDirect ConnectまたはVPN接続が必要。
セキュリティグループ：DMSレプリケーションインスタンスからRDSへの通信（デフォルト1521番ポート）を許可する。
IAMロール：DMS用のIAMロール（dms-vpc-role、dms-cloudwatch-logs-role）をあらかじめ作成しておく。
RDS for Oracleの作成：移行先のRDSインスタンスをあらかじめ作成し、接続確認を済ませておく。

フェーズ②：レプリケーションインスタンスの作成

AWSコンソールの「AWS DMS」から「レプリケーションインスタンス」を選択し、「インスタンスの作成」をクリックします。

設定項目	推奨値・補足
インスタンスクラス	本番移行では `dms.r5.large` 以上を推奨。データ量に応じて選定。
ストレージ	デフォルト50GBだが、大量データの場合は拡張を検討。
VPC	RDSと同じVPCまたはVPCピアリングが通じているVPCを選択。
マルチAZ	本番環境では有効化を推奨。可用性が向上する。
パブリックアクセス	オンプレとの接続はVPN/Direct Connect経由のため、通常は無効。

インスタンスの作成には数分かかります。ステータスが「available」になったら次のステップへ進みます。

フェーズ③：エンドポイントの設定

ソースエンドポイント（オンプレOracle）

「エンドポイント」→「エンドポイントの作成」から、以下のように設定します。

設定項目	設定値
エンドポイントタイプ	ソース
エンジン	Oracle
サーバー名	オンプレOracleのIPアドレスまたはホスト名
ポート	1521（デフォルト）
ユーザー名 / パスワード	事前準備で作成したDMSユーザーの情報
SID またはサービス名	オンプレOracleのSIDまたはサービス名を入力

設定後、「接続のテスト」を実行して「成功」と表示されることを確認してください。

ターゲットエンドポイント（RDS for Oracle）

同様にターゲット側のエンドポイントを作成します。RDSの場合、コンソールで「RDSインスタンスから選択」を使うと接続情報を自動的に取得できるため便利です。

設定項目	設定値
エンドポイントタイプ	ターゲット
エンジン	Oracle
RDSインスタンスの選択	移行先RDS for Oracleを選択
ユーザー名 / パスワード	RDS管理者ユーザーの情報

フェーズ④：タスクの作成・実行

「データベース移行タスク」→「タスクの作成」から移行タスクを設定します。重要な設定項目を解説します。

移行タイプの選択

移行タイプ	概要	用途
全既存データの移行（Full Load）	スナップショット的に全データをコピー	停止を許容できる場合
全既存データの移行および継続的変更のレプリケーション（Full Load + CDC）	全量コピー後に差分を継続的に同期	ダウンタイムを最小化したい場合（推奨）
データ変更のみのレプリケーション（CDC Only）	変更分のみをレプリケーション	別手段で初期データを投入済みの場合

本番移行ではFull Load + CDCの組み合わせを推奨します。全データを転送しながらも、移行中に発生した変更もリアルタイムで同期し続けるため、最終的なカットオーバーを短時間で行えます。

テーブルマッピングの設定

移行対象のスキーマ・テーブルをJSONまたはGUIで指定します。特定のスキーマのみ移行する場合の例を示します。

{
  "rules": [
    {
      "rule-type": "selection",
      "rule-id": "1",
      "rule-name": "include-all-tables",
      "object-locator": {
        "schema-name": "APP_SCHEMA",
        "table-name": "%"
      },
      "rule-action": "include"
    }
  ]
}

特定のテーブルを除外したい場合は、"rule-action": "exclude"のルールを追加します。

タスク設定のポイント

LOB列の設定：BLOBやCLOBなどのLOBデータが含まれる場合、「LOB設定」で「フルLOBモード」を選択する。デフォルトの「制限付きLOBモード」では切り捨てが発生することがある。
ターゲットテーブルの準備モード：「何もしない」「切り捨て」「削除して再作成」から選択。初回移行では「削除して再作成」が安全。
検証の有効化：「データ検証を有効にする」をONにすることで、移行後のデータ整合性チェックを自動化できる。

フェーズ⑤：移行後の検証と切り替え

Full Load完了後、CDCが追いついている状態（レイテンシがほぼ0秒）になったら、カットオーバーのタイミングです。

アプリケーションの接続先をRDS for Oracleのエンドポイントに変更する
移行元のOracleへの書き込みを停止し、残りのCDCが完全に適用されたことを確認する
行数・チェックサムなどでデータの整合性を検証する
アプリケーションの動作確認テストを実施する

移行時の注意点

① シーケンス・ストアドプロシージャは自動移行されない

AWS DMSはテーブルデータの移行に特化しており、シーケンス、ストアドプロシージャ、トリガー、ビューなどのDBオブジェクトは自動では移行されません。これらは別途、Data Pump（expdp/impdp）やSCT（Schema Conversion Tool）を使って移行する必要があります。

② RDSのOracleエディションとライセンスを確認する

RDS for OracleはStandard Edition 2とEnterprise Editionに対応しています。オンプレ側で使用しているエディションと機能を確認し、移行先で同等の機能が使えるか必ず事前に確認してください。特にパーティショニングやAdvanced Compressionなどのオプション機能はエディションによって利用可否が異なります。

③ 文字コードの統一

オンプレ側のキャラクタセット（例：JA16SJIS）とRDS側の設定が異なる場合、文字化けや移行エラーが発生することがあります。RDS for Oracleを作成する際に文字コードを合わせておくか、事前に変換計画を立てておきましょう。

④ ネットワーク帯域とレプリケーションインスタンスのサイジング

データ量が多い場合、Full Loadの時間はネットワーク帯域とレプリケーションインスタンスのスペックに大きく左右されます。本番移行前に、テスト環境で移行時間を計測し、カットオーバー計画に余裕を持たせることが重要です。

⑤ DMSタスクのログ監視

移行中はDMSタスクのログをCloudWatch Logsで確認できます。エラーや警告が出ていないか定期的にチェックしましょう。特に「ERROR」と「WARN」レベルのメッセージは見逃さないようにしてください。

まとめ

本記事では、AWS DMSを使ったオンプレミスOracleからRDS for Oracleへの移行について、全体フローから具体的な設定手順、注意点まで解説しました。要点を整理します。

移行前にアーカイブログモードとSupplemental Loggingを必ず有効化する
本番移行ではFull Load + CDCを組み合わせてダウンタイムを最小化する
DMSはテーブルデータのみ移行対象。DBオブジェクトは別途移行が必要
文字コード・エディション・ライセンスは事前に必ず確認する
CloudWatch Logsでタスクログを監視し、エラーを早期に検知する

AWS DMSは適切に設定すれば非常に強力な移行ツールですが、事前準備の品質が移行の成否を大きく左右します。本番移行の前に必ずテスト環境で動作確認を行い、手順書を整備したうえで臨むことをお勧めします。関連記事として、Oracle DBのバックアップ・リストア手順やAWS RDSのパラメータグループ設定も参考にしてみてください。