ナスです。
以前、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 に移行する機会があればぜひやってみてくださいね。
