【前準備・実行編】OracleをDMSで移行してみる

こんにちは、技術2課の杉村です。
私、築30年ほどの1K・5.5畳のアパートに住んでいるのですが、もう少し広くて新しいところに引っ越したいなという欲が沸いています。
しかし引っ越しにはお金もかかるし、時間がかかるので大変です。
AWS DMSのように、生活に影響を与えずにじわじわと引っ越すことってできないんですかね...

前回の「【事前チェック編】OracleをDMSで移行してみる」にて、AWS Database Migration Service(以下、DMS)を用いてOracle Databaseを移行する際の事前チェック事項について記載しました。
今回は続編として、以下の二点を紹介します。

• データベースへの事前作業
• 実際の移行で気を付けるべきポイント

サプリメンタル・ロギング

事前チェック編でも書いたように、OracleでCDC（差分移行）を利用する場合、ソースDBで「サプリメンタルロギング」を有効化する必要があります（Oracle LogMinerがREDOログ・アーカイブログから更新を読み取るため）。
有効化の方法を以下に記載します。

最小サプリメンタルロギング

まず必須作業として「最小サプリメンタルロギング」をDB全体に適用する必要があります。以下をソースDBに対して実行してください。

RDS以外のOracle

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

RDS for Oracle

exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD');

接続属性の設定

DMSを利用する際は「エンドポイント」をソースDBとターゲットDBの両方に対して作成する必要があります。エンドポイントにはDMSがデータをレプリケートする際に一定の処理を加える設定（接続属性）をすることができます。前述のソースDBに対する最小サプリメンタルロギングの有効化が終わったら、以下を実行します。

ソースDBのDMSエンドポイントの設定画面にて「アドバンスト ＞ 追加の接続属性」に

addSupplementalLogging=Y

を設定することで、サプリメンタルロギングを全テーブルの全カラムに対して付与することができます。

サプリメンタルロギングについての注意点

ただし、上記の接続属性の設定には注意点があります。
ソースエンドポイントに addSupplementalLogging=Y を指定すると、全てのテーブルの全カラムにサプリメンタルロギングが追加されることになり、REDOログ書込みが増え、それがオーバヘッドとなりパフォーマンスが低下するおそれもあります。

それが心配の場合、以下の方法でテーブルごとにサプリメンタルロギングを追加することができます。

主キーの存在するすべてのテーブルに対してロギング有効化

RDS以外のOracle

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

Oracle for RDS

exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD','PRIMARY KEY');

ユニークキーの存在するすべてのテーブルに対してロギング有効化

RDS以外のOracle

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;

Oracle for RDS

exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD','UNIQUE');

addSupplementalLogging=Y がすべての列をサプリメンタルロギングとして記録するのに対し、上記2つは主キーやユニークキーのみを対応とするため、よりオーバヘッドが小さいと言えます。

主キーもユニークキーもないテーブルへのロギング有効化

主キーもユニークキーも存在しないテーブルでは、レコードの位置を一意に特定するため、以下のように全カラムを対象としてロギングをテーブルごとに有効化する必要があります。

ALTER TABLE <table_name> ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

タスクの作成

ソースDBに対する準備作業が終わったら、いよいよDMS移行タスクを作成します。
タスクの作成において推奨されるポイントを記載します。

ターゲットテーブル作成モード

ターゲット上のテーブルのDROP を選択することが推奨されます。
タスクが失敗しリトライをかけるとき等に、これが選択されていれば以前同期したテーブルを削除してから同期されるため、不整合が起きることを防ぐことができます。

ロギングの有効化

ロギングはON にすることが推奨です。
これをONにすることによりCloudWatch Logsにタスクの実行ログが出力されます。
ONにしていないと、タスクが失敗したときにその原因を追うことが難しくなります。
AWSサポートに問い合わせる際も、このログを添付することで問題解決に繋がる可能性があります。

実行

事前チェックや準備が終わったら、いよいよタスクの実行です。
タスクが始まってから最初のうちは実行状況を注視し、問題が起きそうでないか確認します。

また、DMSでは移行できないオブジェクトやデータが存在することも事実です。
事前検証を十分に実施したうえで、本番移行に臨みましょう。

杉村 勇馬 (記事一覧)

サーバーワークス → 株式会社G-gen 執行役員CTO

2021 Japan APN Ambassadors / 2021 APN All AWS Certifications Engineers

マルチAWSアカウント管理運用やネットワーク関係のAWSサービスに関するブログ記事を過去に執筆。

2021年09月から株式会社G-genに出向、Google Cloud(GCP)が専門に。G-genでもGoogle Cloud (GCP) の技術ブログを執筆中。