チュートリアル: DMSを使用した Azure Virtual Machines 上の SQL Server にSQL Serverを移行する

  • [アーティクル]

Azure Database Migration Service と Azure Data Studio の Azure SQL Migration 拡張機能を使用すると、SQL Server のオンプレミス インスタンスから Azure Virtual Machines 上の SQL Server (SQL Server 2016 以降) に最小限のダウンタイムでデータベースを移行できます。

一定の手動構成が必要になるデータベースの移行方法については、Azure Virtual Machines 上の SQL Server への SQL Server インスタンスの移行に関する記事を参照してください。

このチュートリアルでは、Azure Data Studio と Azure Database Migration Service を使用して、SQL Server のオンプレミスのインスタンスから Azure Virtual Machine 上の SQL Server に、最小限のダウンタイムで AdventureWorks2022 データベースを移行します。

このチュートリアルでは、移行プロセス中の許容されるダウンタイムを含め、オフラインとオンラインの両方の移行オプションを提供します。

このチュートリアルでは、次の作業を行う方法について説明します。

  • Azure Data Studio で Azure SQL への移行ウィザードを起動します。
  • ソース SQL Server データベースの評価を実行する
  • ソース SQL Server からパフォーマンス データを収集します。
  • ワークロードに最適な Azure Virtual Machine SKU 上の SQL Server の推奨事項を取得する。
  • ソース SQL Server、バックアップ場所、Azure Virtual Machine 上のターゲット SQL Server の詳細を指定します
  • 新しい Azure Database Migration Service を作成し、セルフホステッド統合ランタイムをインストールしてソース サーバーとバックアップにアクセスします。
  • 移行を開始し、その進行状況を監視します。
  • 準備ができたら、移行カットオーバーを実行します。

前提条件

チュートリアルを開始する前に:

  • Azure Data Studio をダウンロードしてインストールします。

  • Azure Data Studio マーケットプレースから Azure SQL Migration 拡張機能をインストールします。

  • 次に示す組み込みロールのいずれかに割り当てられている Azure アカウントを用意します。

    • ターゲット インスタンスである Azure Virtual Machines 上の SQL Server の共同作成者、およびサーバー メッセージ ブロック (SMB) ネットワーク共有からデータベース バックアップ ファイルをアップロードするストレージ アカウントの共同作成者

    • ターゲット インスタンス (Azure Virtual Machines 上の SQL Server) を含む Azure リソース グループの閲覧者ロール、または Azure ストレージ アカウントの閲覧者ロール

    • Azure サブスクリプションの所有者または共同作成者ロール

    いずれかの組み込みロールを使用する代わりに、カスタム ロールを割り当てることもできます。

    重要

    Azure アカウントが必要になるのは、移行手順を構成するときのみです。 Azure Data Studio の移行ウィザードで Azure レコメンデーションを確認したり評価を行ったりする際に、Azure アカウントは必要ありません。

  • ターゲット インスタンスである Azure Virtual Machines 上の SQL Server を作成します。

    重要

    既存の Azure Virtual Machine がある場合、フル管理モードで SQL IaaS Agent 拡張機能に登録する必要があります。

  • ソース SQL Server インスタンスへの接続に使用するログインが sysadmin サーバー ロールのメンバーであること、または CONTROL SERVER アクセス許可を有していることを確認します。

  • 完全データベース バックアップ ファイルと、その後のトランザクション ログ バックアップ ファイルが格納される SMB ネットワーク共有、Azure ストレージ アカウント ファイル共有、または Azure ストレージ アカウント BLOB コンテナーを指定します。 データベースの移行中、このバックアップ場所が Database Migration Service によって使用されます。

    • Azure Data Studio の Azure SQL 移行拡張機能では、データベース バックアップは取得されません。また、ユーザーに代わってデータベース バックアップも開始されません。 その代わりに、このサービスでは、移行に既存のデータベース バックアップ ファイルが使用されます。

    • データベース バックアップ ファイルが SMB ネットワーク共有に存在する場合、Database Migration Service がデータベースのバックアップ ファイルをアップロードしたりデータベースを移行したりする際に使用できる Azure ストレージ アカウントを作成します。 Azure ストレージ アカウントは必ず、Database Migration Service のインスタンス作成先と同じリージョンに作成してください。

    • 各バックアップは、単独のバックアップ ファイルまたは複数のバックアップ ファイルに書き込むことができます。 完全ログとトランザクション ログなど、複数のバックアップを 1 つのバックアップ メディアに追加することはサポートされていません。

    • 大きなバックアップの移行に関連する潜在的な問題が発生する可能性を低減するために、圧縮されたバックアップを提供できます。

  • ソース SQL Server インスタンスを実行しているサービス アカウントに、データベース バックアップ ファイルが格納されている SMB ネットワーク共有に対する読み取りおよび書き込みアクセス許可があることを確認します。

  • Transparent Data Encryption (TDE) によって保護されたデータベースを移行する場合、データの移行前に、ソース SQL Server インスタンスから Azure Virtual Machines 上の SQL Server に証明書を移行しておく必要があります。 詳細については、「別の SQL Server への TDE で保護されたデータベースの移動」を参照してください。

    ヒント

    Always Encrypted で保護されている機密データがデータベースに含まれている場合、移行プロセスでは、ターゲット インスタンスである Azure Virtual Machine 上の SQL Server に Always Encrypted キーが自動的に移行されます。

  • データベース バックアップがネットワーク ファイル共有にある場合は、データベース バックアップにアクセスして移行するためのセルフホステッド統合ランタイムをインストールするコンピューターを用意します。 移行ウィザードでは、セルフホステッド統合ランタイムをダウンロードしてインストールするためのダウンロード リンクと認証キーが提供されます。

    移行の準備として、セルフホステッド統合ランタイムをインストールするコンピューターで、次のアウトバウンド ファイアウォール規則とドメイン名が有効になっていることを確認します。

    ドメイン名 送信ポート 説明
    パブリック クラウド: {datafactory}.{region}.datafactory.azure.net
    または *.frontend.clouddatahub.net

    Azure Government:{datafactory}.{region}.datafactory.azure.us
    21Vianet によって運営される Microsoft Azure:{datafactory}.{region}.datafactory.azure.cn    		 443 セルフホステッド統合ランタイムが Database Migration Service に接続するために必要です。
    パブリック クラウドに新しく作成されたデータ ファクトリの場合、セルフホステッド統合ランタイム キーから、{datafactory}.{region}.datafactory.azure.net 形式の完全修飾ドメイン名 (FQDN) を特定します。
    既存のデータ ファクトリで、セルフホステッド統合キーに FQDN が見つからない場合は、代わりに *.frontend.clouddatahub.net を使用してください。
    download.microsoft.com 443 セルフホステッド統合ランタイムが更新プログラムをダウンロードするために必要です。 自動更新を無効にしている場合は、このドメインの構成をスキップできます。
    .core.windows.net 443 ネットワーク共有からデータベース バックアップをアップロードするために Azure ストレージ アカウントに接続するセルフホステッド統合ランタイムによって使用されます

    ヒント

    データベース バックアップ ファイルが Azure ストレージ アカウントで既に提供されている場合、移行プロセス中にセルフホステッド統合ランタイムは不要です。

  • セルフホステッド統合ランタイムを使用する場合は、ランタイムがインストールされているコンピューターが、ソース SQL Server インスタンスと、バックアップ ファイルがあるネットワーク ファイル共有に接続できることを確認します。

  • アウトバウンド ポート 445 を有効にして、ネットワーク ファイル共有へのアクセスを許可します。 詳細については、セルフホステッド統合ランタイムを使用するうえでの推奨事項に関する記事を参照してください。

  • Azure Database Migration Service を初めて使う場合は、Microsoft.DataMigration リソース プロバイダーがサブスクリプションに登録されていることを確認します。

このチュートリアルでは、SQL Server から Azure Virtual Machine 上の SQL Server へのオフライン移行について説明します。

Azure Data Studio で Azure SQL への移行ウィザードを起動する

Azure SQL への移行ウィザードを起動するには:

  1. Azure Data Studio で [接続] に移動します。 SQL Server のオンプレミス インスタンスを選択して、そこに接続します。 Azure 仮想マシン上の SQL Server に接続することもできます。

  2. サーバー接続を右クリックして [管理] を選択します。

  3. サーバー メニューの [全般] で、[Azure SQL Migration] を選択します。

  4. [Azure SQL の移行] ダッシュボードで、[Azure SQL への移行] を選択して移行ウィザードを起動します。

    Azure SQL への移行ウィザードの起動方法を示すスクリーンショット。

  5. ウィザードの最初のページで、新しいセッションを開始するか、以前に保存したセッションを再開します。

データベースの評価を実行して、パフォーマンス データを収集し、Azure のレコメンデーションを取得する

  1. Azure SQL への移行ウィザードの [Step 1: Databases for assessment] (ステップ 1: 評価対象のデータベース) で、評価するデータベースを選択します。 次に、 [次へ] を選択します。

  2. [Step 2: Assessment results and recommendations] (ステップ 2: 評価の結果とレコメンデーション) で、次の手順を実行します。

    1. [Choose your Azure SQL target] (Azure SQL ターゲットを選択してください) で、[SQL Server on Azure Virtual Machine] (Azure Virtual Machines 上の SQL Server) を選択します。

      評価の確認を示すスクリーンショット。

    2. [View/Select] (表示/選択) を選択して、評価結果を表示します。

    3. 評価結果からデータベースを選択し、評価レポートを確認して、問題が見つからなかったことを確認します。

    4. [Azure のレコメンデーションを取得する] を選択して、レコメンデーション ペインを開きます。

    5. [Collect performance data now] (今すぐパフォーマンス データを収集する) を選択します。 パフォーマンス ログの格納先となるローカル コンピューター上のフォルダーを選択し、[Start] (開始) を選択します。

      データ収集を停止するか、Azure Data Studio を閉じるまで、パフォーマンス データは収集されます。

      10 分後、Azure Virtual Machines 上の SQL Server のレコメンデーションが利用可能になった旨が Azure Data Studio から伝えられます。 最初のレコメンデーションが生成された後、[データ収集を再開する] を選択してデータ収集プロセスを継続することで、SKU レコメンデーションを調整できます。 評価時間の延長は特に、使用パターンが経時的に変化する状況で効果的です。

    6. 選択した Azure Virtual Machines 上の SQL Server ターゲットの [View details] (詳細の表示) を選択して、詳細な SKU レコメンデーション レポートを開きます。

    7. [Review SQL Server on Azure Virtual Machines Recommendations] (Azure Virtual Machines 上の SQL Server のレコメンデーションを確認します) で、レコメンデーションを確認します。 レコメンデーションのコピーを保存するには、[推奨事項レポートを保存する] チェック ボックスをオンにします。

  3. [閉じる] を選択してレコメンデーション ペインを閉じます。

  4. [次へ] を選択して、引き続きウィザードでデータベースの移行を行います。

移行の設定の構成

  1. Azure SQL への移行ウィザードの [Step 3: Azure SQL target] (ステップ 3: Azure SQL ターゲット) で、Azure アカウント、Azure サブスクリプション、Azure リージョン (場所)、ターゲット インスタンス (Azure Virtual Machines 上の SQL Server) を含むリソース グループを選択します。 次に、 [次へ] を選択します。

  2. [Step 4: Migration mode] (ステップ 4: 移行モード) で、[オフライン移行] を選択し、[次へ] を選択します。

    注意

    オフライン移行モードでは、データベース バックアップ ファイルがターゲット インスタンスである Azure Virtual Machines 上の SQL Server に復元されている間、ソース SQL Server データベースは書き込みアクティビティに使用すべきではありません。 アプリケーションのダウンタイムは、移行プロセスの開始から終了まで続きます。

  3. [Step 5: Data source configuration] (ステップ 5: データ ソースの構成) で、データベース バックアップの場所を選択します。 データベース バックアップは、オンプレミスのネットワーク共有または Azure Storage BLOB コンテナーに置くことができます。

    注意

    データベース バックアップがオンプレミスのネットワーク共有で提供される場合、ウィザードの次の手順でセルフホステッド統合ランタイムを設定する必要があります。 セルフホステッド統合ランタイムは、ソース データベースのバックアップにアクセスし、バックアップ セットの有効性を確認して Azure ストレージ アカウントにバックアップをアップロードする必要があります。

    データベース バックアップが既に Azure Storage Blob コンテナー上にある場合は、セルフホステッド統合ランタイムをセットアップする必要はありません。

  • ネットワーク共有上にあるバックアップの場合は、次の情報を入力または選択します。

    名前 説明
    ソースの資格情報 - ユーザー名 ソース SQL Server インスタンスに接続し、バックアップ ファイルを検証するための資格情報 (Windows および SQL 認証)。
    ソースの資格情報 - パスワード ソース SQL Server インスタンスに接続し、バックアップ ファイルを検証するための資格情報 (Windows および SQL 認証)。
    バックアップを含むネットワーク共有の場所 完全およびトランザクション ログのバックアップ ファイルを含むネットワーク共有の場所。 有効なバックアップ セットに属していないネットワーク共有内の無効なファイルまたはバックアップ ファイルは、移行プロセス中に自動的に無視されます。
    ネットワーク共有の場所への読み取り権限のある Windows ユーザー アカウント バックアップ ファイルを取得するためのネットワーク共有への読み取りアクセス権を持つ Windows 資格情報 (ユーザー名)。
    パスワード バックアップ ファイルを取得するためのネットワーク共有への読み取りアクセス権を持つ Windows 資格情報 (パスワード)。
    ターゲット データベース名 ターゲット データベース名は、移行プロセス中に変更できます。

  • Azure ストレージ BLOB コンテナーに格納されているバックアップの場合は、次の情報を入力または選択します。

    名前 説明
    ターゲット データベース名 ターゲット データベース名は、移行プロセス中に変更できます。
    ストレージ アカウントの詳細 バックアップ ファイルが置かれているリソース グループ、ストレージ アカウント、コンテナー。
    最終バックアップ ファイル 移行するデータベースの最後のバックアップのファイル名。

    重要

    ループバック チェック機能が有効になっていて、ソース SQL Server とファイル共有が同じコンピューター上にある場合、ソースは FQDN を使用してファイル共有にアクセスできません。 この問題を解決するには、ループバック チェック機能を無効にしてください。

  • Azure Data Studio の Azure SQL 移行拡張機能で SQL Server データベースを Azure に移行する際、Azure Storage アカウントのネットワーク設定で特定の構成を行う必要がなくなりました。 ただし、データベースのバックアップ場所と必要なストレージ アカウントのネットワーク設定によっては、リソースが Azure Storage アカウントにアクセスできるようにするために必要な手順がいくつかあります。 さまざまな移行シナリオとネットワーク構成については、次の表を参照してください。

    シナリオ SMB ネットワーク共有 Azure Storage アカウント コンテナー
    すべてのネットワークから有効 追加の手順なし 追加の手順なし
    選択した仮想ネットワークと IP アドレスから有効 1a を参照 2a を参照
    選択した仮想ネットワークと IP アドレス + プライベート エンドポイントから有効 1b を参照 2b を参照

1a - Azure Blob Storage のネットワーク構成

Azure VM に セルフホステッド統合ランタイム (SHIR) がインストールされている場合は、セクション「1b - Azure Blob Storage のネットワーク構成」を参照してください。 オンプレミス ネットワークにセルフホステッド統合ランタイム (SHIR) がインストールされている場合は、次のように、ホスト マシンのクライアント IP アドレスを Azure Storage アカウントに追加する必要があります。

ストレージ アカウントのネットワーク詳細を示すスクリーンショット。

この特定の構成を適用するには、SHIR マシンから Azure portal に接続し、Azure Storage アカウントの構成を開いて [ネットワーク] を選択し、[クライアント IP アドレスを追加する] チェック ボックスをオンにします。 [保存] を選択して変更を確定します。 残りの手順については、セクション「2a - Azure Blob Storage のネットワーク構成 (プライベート エンドポイント)」を参照してください。

1b - Azure Blob Storage のネットワーク構成

仮想マシンの非公開 IP アドレスは IP アドレス範囲のセクションに追加できないため、SHIR が Azure VM でホストされている場合は、VM の仮想ネットワークを Azure Storage アカウントに追加する必要があります。

ストレージ アカウントのネットワーク ファイアウォール構成を示すスクリーンショット。

この特定の構成を適用するには、Azure Storage アカウントを見つけ、[データ ストレージ] パネルで [ネットワーク] を選択し、[既存の仮想ネットワークの追加] チェック ボックスをオンにします。 新しいパネルが開いたら、Integration Runtime をホストしている Azure VM のサブスクリプション、仮想ネットワーク、サブネットを選択します。 この情報は、Azure Virtual Machine の [概要] ページで確認できます。 サブネットに [サービス エンドポイントが必要] と表示される場合には、[有効にする] を選択します。 すべての準備ができたら、更新内容を保存します。 残りの必要な手順については、セクション「2a - Azure Blob Storage のネットワーク構成 (プライベート エンドポイント)」を参照してください。

2a - Azure Blob Storage のネットワーク構成 (プライベート エンドポイント)

バックアップが Azure Storage コンテナーに直接配置されている場合は、Azure Storage アカウントと通信する Integration Runtime が存在しないため、上記の手順はいずれも不要です。 ただし、コンテナーからバックアップを復元するためにターゲット SQL Server インスタンスが Azure Storage アカウントと通信できることを確認する必要があります。 この特定の構成を適用するには、セクション「1b - Azure Blob Storage のネットワーク構成」の手順に従い、"既存の仮想ネットワークの追加" ポップアップに入力するときにターゲット SQL インスタンスの Virtual Network を指定します。

2b - Azure Blob Storage のネットワーク構成 (プライベート エンドポイント)

Azure Storage アカウントにプライベート エンドポイントを設定している場合は、セクション「2a - Azure Blob Storage のネットワーク構成 (プライベート エンドポイント)」で説明されている手順に従います。 ただし、ターゲット SQL Server サブネットだけでなく、プライベート エンドポイントのサブネットも選択する必要があります。 プライベート エンドポイントがターゲット SQL Server インスタンスと同じ VNet でホストされていることを確認してください。 そうでない場合は、「Azure Storage アカウントの構成」セクションのプロセスを使用して、プライベート エンドポイントをもう 1 つ作成します。

Database Migration Service インスタンスを作成する

Azure SQL への移行ウィザードの [Step 6: Azure Database Migration Service] (ステップ 6: Azure Database Migration Service) で、Azure Database Migration Service の新しいインスタンスを作成するか、または以前に作成した既存のインスタンスを再利用します。

Note

過去に Azure portal を使用して作成した Database Migration Service インスタンスは、Azure Data Studio の移行ウィザードで再利用できません。 インスタンスを再利用できるのは、Azure Data Studio を使用してインスタンスを作成した場合だけです。

Database Migration Service の既存のインスタンスを使用する

Database Migration Service の既存のインスタンスを使用するには:

  1. [リソース グループ] で、Database Migration Service の既存のインスタンスを含んだリソース グループを選択します。

  2. [Azure Database Migration Service] で、選択したリソース グループにある Database Migration Service の既存のインスタンスを選択します。

  3. [次へ] を選択します。

Database Migration Service の新しいインスタンスを作成する

Database Migration Service の新しいインスタンスを作成するには:

  1. Database Migration Service の新しいインスタンスを置く新しいリソース グループを [リソース グループ] で選択します。

  2. [Azure Database Migration Service] で [新規作成] を選択します。

  3. [Azure Database Migration Service の作成] で、Database Migration Service インスタンスの名前を入力し、[作成] を選択します。

  4. [Set up integration runtime] (統合ランタイムのセットアップ) で、次の手順を実行します。

    1. [統合ランタイムのダウンロードとインストール] リンクを選択して、Web ブラウザーでダウンロード リンクを開きます。 統合ランタイムをダウンロードし、ソース SQL Server インスタンスに接続するための前提条件を満たしたコンピューターにそれをインストールします。

      インストールが完了すると、Microsoft Integration Runtime Configuration Manager が自動的に起動して登録プロセスが開始されます。

    2. [認証キー] テーブルで、ウィザードから提供されたいずれかの認証キーをコピーし、それを Azure Data Studio に貼り付けます。 認証キーが有効であれば、Integration Runtime Configuration Manager に緑色のチェック マーク アイコンが表示されます。 緑色のチェック マークは、引き続き登録に進むことができることを示します。

      セルフホステッド統合ランタイムの登録後、Microsoft Integration Runtime 構成マネージャーを閉じます。

      Note

      セルフホステッド統合ランタイムを使用する方法について詳しくは、「セルフホステッド統合ランタイムを作成して構成する」を参照してください。

  5. Azure Data Studio の [Azure Database Migration Service の作成] で [テスト接続] を選択し、新しく作成した Database Migration Service インスタンスが、新たに登録されたセルフホステッド統合ランタイムに接続されていることを確認します。

  6. Azure Data Studio の移行ウィザードに戻ります。

データベースの移行を開始する

Azure SQL への移行ウィザードの [Step 7: Summary] (ステップ 7: サマリー) で、作成した構成を確認し、[移行の開始] を選択してデータベースの移行を開始します。

データベースの移行を監視する

  1. Azure Data Studio のサーバー メニューの [General] (全般) で、[Azure SQL Migration] (Azure SQL の移行) を選択し、Azure SQL の移行に使用するダッシュボードに移動します。

    [データベースの移行状態] で、進行中の移行、完了済みの移行、失敗した移行 (該当する場合) を追跡するか、またはすべてのデータベースの移行を確認できます。

    移行ダッシュボードの監視のスクリーンショット。

  2. [データベースの移行が進行中] を選択して、アクティブな移行を確認します。

    特定の移行の詳細を取得するには、そのデータベースの名前を選択します。

    移行の詳細ペインには、バックアップ ファイルとそれらに対応する状態が表示されます。

    Status 説明
    着荷済 バックアップ ファイルがソース バックアップ場所に到着し、検証されました。
    アップロード 統合ランタイムで、バックアップ ファイルが Azure Storage にアップロードされています。
    アップロード済み バックアップ ファイルが Azure Storage にアップロードされました。
    Restoring バックアップ ファイルを Azure Virtual Machine 上の SQL Server に復元しています。
    復旧済み Azure Virtual Machine 上の SQL Server にバックアップ ファイルが正常に復元されました。
    取り消されました 移行プロセスが取り消されました。
    無視 バックアップ ファイルは有効なデータベース バックアップ チェーンに属していないため、無視されました。

すべてのデータベース バックアップが Azure Virtual Machine 上の SQL Server のインスタンスに復元されると、移行されたデータベースが確実に使用できる状態になるように Database Migration Service によって自動一括移行が開始されます。 移行の状態が [進行中] から [成功] に変わります。

制限事項

- 1 つのデータベースを移行する場合、データベース バックアップは (コンテナーのルート フォルダーを含め) データベース フォルダー内のフラット ファイル構造に配置する必要があります。また、サポートされていないため、フォルダーを入れ子にすることはできません。

- 同じ Azure Blob Storage コンテナーを使用して複数のデータベースを移行する場合は、異なるデータベースのバックアップ ファイルをコンテナー内の別々のフォルダーに配置する必要があります。

- Azure 仮想マシン上のターゲット SQL Server で DMS を使用して既存のデータベースを上書きする操作はサポートされていません。

- ソース トポロジに合わせてターゲットで高可用性とディザスター リカバリーを構成することは、DMS ではサポートされていません。

次のサーバー オブジェクトはサポートされていません。

  • SQL Server エージェント ジョブ
  • 資格情報
  • SSIS パッケージ
  • サーバー監査

- DMS を使用したデータベースの移行には、Azure Data Factory から作成された既存のセルフホステッド統合ランタイムを使用することはできません。 最初は、Azure Data Studio の Azure SQL 移行拡張機能を使用してセルフホステッド統合ランタイムを作成する必要があります。これを今後のデータベース移行に再利用できます。

- Azure Virtual Machines 上の SQL Server に移行する場合、現在、SQL Server 2008 以前のバージョンを使用した VM はターゲット バージョンとしてサポートされていません。

- SQL Server 2012 または SQL Server 2014 を使用した VM を使用している場合は、ネットワーク共有オプションを使用する代わりに、ソース データベースのバックアップ ファイルを Azure Storage Blob コンテナーに格納する必要があります。 ブロック BLOB は SQL 2016 以降でのみサポートされているため、バックアップ ファイルをページ BLOB として格納します。

- ターゲットの Azure 仮想マシンの SQL IaaS Agent 拡張機能が、軽量モードではなくフル モードであることを確認する必要があります。

- DMS を使用した Azure SQL VM への移行では、SQL IaaS エージェントを内部で使用します。 また、SQL IaaS Agent 拡張機能では、既定のサーバー インスタンスまたは単一の名前付きインスタンスの管理のみがサポートされます。

- 1 つ以上の移行を同時に使用して、ターゲットとして最大 100 個のデータベースを同じ Azure SQL Server 仮想マシンに移行できます。 さらに、100 個のデータベースを含む移行が完了したら、ターゲットとして同じ Azure SQL Server 仮想マシンへの新しい移行を開始するのは最低でも 30 分待った後にしてください。 また、各データベースのすべての移行操作 (移行の開始、一括移行) には、順次数分かかります。 たとえば、100 個のデータベースを移行する場合、移行キューの作成に約 200 分 (2 x 100)、100 個のデータベースをすべて一括移行するのに約 100 分 (1 x 100) (バックアップと復元の時間を除く) かかることがあります。 そのため、データベースの数が増えるほど、移行は遅くなります。 厳密な移行テストに基づき、事前に移行期間を長めにスケジュールするか、SQL Server Azure VM に移行する際に多数のデータベースをバッチにパーティション分割してください。

- VM がバックアップ ファイルにアクセスできるように Azure Storage アカウントのネットワークとファイアウォールを構成する以外に、 ストレージ アカウントへの送信接続を許可するように、Azure VM 上の SQL Server のネットワークとファイアウォールを構成する必要もあります。

- SQL 移行の進行中は、Azure VM 上のターゲット SQL Server を電源オンのままにしておく必要があります。 また、新しい移行を作成する場合は、フェールオーバーするか、移行をキャンセルします。

ある場合はエラー メッセージ

ユーザー 'NT Service\SQLIaaSExtensionQuery のログインに失敗しました

エラー: Login failed for user 'NT Service\SQLIaaSExtensionQuery

理由: SQL Server インスタンスはシングル ユーザー モードです。 考えられる理由の 1 つは、Azure VM 上のターゲット SQL Server がアップグレード モードであることです。

解決策: Azure VM 上のターゲット SQL Server がアップグレード モードを終了するまで待ってから、もう一度移行を開始してください。

メッセージ: 復元ジョブを作成できませんでした。

エラー: Ext_RestoreSettingsError, message: Failed to create restore job.;Cannot create file 'F:\data\XXX.mdf' because it already exists.

解決策: Azure VM 上のターゲット SQL Server に接続し、XXX.mdfファイルを削除します。 次に、もう一度移行を開始します。

関連するコンテンツ