データベースのAzureSQLデータベースへの移行

時間の経過とともに、オンプレミスでSQL Serverを実行するための高コストの代わりに、Azure SQL Databaseに移行するか、少なくとも評価する企業が増えています。

互換性の確認

データベースをAzureSQLDatabaseに移行する最初の側面の1つは、互換性を確認することです。Microsoftは、多数のデータベースを提供しています。 Azure SQL Database V12（以降、単に「V12」と呼びます）でこれを行う方法。これらの方法の1つは、最新の互換性ルールを使用してV12の非互換性を検出するSQL Server Data Tools for Visual Studio（SSDT）を使用することです。 SSDTでは、データベーススキーマをインポートして、V12展開用のプロジェクトを構築できます。非互換性が見つかった場合は、SSDT内で修正してから、ソースデータベースに同期して戻すことができます。

互換性の問題のレポートを生成できるSqlPackageと呼ばれるコマンドラインツールを使用することもできます（常に最新バージョンであることを確認してください）。 SQL Server Management Studioは、エラーを検出して画面に報告できるデータ層アプリケーションのエクスポート機能を使用する別の方法です。エラーが検出されない場合は、データベースをV12に移行できます。非互換性が検出された場合は、移行前にSSMSを使用して修正できます。

Data Migration Assistantは、アップグレードの労力を軽減するために使用できるスタンドアロンツール（SQL Server Migration Assistantと簡単に混同されます）であり、SQL Server 2016 UpgradeAdvisorPreviewに代わるものです。 DMAは、パフォーマンスと信頼性の向上を推奨することもできます。もう1つのツールであるSQLAzureMigration Wizard（SAMW）は、Azure SQLDatabaseV11互換性ルールを使用してV12の非互換性を検出するCodeplexツールです。 SAMWは、V12への移行を完了し、いくつかの互換性の問題を修正することもできます。 SAMWを使用する際に注意すべき点は、修正する必要のない非互換性を検出できることです。

データの移行

データベースが互換性チェックに合格したら、移行するのに最適な方法を決定する必要があります。より一般的な方法には、SSMS移行ウィザードの使用、BACPACへのエクスポート、トランザクションレプリケーションの使用、データベースの手動スクリプト作成とデータの挿入などがあります。

SSMS移行ウィザードの使用は、小規模から中規模のSQLServer2005以降のデータベースに最適です。 SSMS 2016でこのウィザードをアクティブにするには、データベースを右クリックし、[タスク]を選択して、[データベースをMicrosoftAzureSQLデータベースに展開する]を選択します。 SSMS 2014では、データベースをWindowsAzureSQLデータベースにデプロイすることと呼ばれています。このウィザードを使用すると、移行するデータベースを指定し、Azureサブスクリプションに接続し、.bacpacファイルの場所、新しいデータベース名、および移行先の層を選択できます。 [完了]をクリックすると、ウィザードはスキーマを抽出して検証し、データをエクスポートします。データがエクスポートされると、展開計画が作成され、新しいV12データベースへのデータのインポートが開始されます。

SSMS移行ウィザードと非常によく似ているのは、データ層のエクスポートアプリケーションです。このオプションを選択するには、データベースを右クリックし、[タスク]、[データ層アプリケーションのエクスポート]の順に選択します。エクスポート設定で、.bacpacファイルを作成する場所を指定します。これをローカルに保存することも、Azureストレージアカウントに直接保存することもできます。含めるテーブルを選択できる詳細タブもあります。これは、ローカルデータベースにV12に移行したくないテーブルのコピーが含まれている場合に役立ちます。 [完了]を選択すると、データがエクスポートされます。次に、SSMSを介してAzureサーバーに接続し、データ層アプリケーションのインポートを選択できます。ファイルの場所、データベース名、およびAzureSQLデータベースの階層を指定します。 [完了]を選択すると、データベースのインポートが開始されます。この方法では、エクスポートとインポートが分離されるため、プロセスを少し細かく制御できます。また、.bacpacファイルをAzureストレージアカウントに保存するオプションも提供されるため、より脆弱なインポートプロセスがインターネット接続に依存することはありません。

SSMS移行ウィザードまたはデータ層アプリケーションのエクスポートを使用する場合のオプションは、SQLServerを使用してAzureVMを作成し、ログ配布を設定することです。これにより、データベースをAzureクラウドで事前にステージングして、データベースのインポート時間を最小限に抑えることができます。移行を行うときは、セカンダリで最終的なログバックアップを復元してから、ログ配布を削除するだけです。データベースをオンラインにするには、リカバリを使用して復元を実行します。これにより、データベースをデータセンターからAzureデータセンターにコピーするのにかかる時間が実質的になくなります。

トランザクションレプリケーションは、V12への移行のダウンタイムを削減するのに役立つもう1つの方法です。データベースがトランザクションレプリケーションをサポートできる場合、V12に切り替えるためのメンテナンスウィンドウが非常に小さい場合に最適なオプションです。トランザクションレプリケーションを設定するには、公開されたテーブルごとに主キーが必要です。これは、多くのデータベースで問題になる可能性があります。ディストリビューションデータベースを設定し、パブリッシャーとサブスクライバーを設定し、ジョブを監視する必要があるため、トランザクションレプリケーションの構成も複雑になる可能性があります。

スクリプトの生成ウィザードを使用してデータベーススキーマやデータをスクリプト化することにより、手動で移行することもできます。次に、スクリプトを実行して、Azureで空のデータベースを作成し、スキーマやデータをインポートできます。この方法を使用して空のデータベースを作成し、SSMSとリンクサーバーを使用して一度に1つのテーブルにデータを手動で挿入する人がいると聞いています。この方法はうまくいくかもしれませんが、外部キー関係やID列などのスキーマ構造がたくさんある場合は非常に複雑になる可能性があります。その場合、上記の他の方法の方が信頼性が高く効率的です。

その他の移行に関する考慮事項

オンプレミスデータベースをV12に移行することを計画している場合、データベースのサイズは、移行にかかる時間の大きな要因です。データベースのエクスポート、データの転送、およびインポートはすべて、データベースのサイズに比例して増加します。

データベースをV12に移動するときの復元/インポート時間のもう1つの大きな要因は、復元するパフォーマンス層でもあります。復元/インポートプロセスには多くの馬力が必要になるため、移行を迅速化するために、より高いパフォーマンス層への復元を検討する必要があります。データベースがオンラインの場合、毎日のパフォーマンスのニーズを満たす下位層に簡単かつ迅速にドロップダウンできます。マウスを数回クリックするだけでパフォーマンス階層を変更できることは、AzureSQLDatabaseの大きな利点の1つです。

監視

データベース管理の重要な部分は監視です。何かを監視していない場合、それを測定することはできません。正常に動作しているときにメトリックが何であるかがわからない場合、パフォーマンスが低下したときにどのメトリックが悪化するかをどのように知ることができますか？オンプレミスデータベースには、SQL Server Management Studio、パフォーマンスモニター、タスクマネージャー、DMVなどの使い慣れたツールがあります。データベースをV12に移行すると、OSの観点から監視する機能が失われ、他の概念も少し変わります。これで、データベーストランザクションユニットを表すDTUと呼ばれるこのメトリックを使用できるようになりました。 CPU、データとトランザクションログのI / O、およびメモリの組み合わせと考えてください。 Azure Portalには、デフォルトでDTUパーセンテージがチェックされている監視グラフが含まれており、このグラフを編集して、次のような追加の指標を含めることができます。

ファイアウォールによってブロックされています
CPU％
DTU制限
使用されたDTU
データI/O％

データベースサイズ％
デッドロック
接続の失敗
インメモリOLTPストレージ％ （プレビュー）

ログI/O％
セッション％
接続の成功
データベースの合計サイズ
労働者％

少なくとも、CPUパーセンテージ、データI / Oパーセンテージ、デッドロック、およびデータベースサイズパーセンテージを追加します。現在、このグラフには過去1時間のリソース使用率が表示されています。

DMVによる監視は、個々のデータベースメトリックとデータベースサイズの計算方法に関連するいくつかの新しいDMVがあることを除いて、あまり変わっていません。以前の記事の1つである「AzureSQLデータベースでのパフォーマンスのチューニングの開始」では、AzureSQLデータベースに関連するディスクレイテンシと待機統計の収集に使用される一般的なスクリプトの違いについて説明しています。

DBSentryを備えたSentryOneなどのサードパーティツールもAzureSQLデータベースへのフックを含め始めています。 DB Sentryを使用すると、パフォーマンスを監視し、システムで発生しているイベントを管理できます。優れた機能の1つは、全体的なパフォーマンスに最も影響を与えるクエリを確認できるトップSQL関数です。これにより、そのクエリの問題を調整/修正できます。もう1つは、DTUを時系列でグラフ化し、他の重要なメトリックと一緒にダッシュボードで視覚化することです。

SentryOneクライアントのトップSQL

DBSentryダッシュボードでのDTUの使用

これらのメトリックは専用のデータベースに保存され、ベースラインを設定し、時間の経過とともにパフォーマンスの傾向を把握することができます。これは、現在Azureポータルで取得している限られたグラフよりもはるかに優れています。

概要

データベースに互換性がある場合、Azure SQL Database V12に移行することには多くの利点があります。そのため、利用可能なツールの1つを利用して、V12との互換性を確認してください。データベースに互換性がある場合、または互換性を持たせるために簡単に変更できる場合は、Azure SQL Database V12に簡単に移行して、アプリケーションとワークロードのテストとベンチマークを開始できます。