【事前チェック編】OracleをDMSで移行してみる

こんにちは、技術2課の杉村です。
もはや夏本番。真夏日が続きますが、体調はいかがでしょうか。
人間の体はマイグレーションしようと思っても替えが無いので、大事にしたいものです。

さて今回は、なにかと噂のDatabase Migration Service(以下、DMS)を利用してOracle DatabaseをAWSに移行する方法をご紹介いたします。
今回は事前チェック編。まずは移行の方法を検討し、あなたのOracle DatabaseがDMSで移行するのに適しているか、確認してみましょう。

その前に、DMSの基本的なご紹介は、今をときめく技術4課の多田さんのブログエントリーをぜひご覧ください。

【準備編】Database Migration Serviceにチャレンジ！
http://blog.serverworks.co.jp/tech/2017/04/12/dms-beginner-1/

Oracle to Oracleの移行方法

Oracleのマイグレーションにはいくつか方法があります。
DMSを使うのもその一つ。

DMSの移行タスクの選択

DMSでは、3種類の移行タスクを選択できます。
[A] Migrate existing data - ソースDBのデータを全て移行（フルロード）する。（ダウンタイム不要）
[B] Migrate existing data and replicate ongoing changes - ソースDBのデータをフルロードした後、更新をキャプチャしてターゲットDBに継続的に移行する。
[C] Replicate data changes only - ソースDBの更新をキャプチャして継続的に移行する。

フルロードのみ行うのが[A]、差分移行のみ行うのが[C]、[A]と[C]を両方行うのが[B]となります。
単純にいえば、[B]を使用すれば、ほとんどダウンタイム無しで移行を行うことができます。しかしビューやプロシージャなど、DMSでは移行できないスキーマオブジェクトがあるので、DMSだけで移行を全て完了するのは難しいという現実があります。ですので、今回は以下のようなケースを想定してご紹介しようと思います。

DMSとOracle DataPumpの併用

目的: オンプレミス環境のOracle DatabaseをAWS上のRDS for Oracleに移行する
※以降、この記事では、移行元データベースを「ソースDB」、移行先データベースを「ターゲットDB」と呼ぶことにします。

ソースDBへの更新を停止
Oracle Data Pumpでdmpファイルをエクスポート
エクスポート完了後、ソースDBへの更新を再開
ターゲットDBにdmpファイルをインポート
DMSの "Replicate data changes only" (差分移行)タスクで、Data Pumpのエクスポート後に生じた差分を移行
移行タスクが安定しリアルタイムにデータを同期している状態になったら、ソースDBへの更新を再び停止
DMSによりソースDBとターゲットDBの最終的な差分移行
アプリケーションの使用するDBをターゲットDBに変更

今回は、最初のフルロードはData Pumpで行い、差分の移行にDMSを利用する、という方法を採用しました。

ダンプファイルのみを用いた移行方法ですと、ソースDBでダンプファイルをエクスポート開始してから、ターゲットDBにダンプファイルをインポートし終わって、アプリケーションの向き先を変えるまで、長いダウンタイムを要してしまいます。(Fig. 1)

一方で、先にご紹介したようなData Pump + DMSの併用であれば、ダウンタイムはdmpファイルのエクスポートを行う時間（1～3）と、アプリケーションの向き先を変えるまでの時間（6～8）だけですみます。 (Fig. 2)

小さいダウンタイムで、かつ確実にオブジェクトを移行するために、Data PumpとDMSの合わせ技で移行を成功させようというわけです。

もちろんこれが唯一の答えではありません。
どれくらいのダウンタイムが許容されるか、データ量はどのくらいか、どのようなオブジェクトが存在するか、などにより最適な移行方法は違います。
こちらはあくまで一例なのです。

移行の制限

さてどうやって移行するか、おおまかな流れがイメージできたところですが、実際にDMSで問題なく移行が行えるのか、心配なところです。

代表的なところでは、DMSでのOracle移行には以下のような制限があります。
できないことを並べ立てるとちょっとネガティブな感じになってしまいますが、できないことを明らかにしておくことは大事です。

DMSによる移行の制限

DMSでは、例えば以下のようなものは移行できません。DMS以外の方法で移行する必要があります。

ビュー、ストアドプロシージャ・トリガ・シノニムなどのオブジェクト
表領域・ユーザ・ロールなどのスキーマ定義情報

また、差分移行では以下のような更新をキャプチャして移行することはできません。
参考: AWS Database Migration Service のソースとしての Oracle データベースの使用

パーティション・サブパーティションにたいする ADD、DROP、EXCHANGE、TRUNCATE 等のデータ変更は移行できない
ALTER TABLE ADD DEFAULT <> を用いると、ターゲットDBにデフォルト値が移行されず、新しい列は NULL になってしまう
CREATE TABLE AS SELECT ... ではデータが複製されず新しいテーブルのみ作成される
Oracle DBMS_REDEFINITIONパッケージにより生じた変更(テーブルメタデータやOBJECT_IDの変更など)は移行されない
LOBの更新（デフォルトでは移行できないが、Oracleのバージョンによっては移行できるようにする方法もある)

ソースDBへの事前設定（差分移行の場合）

また、DMSで差分移行をするには、ソースDBに以下の設定をする必要があります。
何らかの事情で以下の設定ができない場合は、DMSの差分移行は使えません。

・ARCHIVELOGモードをONにする
DMSはREDOログ・アーカイブログからデータ変更を読み取ってターゲットDBに適用します。
そのためかDMSの仕様として、ARCHIVELOGモードがONである必要があります。

・サプリメンタル・ロギングをOnにする
サプリメンタル・ロギングとは、REDOログに記録される追加的なログのことです。
DMSはREDOログ・アーカイブログから変更をキャプチャしています。
REDOログは適用先をROWIDで決定しますが、ROWIDはデータベースごとに固有のIDです。
ですからソースDBのROWIDをそのままターゲットDBに持って行っても、どこに適用していいか分からないのです。
そのため、サプリメタル・ロギングをONにすることで追加の情報をREDOログに書き込み、ターゲットDBでも利用できるようにするのです。

サプリメンタルロギングについてはDMSの「エンドポイント」にも、とある設定が必要です。
これは次回のブログでご紹介いたします。

また以下は、ソースDBがRDSの場合のみ、設定が必要です。
参考: Amazon RDS DB インスタンス上の Oracle のソースとしての設定

自動バックアップを有効にする
ARCHIVEログの保存期間を設定する

下記はRDSでアーカイブログの保存期間を24時間に設定する例です。もちろんディスク容量を消費しますのでご留意を。

exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);

事前検証は必要

上記のような条件を許容できる、または回避できるのであれば、DMSでの移行はとても有力な選択肢です。

条件のチェックがOKでも、DMSでの本番移行を実施する前に、検証をすることが非常に重要です。
ほんとうにすべてのトランザクションがキャプチャされて移行されるのか、複数のパターンで試してみるといいでしょう。

さて、事前チェック編はひとまずここまでです。
次回は、DMSタスクの設定方法についてご紹介いたします。