データ移行ツールいろいろ～SQL Server Migration Assistant（移行編）

古林

2020年03月16日

みなさまこんにちは。クラウドアーキテクトの卵です。

最近、10 年以上使っていた電子レンジがとうとう壊れてしまいました。。。

1 日に最低 2 回は電子レンジを使用するので、新たな電子レンジを求め早速行きつけの家電量販店に行きました。
最近の電子レンジは機能も種類も豊富ですね！どういうものを買おうかを先に調査し、ある程度アタリをつけていたのですが、それでも少し迷ってしまいました。
日頃の使い方を基に、事前に購入ポイントを洗い出しておいて良かったです。（でないと、もっと迷っていたかも）

電子レンジ機能がほとんど。でも、たまにオーブン機能も使う。
→ オーブンレンジ一択
お手入れのラクさを考え、ターンテーブルはナシで。
メニューや温度を選ぶ際は、ボタンではなくダイヤル式（ぐりぐり回せるやつ）がいいな。
以前の電子レンジよりも大きいものがいい。（電子レンジにギリギリ入らなかった！ということを防ぎたい）

今では、我が家で大活躍しております。

＜目次＞

はじめに
SQL Server Migration Assistant の操作（移行編）
おわりに

「Microsoft Azure の導入・構築・運用」に関する資料請求・お問い合わせはこちら

1.はじめに

第 4 回目は、前回に引き続き SQL Server Migration Assistant を紹介します。

今回は SQL Server Migration Assistant を利用して IaaS で立てた Oracle 11g を SQL Database に移行してみます。
（本当はオンプレミス環境として Oracle 11g を立てたかったのですが、手頃な環境がなかったので IaaS にしています）

＜環境構成（おさらい）＞

2.SQL Server Migration Assistant の操作（移行編）

SQL Server Migration Assistant を使って、実際に移行を実施してみましょう！
SQL Server Migration Assistant のダウンロード、インストールについては前回のブログをご覧ください。

【参考：SQL Server Migration Assistant を使った Linux 上の SQL Server 2017 への Oracle スキーマを移行します。】
https://docs.microsoft.com/ja-jp/sql/ssma/oracle/sql-server-linux-convert-from-oracle?view=sql-server-2017

＜移行操作の流れ＞

移行プロジェクトを作成
移行元データベースを選択
移行先データベースを選択
スキーマ変換
データベース同期
データ移行

1.移行プロジェクトを作成

前回のブログの『① アセスメントプロジェクトを作成』と同様の手順となります。
2 ステップで作成できます。

2.移行元データベースを選択

前回のブログの『② アセスメントを実施したいデータベースの指定』と同様の手順となります。
入力値を入力後し、移行元データベースに接続します。接続後、移行したいスキーマにチェックを入れてください。

3.移行先データベースを選択

移行先のデータベースサーバーに接続します。画面上部の「Connect to Azure SQL Database」をクリックし、以下の内容を入力後、「Connect」ボタンをクリックします。
SQL Server Management Studio を使ったことがある人は、馴染みのある画面かもしれません。

※ 移行元データベースと同様、よく分からなくなった場合、SQL Server Management Studio 等の接続情報を確認して、同じものを入れたら OK です。

＜入力値＞

左右にスクロールしてご覧ください。

Server name	移行先データベースのデータベースサーバーを入力。
Database	移行先データベースを選択。
User name	移行先データベースに接続できるユーザーを入力。
Password	ユーザーにひもづくパスワードを入力。

データベースサーバーに接続できた場合、下図の赤枠部分のようにデータベースサーバーにひもづくデータベースが表示されます。

4.スキーマ変換

移行元データベースにある Oracle のスキーマを、移行先データベースである SQL Database に合わせて変換します。
移行元データベースのスキーマを右クリックし、「Convert Schema」をクリックします。
（今回の場合は Oracle の HR スキーマで実行しています。）

「Convert Schema」をクリックしても、下部にログが出るだけで、ここでは何も起きない…ように見せかけて、SQL Database 側にスキーマが表示されています。

5.データベース同期

スキーマ変換を実施しただけでは、まだスキーマ移行は完了していません。
移行先データベース側（SQL Database 側）で移行元データベース側（Oracle 側）と同期することで、スキーマ移行が実施されます。

「④ スキーマ変換」で、移行先データベースに作成されたデータベースを右クリックし、「Synchronize with Database」をクリックします。
（ここでは、HR というデータベースで実行しています。）

「Synchronize with Database」をクリックすると、下図のようなダイアログが表示されます。少し直感的に分かりにくいかもしれませんが、ダイアログの右側「Local Metadata」が Oracle の情報で、ダイアログの左側「Database」が SQL Database の情報になります。

今回、移行先データベース（SQL Database 側）にないスキーマを移行するため、ダイアログの左側は、全て何もない状態 [Not Found] と表示されています。
確認し、「OK」ボタンをクリックします。

「OK」ボタンをクリックすると、スキーマが実際に移行先データベース（SQL Database 側）に作成されます。

これでスキーマ移行が完了しました。移行先データベース側（SQL Database 側）のテーブル情報等も、SQL Server Migration Assistant から確認できるようになりました。

6.データ移行

最後にデータを移行します。
移行元データベースのスキーマを右クリックし、「Migration Data」をクリックします。

移行元データベース（Oracle）、移行先データベース（SQL Database）ともに、もう一度資格情報の入力が必要となります。
移行元データベース（Oracle）、移行先データベース（SQL Database）の順に資格情報を入力すると、データ移行が開始されます。

データ移行が完了すると、下図の赤枠部分に移行結果が表示されます。
今回はデータベース容量が 200 MB 程度でしたので、5 分もかからずに終わりました。

ダイアログにある「Save Report」ボタンをクリックすると、ダイアログの内容を CSV 形式で保存することができます。
CSV の中身は、ダイアログの表と同じです。

3.おわりに

いかがでしたか？アセスメントに続き、SQL Server Migration Assistant を利用した移行についても簡単に実施できることがお分かりいただけたかと思います。

詳細については Microsoft のDocs に記載がありますが、他の Docs と違い機械翻訳となっていますので、少々読みにくい部分があるかもしれません。

【参考：SQL Server Migration Assistant】
https://docs.microsoft.com/ja-jp/sql/ssma/sql-server-migration-assistant?view=sql-server-2017

「他の DB を SQL Database に移行したい」という場合には、前回ご紹介したアセスメントを含めて検討してみてはいかがでしょうか。工数の削減にもつながると思います。