sorta kinda...

主にAWS関連ですが、これに限らずいろいろ勉強したことや思ったことを書いていきます。

DMS で RDS Oracle に移行する際に引っ掛かりがちなポイント [cloudpack OSAKA blog]

ナスです。

オンプレ Oracle から RDS Oracle に移行する話が意外と多いです。Aurora への移行とかはどれくらい行われているのかはわかりませんが、少なくとも私はまだほとんど聞いたことがありません…まだまだこれからですね。

ただ、Oracle から RDS Oracle に移行するだけなのに、わりとすんなりいかないもんです。なんとなく多いと思っているのは、DMS で移行後のデータ型が変換されてしまって悩むパターンですね。今回は数値データ型(NUMBER)を例に、どのように変換されてしまうのか、またどうやって対処すればいいのかをご紹介します。

 

DMS で NUMBER はどう変換されるのか

DMS で RDS Oracle へ移行した後によく気になるのは、数値が NUMBER(38,10) データ型になってしまうパターンでしょうか。これはトラブルシューティングドキュメントの「NUMBER のデータ型が誤って解釈される」に書かれています。
docs.aws.amazon.com

例えば、移行元は NUMBER なのに、移行先では NUMBER(38,10) になっている、という感じです。なんで勝手に精度とスケールの数値がつくんだよ!って最初は思いました。

実際にテストしてみました。↓は移行元のテーブルです。

SQL> desc tbl1;
 Name                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 COL1                           NUMBER
 COL2                           VARCHAR2(100)

↓は移行先のテーブルです。

SQL> desc tbl1;
 Name                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 COL1                           NUMBER(38,10)
 COL2                           VARCHAR2(100)

 

そもそもなんでそんな風に変換されるのか

DMS を使うとどのデータ型がどのように変換されるのか、それはドキュメントに記載があります。

移行元のデータ型と DMS データ型のマッピング
docs.aws.amazon.com

DMS データ型と移行先のデータ型のマッピング
docs.aws.amazon.com

まず今回の例でいくと、移行元の NUMBER は精度もスケールも指定されていないので、Oracle 公式ドキュメントによると精度38、スケール0になるようです (NUMBER(38) ってことですね) 。
Oracleデータ型

続いて、移行元のデータ型と DMS データ型のマッピングをみると、「精度がスケール以上の場合、NUMERIC を使用します。」とありますので、DMS では NUMERIC になります。

さらに、DMS データ型と移行先のデータ型のマッピングをみると、DMS の NUMERIC は 移行先 RDS Oracle では NUMBER (p,s) になることになっています。精度とスケールは書かれていませんね?
そして最後にみるのが、下の追加属性の項目です。NUMBER の精度とスケールのデフォルト値が書かれています。

DMS での追加の接続属性の使用
docs.aws.amazon.com

Number スケールを指定します。最大 38 のスケールを選択するか、FLOAT を選択できます。デフォルトでは、NUMBER データ型が精度 38、スケール 10 に変換されます。

なるほど、だから移行元の NUMBER は、移行先では NUMBER(38,10) になってしまうんですね。

 

これは困る!どうやって同じ型にすればいいのか?

今回の例では、DMS での追加の接続属性の使用のドキュメントの通り、DMS の移行元のエンドポイント設定で、追加の接続属性に numberDataTypeScale=0 を追記すれば OK です。

まず、DMS エンドポイント設定で、移行元のエンドポイントを選択して変更ボタンを押します。
f:id:nasrinjp1:20171002232238p:plain

アドバンストの箇所を開くと、追加の接続属性の欄があるので、下図のように追記します。 f:id:nasrinjp1:20171002232143p:plain

この後、再度移行タスクを実行すると、移行先のデータ型は下記の通り NUMBER(38) になります。

SQL> desc tbl1;
 Name                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 COL1                           NUMBER(38)
 COL2                           VARCHAR2(100)

 

データ型のマッピングAWS ドキュメントで確認すれば、どのデータ型がどのように変換されるのかがわかるので、うまくいかなかった時はもう一度読み返してみましょう。きちんとたどればきっと何かわかりますよ。

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

ナスです。

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

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

 

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

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

 

タスク設定

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

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

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

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

 

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

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

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

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

ここまで設定したら、タスク設定ではこのように見えているはずです。
f:id:nasrinjp1:20170908001438p:plain

 

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

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

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

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