移行ガイド: SQL Server から Azure SQL Managed Instance へ

  • [アーティクル]

適用対象:Azure SQL Managed Instance

このガイドに従って、SQL Server データベースを Azure SQL Managed Instance に移行します。

オンプレミスまたは次で実行されている SQL Server を移行できます。

  • SQL Server on Virtual Machines
  • Amazon EC2 (Elastic Compute Cloud)
  • SQL Server 用 Amazon RDS (Relational Database Service)
  • Google Compute Engine
  • Cloud SQL for SQL Server - GCP (Google Cloud Platform)

移行の詳細については、移行の概要に関するページを参照してください。 その他の移行ガイドについては、データベースの移行に関するページを参照してください。

Migration process flow

前提条件

SQL Server を Azure SQL Managed Instance に移行するには、以下を完了していることを確認します。

移行前

ソース環境がサポートされていることを確認した後、移行前ステージから開始します。 既存のデータ ソースをすべて検出し、移行が可能かどうかを評価し、移行の阻害要素となる可能性のある問題を特定します。

発見

検出フェーズでは、ネットワークをスキャンして、組織で使用されているすべての SQL Server インスタンスと機能を特定します。

Azure Migrate を使用して、オンプレミス サーバーの移行の適合性を評価し、パフォーマンスに基づくサイズ変更を行い、Azure でそれらのサーバーを実行するためのコストを見積もります。

または、Microsoft Assessment and Planning Toolkit  ("MAP Toolkit") を使用して、現在の IT インフラストラクチャを評価します。 ツールキットには、移行計画のプロセスを簡略化するための強力なインベントリ、評価、およびレポート ツールが用意されています。

検出フェーズで使用できるツールの詳細については、「データ移行のシナリオで利用できるサービスとツール」を参照してください。

データ ソースが検出された後、Azure SQL Managed Instance に移行できるオンプレミスの SQL Server インスタンスを評価して、移行の阻害要素や互換性の問題を特定します。 次の手順に進んで、データベースを評価し、Azure SQL Managed Instance に移行します。

Steps for migration to Azure SQL Managed Instance

評価

Note

VMware 上の SQL Server データ資産全体を大規模に評価している場合は、Azure Migrate を使用して、Azure SQL デプロイに関する推奨事項、ターゲットのサイズ設定、月単位の見積もりを取得します。

SQL Managed Instance がアプリケーションのデータベース要件に適合しているかどうかを確認します。 SQL Managed Instance は、SQL Server を使用する既存のアプリケーションの大部分について簡単なリフト アンド シフト移行を提供するように設計されています。 ただし、まだサポートされていない機能が必要で、回避策を実装するコストが高すぎる場合があります。

Azure Data Studio 用の Azure SQL Azure SQL Migration 拡張機能は、評価を実行し、Azure レコメンデーションを取得して、オンプレミスの SQL Server データベースを Azure Virtual Machines 上の SQL Server に移行する、ウィザード ベースのシームレスなエクスペリエンスを提供します。 移行の阻害要因や警告を強調表示する以外にも、拡張機能にはデータベースのパフォーマンス データを収集するための Azure レコメンデーションのオプションも含まれていて、ワークロードのパフォーマンス ニーズを (最小価格で) 満たす適切なサイズの Azure SQL Managed Instance を推奨します。

Azure Data Studio の Azure SQL Migration 拡張機能を使用して、データベースを評価し、次の情報を取得できます。

Azure SQL Migration 拡張機能を使用してご自分の環境を評価するには、次の手順に従います。

  1. Azure Data Studio 用の Azure SQL Migration 拡張機能を開きます。
  2. 移行元の SQL Server インスタンスに接続します
  3. Azure Data Studio の Azure SQL Migration ウィザードで、[Azure SQL に移行] ボタンをクリックします
  4. 評価用のデータベースを選択し、[次へ] をクリックします
  5. 移行先の Azure SQL を選択します (この場合はAzure SQL Managed Instance)
  6. [表示/選択] をクリックして評価レポートを確認します
  7. 移行のブロックと機能パリティの問題を探します。 評価レポートはファイルにエクスポートすることもできます。このファイルを、組織内の他のチームや担当者と共有できます。
  8. 移行後の作業が最小限になるようなデータベース互換レベルを特定します。

Azure SQL Migration 拡張機能を使用して Azure の推奨事項を取得するには、次の手順に従います。

  1. Azure Data Studio 用の Azure SQL Migration 拡張機能を開きます。
  2. 移行元の SQL Server インスタンスに接続します
  3. Azure Data Studio の Azure SQL Migration ウィザードで、[Azure SQL に移行] ボタンをクリックします
  4. 評価用のデータベースを選択し、[次へ] をクリックします
  5. 移行先の Azure SQL を選択します (この場合はAzure SQL Managed Instance)
  6. [Azure の推奨事項] セクションに移動し、[Azure の推奨事項を取得する] をクリックします
  7. [Collect performance data now] (今すぐパフォーマンス データを収集する) を選択します。 パフォーマンス ログの格納先となるローカル コンピューター上のフォルダーを選択し、[Start] (開始) を選択します。
  8. 10 分後、Azure SQL Managed Instance のレコメンデーションが利用可能になった旨が Azure Data Studio から伝えられます。
  9. 移行先の Azure SQL パネルで Azure SQL Managed Instance カードを確認し、Azure SQL Managed Instance SKU の推奨事項を確認します

詳細については、Azure Data Studio を使用して SQL Server を Azure SQL Managed Instance にオンラインで移行する方法のチュートリアルに関するページを参照してください。

詳細については、Azure Data Studio を使用して SQL Server を Azure SQL Managed Instance にオフラインで移行する方法のチュートリアルに関するページを参照してください。

データベースが Azure SQL Managed Instance に対して準備が整っていないことを示す複数の阻害要素が評価で検出された場合は、代わりに次のことを検討します。

スケーリングされた評価と分析

Azure Data Studio の Azure SQL Migration 拡張機能 と Azure Migrate では、スケーリングされた評価の実行と分析のための評価レポートの統合がサポートされています。

複数のサーバーとデータベースがあり、それらを大規模に評価および分析して、データ資産を広範囲に確認する必要がある場合は、以下のリンクを参照して詳細を確認してください。

重要

複数のデータベースの大規模な評価は、DMA のコマンド ライン ユーティリティを使用して自動化することもできます。また、Azure Migrate に結果をアップロードして、さらに分析を行うことや、ターゲットの準備を行うこともできます。

最適なサイズに設定されたマネージド インスタンスにデプロイする

Azure Data Studio 用の Azure SQL Migration 拡張機能を使用して、適切なサイズの Azure SQL Managed Instance のレコメンデーションを取得できます。 この拡張機能を使用すると、ソース SQL Server インスタンスからパフォーマンス データが収集され、最小限のコストでワークロードのパフォーマンス ニーズを満たす適切なサイズの Azure レコメンデーションが提供されます。 詳細については、「オンプレミスの SQL Server データベースに適したサイズの Azure レコメンデーションを取得する」を参照してください

検出および評価フェーズの情報に基づいて、適切なサイズのターゲット SQL Managed Instance を作成します。 これを行うには、Azure portal、PowerShell、または Azure Resource Manager (ARM) テンプレートを使用します。

SQL Managed Instance は、クラウドへの移行を予定しているオンプレミスのワークロード向けに調整されます。 ワークロードのリソースの適切なレベルの選択において高い柔軟性を発揮する購入モデルが導入されます。 オンプレミスの世界では、物理コアと IO 帯域幅を使用して、これらのワークロードのサイズを設定することがおそらく一般的です。 マネージド インスタンスの購入モデルは仮想コア ("vCore") に基づいており、追加のストレージと IO を個別に使用できます。 仮想コア モデルは、クラウドのコンピューティング要件と現在オンプレミスで使用しているものを把握するためのシンプルな方法です。 この購入モデルにより、クラウド内の移行先環境を適切にサイズ設定することができます。 適切なサービス レベルと特性を選択するために役立ついくつかの一般的なガイドラインを次に示します。

  • ベースラインの CPU 使用率に基づいて、SQL Server で使っているコアの数と一致するマネージド インスタンスをプロビジョニングできます。そのとき、マネージド インスタンスがインストールされている VM の特性と一致するように CPU の特性をスケーリングすることが必要になる場合があることに留意します。
  • ベースラインのメモリ使用量に基づいて、対応するメモリを備えたサービス レベルを選択します。 メモリの量は直接選択できないため、一致するメモリ (Standard シリーズ (Gen5) の 5.1 GB/仮想コアなど) を備えた仮想コアの容量を持つマネージド インスタンスを選択する必要があります。
  • ファイル サブシステムのベースライン IO 待機時間に基づいて、General Purpose (5 ミリ秒を超える待機時間) と Business Critical (3 ミリ秒未満の待機時間) のサービス レベルのいずれかを選択します。
  • 予期される IO パフォーマンスを得るために、ベースラインのスループットに基づいて、データ ファイルまたはログ ファイルのサイズを事前に割り当てます。

コンピューティング リソースとストレージ リソースをデプロイ時に選択し、後で Azure portal を使用してアプリケーションのダウンタイムなしに変更できます。

Managed Instance Sizing

VNet インフラストラクチャとマネージド インスタンスを作成する方法については、マネージド インスタンスの作成に関するページを参照してください。

重要

移行先の VNet とサブネットがマネージド インスタンスの VNet 要件に従っているようにすることが重要です。 非互換性があると、新しいインスタンスの作成や、既に作成したインスタンスの使用ができなくなることがあります。 詳しくは、ネットワークの新規作成と既存のネットワークの構成に関する記事をご覧ください。

移行

移行前ステージの関連タスクを完了したら、スキーマとデータの移行を実行する準備は完了です。

選択した移行方法を使用してデータを移行します。

SQL Managed Instance のターゲットは、オンプレミスまたは Azure VM データベース実装からのデータベースの一括移行を必要とするユーザー シナリオです。 これらは、インスタンス レベルの機能や複数データベース間の機能を定期的に使用するアプリケーションのバックエンドのリフト アンド シフトが必要な場合に最適な選択肢です。 このシナリオに該当する場合は、アプリケーションを再設計する必要なしに Azure 内の対応する環境にインスタンスを移行できます。

SQL インスタンスを移行するには、以下を慎重に計画する必要があります。

  • 併置する必要のある (同じインスタンスで実行されている) すべてのデータベースの移行。
  • ログイン、資格情報、SQL エージェント ジョブと演算子、サーバー レベルのトリガーなど、アプリケーションが依存するインスタンス レベルのオブジェクトの移行。

SQL Managed Instance は、通常の DBA アクティビティの一部を組み込み時にユーザーがプラットフォームに委任できるマネージド サービスです。 したがって、高可用性が組み込まれているため、定期的なバックアップや Always On 構成のメンテナンス ジョブなど、いくつかのインスタンス レベルのデータは移行する必要がありません。

この記事では、推奨される移行オプションのうち 2 つについて説明します。

  • Azure Data Studio 用の Azure SQL Migration 拡張機能 - ダウンタイムがほぼゼロの移行。
  • ネイティブな RESTORE DATABASE FROM URL - SQL Server のネイティブ バックアップを使用し、ある程度のダウンタイムが必要。

このガイドでは、2 つの最も一般的な方法、つまり Azure Database Migration Service (DMS) およびネイティブのバックアップと復元について説明します。

その他の移行ツールについては、「移行オプションを比較する」を参照してください。

Azure Data Studio 用の Azure SQL Migration 拡張機能を使用して移行する (最小限のダウンタイム)

Azure Data Studio を使用して最小限のダウンタイムでの移行を実行するには、次に示す大まかな手順に従います。 詳細なステップバイステップのチュートリアルについては、「Azure Data Studio を使用して SQL Server を Azure SQL Managed Instance にオンラインで移行する」を参照してください。

  1. Azure Data Studio と Azure SQL Migration 拡張機能をダウンロードしてインストールします。
  2. Azure Data Studio の拡張機能で Azure SQL Migration ウィザードを起動します。
  3. 評価用のデータベースを選択し、移行の準備状況または問題 (存在する場合) を表示します。 さらに、パフォーマンス データを収集し、適切なサイズの Azure レコメンデーションを取得します。
  4. サブスクリプションから Azure アカウントとターゲットの Azure SQL Managed Instance を選択します。
  5. データベース バックアップの場所を選択します。 データベース バックアップは、オンプレミスのネットワーク共有または Azure Blob Storage コンテナーに置くことができます。
  6. Azure Data Studio のウィザードを使用して、新しい Azure Database Migration Service を作成します。 Azure Data Studio を使用して以前に Azure Database Migration Service を作成したことがある場合は、必要に応じてそれを再利用できます。
  7. 省略可能: バックアップがオンプレミスのネットワーク共有上にある場合は、ソース SQL Server に接続できるマシンと、バックアップ ファイルを含む場所にセルフホステッド統合ランタイムをダウンロードしてインストールします。
  8. データベースの移行を開始し、Azure Data Studio での進行状況を監視します。 Azure portal の Azure Database Migration Service リソースで進行状況を監視することもできます。
  9. 一括移行を完了します。
    1. ソース データベースに送信されるすべてのトランザクションを停止します。
    2. アプリケーション構成を変更し、Azure SQL Managed Instance 上のターゲット データベースをポイントするようにします。
    3. 指定されたバックアップ場所で、ソース データベースのログ末尾のバックアップを行います。
    4. 監視の詳細パッケージで、すべてのデータベース バックアップの状態が [復元された] になっていることを確認します。
    5. 監視の詳細ページで [一括を完了する] を選択します。

バックアップと復元

短時間で簡単にデータベースを移行できるようにするための Azure SQL Managed Instance の主な機能の 1 つは、Azure Storage に格納されているデータベース バックアップ (.bak) ファイルのネイティブ復元です。 バックアップと復元は、データベースのサイズに基づく非同期操作です。

次の図は、プロセスの概要を示しています。

Diagram shows SQL Server with an arrow labeled BACKUP / Upload to URL flowing to Azure Storage and a second arrow labeled RESTORE from URL flowing from Azure Storage to a SQL Managed Instance.

Note

バックアップを作成し、それを Azure Storage にアップロードする時間、および Azure SQL Managed Instance に対してネイティブの復元操作を実行する時間は、データベースのサイズによって異なります。 大規模なデータベースの操作に対応するために、十分なダウンタイムを考慮してください。

次の表は、実行しているソース SQL Server のバージョンに応じて使用できる方法に関する詳細情報を示しています。

手順 SQL エンジンとバージョン バックアップ/復元方法
Azure Storage へのバックアップの格納 2012 SP1 CU2 より前 Azure Storage に .bak ファイルを直接アップロードする
2012 SP1 CU2 - 2016 非推奨の WITH CREDENTIAL 構文を使用して直接バックアップする
2016 以上 WITH SAS CREDENTIAL を使用して直接バックアップする
Azure Storage からマネージド インスタンスに復元する SAS 資格情報での URL からの復元

重要

  • ネイティブ復元オプションを使用して、Transparent Data Encryption によって保護されたデータベースをマネージド インスタンスに移行する場合は、データベースの復元の前に、オンプレミスまたは Azure VM SQL Server の対応する証明書を移行する必要があります。 詳細な手順については、TDE 証明書のマネージド インスタンスへの移行に関するページを参照してください。
  • システム データベースの復元はサポートされていません。 (master または msdb データベースに格納されている) インスタンス レベルのオブジェクトを移行するには、それらのスクリプトを作成し、移行先のインスタンスで T-SQL スクリプトを実行することをお勧めします。

バックアップと復元を使用して移行するには、次の手順に従います。

  1. データベースを Azure Blob Storage にバックアップします。 たとえば、SQL Server Management Studio で [backup to url](URL へのバックアップ) を使用します。 Microsoft Azure Tool を使用して、SQL Server 2012 SP1 CU2 より前のデータベースをサポートします。

  2. SQL Server Management Studio を使用して Azure SQL Managed Instance に接続します。

  3. データベース バックアップがある Azure Blob Storage のアカウントにアクセスするために、Shared Access Signature を使用して資格情報を作成します。 次に例を示します。

    CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE'
, SECRET = 'sv=2017-11-09&ss=bfqt&srt=sco&sp=rwdlacup&se=2028-09-06T02:52:55Z&st=2018-09-04T18:52:55Z&spr=https&sig=WOTiM%2FS4GVF%2FEEs9DGQR9Im0W%2BwndxW2CQ7%2B5fHd7Is%3D'

  4. Azure Storage Blob コンテナー内のバックアップを復元します。 次に例を示します。

    RESTORE DATABASE [TargetDatabaseName] FROM URL =
  'https://mitutorials.blob.core.windows.net/databases/WideWorldImporters-Standard.bak'

  5. 復元が完了したら、SQL Server Management Studio 内のオブジェクト エクスプローラーでデータベースを確認します。

この移行オプションの詳細については、「SSMS を使用して Azure SQL Managed Instance にデータベースを復元する」を参照してください。

Note

データベースの復元操作は非同期であり、再試行できます。 接続が切断されるか、タイムアウトが発生した場合に、SQL Server Management Studio にエラーが生じる可能性があります。 Azure SQL Database では、バックグラウンドでのデータベースの復元を試行し続けます。sys.dm_exec_requests および sys.dm_operation_status ビューを使用して、復元の進行状況を追跡できます。

データの同期と切り替え

データの変更をソースからターゲットに継続的にレプリケートおよび同期する移行オプションを使用している場合、ソースのデータとスキーマが変更され、ターゲットと食い違う可能性があります。 データの同期中にソースのすべての変更がキャプチャされ、移行プロセス中にターゲットに適用されるようにしてください。

ソースとターゲットの両方でデータが同じであることを確認した後、ソース環境からターゲット環境に切り替えることができます。 切り替え中の最小限の中断によってもビジネス継続性に影響が出ないようにするために、ビジネス チームやアプリケーション チームと共に切り替えプロセスを計画することが重要です。

重要

DMS を使用した移行の一環として切り替えを実行する場合、それに関連する特定の手順について詳しくは、移行カットオーバーの実行に関するページを参照してください。

移行後

移行ステージが正常に完了した後、移行後の一連のタスクを実行し、すべてが円滑かつ効率的に機能することを確認します。

移行後の段階は、発生したデータの精度の問題を調整したり、完全性を検証したり、ワークロードでのパフォーマンスの問題に対処したりするために非常に重要です。

アプリケーションの監視と修復

マネージド インスタンスへの移行を完了した後は、アプリケーションの動作とワークロードのパフォーマンスを追跡する必要があります。 このプロセスには、次のアクティビティが含まれます。

テストを実行する

データベース移行のテストア プローチは、次のアクティビティで構成されています。

  1. 検証テストを作成する: データベースの移行をテストするには、SQL クエリを使用する必要があります。 ソース データベースとターゲット データベースの両方に対して実行する検証クエリを作成する必要があります。 その検証クエリでは、定義されているスコープに対応する必要があります。
  2. テスト環境を設定する: テスト環境には、ソース データベースとターゲット データベースのコピーが含まれている必要があります。 必ずテスト環境を分離してください。
  3. 検証テストを実行する: ソースとターゲットに対して検証テストを実行してから、結果を分析します。
  4. パフォーマンス テストを実行する: ソースとターゲットに対してパフォーマンス テストを実行し、結果を分析して比較します。

高度な機能を使用する

SQL Managed Instance によって提供されるクラウドベースの高度な機能を活用できます。たとえば、組み込みの高可用性、脅威検出、ワークロードの監視と調整などです。

Azure SQL Analytics を使用すると、多数のマネージド インスタンスを一元的な方法で監視できます。

SQL Server の一部の機能は、データベース互換レベルを最新の互換性レベル (150) に変更した場合にのみ使用できます。

次のステップ