Oracle スキーマごとにデータを RDS に移行する流れ [cloudpack OSAKA blog]

ナスです。

以前、DMS での DB 移行の記事を書きました。
nasrinjp1.hatenablog.com

この時は何も考えずに DB のデータを移行してみましたが、スキーマごとに移行したいという要件が結構あったりしますので、今回はスキーマごとにデータを移行する流れを見てみましょう。

ソースとターゲットの接続設定

ここは上に貼ってある過去記事の通りに接続設定をします。もう一回書くのがめんどいだけです…

タスク設定

ここが前回の記事と違うところです。今回は、WORK1 というスキーマの全テーブルを RDS に移行してみます。

まず、タスクのテーブルマッピングのところで、移行するスキーマ名を入力します。ここでは WORK1 と入れてます。

そしてそのすぐ下に、変換ルールを設定する箇所があります。ここで、下の図のように設定します。

ターゲットに「スキーマ」を選択、スキーマ名に今回移行するスキーマ WORK1 を入力します。そしてアクションで「名前の変更」「WORK1」を入力します。
スキーマ変換する設定なのに、WORK1 から WORK1 に変換って指示するなんて、なんか変ですよね？　でもこれには理由があります。

同じスキーマ名で移行するのになぜ変換するのか？

ここで DMS を使った Oracle データ移行のベストプラクティスのドキュメントをご紹介しましょう。
docs.aws.amazon.com

Oracle をターゲットとして使用するときは、ターゲット接続に使用されるスキーマ/ユーザーにデータを移行することを前提とします。別のスキーマにデータを移行する場合は、スキーマ変換を使用する必要があります。

って書かれています。以前書いた記事の中では、ターゲット DB は MASTER ユーザで接続しました。この状態で、スキーマ WORK1 のテーブルを移行すると、ターゲット側ではスキーマ MASTER のテーブルとして移行されてしまいます。なので、同じスキーマに移行するだけでもスキーマ変換ルールが必要になる、というわけです。

ここまで設定したら、タスク設定ではこのように見えているはずです。

では移行してみましょう！

work1-all タスクを選択して「開始」ボタンを押します。しばらくすると、ステータスが「ロード完了」となり移行が完了します。テーブル統計のタブでは、移行したテーブルとデータ件数を確認できますよ。

実際にテーブルがターゲット側に移行されているかを確認してみましょう。

SQL> select OWNER,TABLE_NAME,TABLESPACE_NAME from ALL_TABLES where OWNER like 'WORK%' order by OWNER,TABLE_NAME;

OWNER　TABLE_NAME　TABLESPACE_NAME  
--------　-------------- 　------------------------------  
WORK1　CLOBTBL1　USERS  
WORK1　TBL1　　　USERS

ちゃんとスキーマ WORK1 のテーブルとして移行されていますね。

この流れでわかるとは思いますが、スキーマごとに移行する場合は、スキーマ単位で DMS のタスクを作成する必要があります。スキーマ 100 個を移行しようと思ったら、タスクも 100 個作れば ok です。

かなり雑な説明ですが、やってみるととても簡単にスキーマごとにデータ移行できることがわかります。Oracle DB を RDS に移行する機会があればぜひやってみてくださいね。