この記事は、Data Platform for Microsoft Azure Advent Calendar 2021のための記事となります。
本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。
はじめに
SQL Server Express とは？
SQL Server には Express と Developer という２つの無償で利用可能なエディションがあります。なかでも、Express は、小規模で機能や容量の制限があるものの、現場主体でAccessのVBAアプリなんかを使っていたお客さんのマルチユーザー化に伴う規模拡大（それでも小さい）なんて用途でよく利用されています。
SQL Server 2019 Express は、デスクトップ、Web、小規模サーバー向けのアプリケーションの開発と運用に最適な、SQL Server の無料エディションです。
引用元：オンプレミスまたはクラウドで SQL Server をお試しください
Express Edition はエントリレベルの無料のデータベースで、学習や、デスクトップおよび小規模サーバー データ ドリブン アプリケーションの構築などに適しています。 このエディションは、独立系ソフトウェア ベンダー、開発者、クライアント アプリケーションを趣味で開発する開発者などに最適です。 さらに高度なデータベース機能が必要な場合には、 SQL Server Express を SQL Serverの他の上位バージョンにシームレスにアップグレードできます。 SQL Server Express LocalDB は、Express の簡易バージョンです。Express のプログラミング機能をすべて備えており、ユーザー モードで実行され、前提条件が少なく構成不要の高速インストールが可能です。
引用元：SQL Server 2019 (15.x)の各エディションとサポートされる機能
違いについてやダウンロードは参考リンクをご覧ください。
SQL Server Express を Azure SQL Database 移行するモチベーション
普通にOS上にインストールされて構築された SQL Server と PaaS である Azure SQL Database にはまず、クラウドにおける共同責任で書かれているようにユーザー側が管理する部分が全く異なるというのが大きな違いとなります。さらに、Azure SQL Database はどのサービスを使用しても、必ず4ノードクラスタ構成をとるので、可用性、冗長性においてかなりのアドバンテージがあります。__手塩にかけてサーバのお世話がしたい__というモチベーションが無い限り、一般的にはPaaSでのおまかせ運用のほうがメリットがあります。
データ移行のながれ
DMA によるアセスメント
DMA (Data Migration Assistant) はSQL Serverをバージョンアップしたり、Azure SQL Database や SQL Managed Instance との互換性上問題になりうる項目をアセスメントするツールです。詳細は Data Migration Assistant の概要をご覧ください。
今回のアセスメント結果はこんな感じ。Trace flag って機能がSQL Databaseでは対応してないよって言われてます。
互換性レベルの違いは特に問題なし。なので、なんの修正もせずに移行しちゃいます。
移行用 DMS （Azure Database Migration Service) のセットアップ
DMS（Azure Database Migration Service) は、Azure へのデータベースの移行を容易にするツールです。今回は__規模が小さい__ので、無償提供されている__Standardで充分__だと判断しました。
- サービスだけ先につくっておきます。残りのプロジェクト、アクティビティは移行元先をセットアップしてから作成します。
検証のながれ
今回の作業では、本番環境を想定してすべて仮想ネットワークに閉じた構成で実施しました。仮想マシンの存在する仮想ネットワークに PaaS である SQL Database と DMS をプライベートエンドポイント構成でつなぐだけです。
実環境であれば、この仮想ネットワークに対して企業のオフィスなどからVPNを張ったり、Express Routeを張るような形でセキュアにアクセスすればいいと思います。
Express Edition の準備
- Azure 上の仮想マシンに適当にインストールします。Express Edition をインストールしたマシン以外からアクセスするためにはちょっとした設定が必要です。docs に明記されていますのでご覧ください。
- Windows Firewall と Network Security Group のポートの確認もお忘れなく。
- Adventure Works をリストア。バックアップファイルは適当にOLTPあたりのものを使用。
SQL Database の準備
- Serverless で作成します。論理サーバのネットワーク構成でプライベートエンドポイント以外設定しません。
- なぜ Serverless かというと、ずっと稼働している必要が無いからです。不要な時にストップしてくれるほうがコスト的に大満足。
DMS のプロジェクト、アクティビティ準備
ネットワーク構成さえできれば、基本的にウィザードポチポチで設定できてしまいます。ポイントだけスクリーンショット貼っておきます
既存のVNET選択
出来上がったらプロジェクトをつくります
このあたりもウィザードで選択していくだけですが、自分が迷ったのは SQL Server のインストールされたVMのホスト名の名前解決がDMSからはできなかったので、IPアドレス直打ちで対処しました。
お客様環境ではDNSフォワーダなどで名前解決の仕組み実装してると思いますので、この場では暫定対応を行いました。
Windows 認証でサーバー証明書を信頼するにチェックボックスを入れるとうまくいきました
プロジェクトのできあがり。
アクティビティの作成と実行
さて、プロジェクトができたのでアクティビティ（活動？）を作成します。
DMSではスキーマのみもしくはデータ移行かいずれかを選択することができます。
移行先にテーブルつくってない場合はスキーマをまず移行しましょう。
ウィザードポチポチで（略）
警告つきで完了です。
警告はこんな感じ。内容によっては対処してください。
データの移行をはじめます。
ウィザードにしたがって（略）とできます。
本番だとソースを読み取りのみにして移行→切替ってこともできるのですが、今回はこのまま突っ走ります。
ターゲットデータベース、黒くてわかりにくいのですがプルダウンになってるのでSQL Database側のデータベースを選択します。
スキャンするのにちょっと時間かかって…こういう感じ
対象のテーブルを選択して
途中経過。
さて、これで移行できました。通常の SQL Server から PaaS 構成に移行することで、よりアプリケーションやデータそのものに集中できますね！
それでは素敵なクリスマスをお迎えください。