チュートリアル: Azure Data Studio で SQL Server を Azure Virtual Machine 上の SQL Server にオンライン移行する

  • [アーティクル]

Azure Data Studio の Azure SQL 移行拡張機能を使用して、データベースを SQL Server インスタンスから Azure Virtual Machine 上の SQL Server (SQL Server 2016 以降) に最小限のダウンタイムで移行します。 一定の手作業が必要になる可能性のある方法については、Azure Virtual Machine 上の SQL Server への SQL Server インスタンスの移行に関する記事を参照してください。

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

このチュートリアルでは、以下の内容を学習します。

  • 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 を作成し、セルフホステッド統合ランタイムをインストールしてソース サーバーとバックアップにアクセスします。
  • 移行を開始し、その進行状況を監視します。
  • 準備ができたら、移行カットオーバーを実行します。

この記事では、SQL Server から Azure Virtual Machine 上の SQL Server へのオンライン移行について説明します。 オフライン移行については、「Azure Data Studio と DMS を使用してオフラインで SQL Server を Azure Virtual Machine 上の SQL Server に移行する」を参照してください。

前提条件

このチュートリアルを完了するには、以下を実行する必要があります。

  • Azure Data Studio をダウンロードし、インストールする

  • Azure Data Studio マーケットプレースから Azure SQL 移行拡張機能をインストールする

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

    • Azure Virtual Machine 上のターゲット SQL Server の共同作成者 (および SMB ネットワーク共有からデータベース バックアップ ファイルをアップロードするためのストレージ アカウント)。
    • Azure Virtual Machine または Azure ストレージ アカウント上のターゲット SQL Server を含む Azure リソース グループの閲覧者ロール。
    • Azure サブスクリプションの所有者または共同作成者ロール。
    • 前述の組み込みロールを使用する代わりに、この記事で定義したカスタム ロールを割り当てることもできます。

    重要

    Azure アカウントは、移行手順を構成する場合にのみ必要であり、移行ウィザードの評価または Azure の推奨事項の手順では必要ありません。

  • Azure Virtual Machine 上にターゲット SQL Server を作成します。

    重要

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

  • ソース SQL Server の接続に使用するログイン情報が、sysadmin サーバー ロールのメンバーであるか、CONTROL SERVER アクセス許可が付与されていることを確認します。

  • データベースの完全バックアップ ファイルとトランザクション ログ バックアップ ファイルに、次のいずれかのストレージ オプションを使用します。

    • SMB ネットワーク共有
    • Azure ストレージ アカウントのファイル共有または BLOB コンテナー

    重要

    • Azure Data Studio の Azure SQL 移行拡張機能では、データベース バックアップは取得されません。また、ユーザーに代わってデータベース バックアップも開始されません。 その代わりに、このサービスでは、移行に既存のデータベース バックアップ ファイルが使用されます。
    • データベース バックアップ ファイルが SMB ネットワーク共有で提供されている場合は、DMS サービスがデータベース バックアップ ファイルをアップロードできる Azure ストレージ アカウントを作成します。 Azure Storage アカウントは、Azure Database Migration Service インスタンスの作成先と同じリージョンに作成してください。
    • Azure Database Migration Service によってバックアップが開始されることはなく、移行には既存のバックアップが使用されます。これは、ディザスター リカバリー計画の一部として既に作成されている場合があります。
    • 各バックアップは、独立したバックアップ ファイルまたは複数のバックアップ ファイルに書き込まれます。 ただし、1 つのバックアップ メディアに複数のバックアップ (完全バックアップとトランザクション ログなど) を追加することはサポートされていません。
    • 大きなバックアップの移行に関連する潜在的な問題が発生する可能性を低減するには、圧縮されたバックアップを使用します。

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

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

    ヒント

    データベースに Always Encrypted で保護されている機密データが含まれている場合、Azure Data Studio と DMS を使用した移行プロセスでは、Azure Virtual Machine 上のターゲット SQL Server に Always Encrypted キーが自動的に移行されます。

  • データベース バックアップがネットワーク ファイル共有にある場合は、データベース バックアップにアクセスして移行するためのセルフホステッド統合ランタイムをインストールするマシンを用意します。 移行ウィザードでは、セルフホステッド統合ランタイムをダウンロードしてインストールするためのダウンロード リンクと認証キーが提供されます。 移行の準備として、セルフホステッド統合ランタイムをインストールする予定のマシンで、次のアウトバウンド ファイアウォール規則とドメイン名が有効になっていることを確認します。

    ドメイン名 送信ポート 説明
    パブリック クラウド: {datafactory}.{region}.datafactory.azure.net
    または *.frontend.clouddatahub.net
    Azure Government: {datafactory}.{region}.datafactory.azure.us
    中国: {datafactory}.{region}.datafactory.azure.cn    		 443 セルフホステッド統合ランタイムがデータ移行サービスに接続するために必要です。
    パブリック クラウドに新しく作成されたデータ ファクトリの場合、セルフホステッド統合ランタイム キーから {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 リソース プロバイダーがサブスクリプションに登録されていることを確認します。 リソース プロバイダーを登録する手順に従ってください

Azure Data Studio で [Azure SQL への移行] ウィザードを起動します

  1. Azure Data Studio を開き、サーバー アイコンを選択して、オンプレミスの SQL Server (または Azure Virtual Machine の SQL Server) に接続します。
  2. サーバーの接続で、右クリックして [管理] を選択します。
  3. サーバーのホーム ページで、 [Azure SQL の移行] 拡張機能を選択します。
  4. [Azure SQL の移行] ダッシュボードで、 [Azure SQL への移行] を選択して移行ウィザードを起動します。 Launch Migrate to Azure SQL wizard
  5. 移行ウィザードの最初の手順で、既存または新しい Azure アカウントを Azure Data Studio にリンクします。

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

  1. 評価を実行するデータベースを選択し、 [次へ] を選択します。
  2. Azure Virtual Machine 上の SQL Server をターゲットとして選択します。 Screenshot of assessment confirmation.
  3. [表示/選択] ボタンを選択してデータベースの評価結果の詳細を表示し、移行するデータベースを選択し、 [OK] を選択します。
  4. [Azure のレコメンデーションを取得する] ボタンを選択します。
  5. [パフォーマンス データを今すぐ収集する] オプションを選択して、収集するパフォーマンス ログのパスを入力し、[開始] ボタンをクリックします。
  6. これで、収集を停止するか、ウィザードの [次へ] ボタンを押すか、Azure Data Studio を閉じるまで、Azure Data Studio はパフォーマンス データを収集するようになります。
  7. 10 分後に、Azure SQL VM の推奨される構成が表示されます。 最初の 10 分が経過した後に [レコメンデーションの更新] リンクを押すと、収集した追加のデータを含めて推奨事項を更新更新することもできます。
  8. 上記の [Azure Virtual Machine] ボックスの [SQL Server] で、[詳細の表示] ボタンを選択して、推奨事項の詳細を確認します。
  9. ビューの詳細ボックスを閉じ、[次へ] ボタンを押します。

移行の設定の構成

  1. 対応するドロップダウン リストからサブスクリプション、場所、リソース グループを選択して [Azure Virtual Machine] 上のターゲット [SQL Server] を指定し、[次へ] を選択します。
  2. 移行モードとして [オンライン移行] を選択します。

    注意

    オンライン移行モードでは、データベース バックアップが Azure Virtual Machine 上のターゲット SQL Server に継続的に復元されている間、ソース SQL Server データベースは読み取りと書き込みのアクティビティに使用できます。 アプリケーションのダウンタイムは、移行の最後の切り替えの期間に限定されます。

  3. 手順 5 では、データベース バックアップの場所を選択します。 データベース バックアップは、オンプレミスのネットワーク共有または Azure Storage Blob コンテナーに置くことができます。

    Note

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

  • ネットワーク共有に置かれたバックアップには、ソース SQL Server、ソース バックアップの保存先、ターゲット データベース名、バックアップ ファイルのアップロード先の Azure ストレージ アカウントの以下の詳細を指定します。

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

  • Azure Storage BLOB コンテナーに格納されたバックアップの場合、対応するドロップダウン リストから、[ターゲット データベース名]、[リソース グループ]、[Azure ストレージ アカウント]、[BLOB コンテナー] の以下の詳細を指定します。

    フィールド 説明
    ターゲット データベース名 ターゲット データベース名は、移行プロセス中にターゲットのデータベース名を変更する場合は変更できます。
    ストレージ アカウントの詳細 バックアップ ファイルが置かれているリソース グループ、ストレージ アカウント、コンテナー。
  1. [次へ] を選択して続行します。

    重要

    ループバック チェック機能が有効になっていて、ソース 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 アカウントに追加する必要があります。

    Screenshot that shows the storage account network details.

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

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

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

    Screenshot that shows the storage account network firewall configuration.

    この特定の構成を適用するには、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 つ作成します。

Azure Database Migration Service を作成する

  1. 新しい Azure Database Migration Service を作成するか、以前に作成した既存のサービスを再使用します。

    Note

    以前に Azure portal を使用して DMS を作成した場合、Azure Data Studio の移行ウィザードでそれを再使用することはできません。 以前に Azure Data Studio を使用して作成された DMS だけが再使用できます。

  2. 既存の DMS があるリソース グループを選択します。そうでない場合は、新しいものを作成する必要があります。 [Azure Database Migration Service] ドロップダウンに、選択したリソース グループ内の既存の DMS が一覧表示されます。
  3. 既存の DMS を再使用するには、ドロップダウン リストから選択します。セルフホステッド統合ランタイムの状態がページの下部に表示されます。
  4. 新しい DMS を作成するには、 [新規作成] を選択します。
  5. [Azure Database Migration Service の作成] 画面で、DMS の名前を入力し、 [作成] を選択します。
  6. DMS の作成が正常に完了すると、統合ランタイムをセットアップするための詳細が表示されます。
  7. [統合ランタイムのダウンロードとインストール] を選択して、Web ブラウザーでダウンロード リンクを開きます。 ダウンロードを完了します。 ソース SQL Server、およびソース バックアップを含む場所に接続するための前提条件を満たしているマシンに、統合ランタイムをインストールします。
  8. インストールが完了すると、Microsoft Integration Runtime Configuration Manager が自動的に起動して登録プロセスが開始されます。
  9. Azure Data Studio のウィザード画面に表示された認証キーの 1 つをコピーして貼り付けます。 認証キーが有効であれば、Integration Runtime Configuration Manager に緑色のチェック マーク アイコンが表示され、引き続き登録できることが示されます。
  10. セルフホステッド統合ランタイムの登録が正常に完了したら、Microsoft Integration Runtime Configuration Manager を閉じ、Azure Data Studio の移行ウィザードに戻ります。
  11. Azure Data Studio の [Azure Database Migration Service の作成] 画面で [接続のテスト] を選択して、新しく作成された DMS が新しく登録されたセルフホステッド統合ランタイムに接続されていることを確認し、 [完了] を選択します。 Test connection integration runtime
  12. 概要を確認し、 [完了] を選択してデータベースの移行を開始します。

移行を監視する

  1. [データベースの移行状態] で、進行中の移行、完了した移行、失敗した移行 (ある場合) を追跡できます。

    monitor migration dashboard

  2. [データベースの移行が進行中] を選択して、進行中の移行を表示し、データベース名を選択して詳細情報を取得します。

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

    状態 説明
    [受信] バックアップ ファイルがソース バックアップ場所に到着し、検証されました
    アップロード 統合ランタイムで現在、バックアップ ファイルが Azure Storage にアップロードされています
    アップロード完了 バックアップ ファイルが Azure Storage にアップロードされました
    Restoring Azure Database Migration Service は、現在バックアップ ファイルを Azure Virtual Machine 上の SQL Server に復元しています
    復元 Azure Virtual Machine の SQL Server でバックアップ ファイルが正常に復元されました
    Canceled 移行プロセスが取り消されました
    無視 バックアップ ファイルは有効なデータベース バックアップ チェーンに属していないため、無視されました

    online vm backup restore details

移行カットオーバーを完了する

このチュートリアルの最後の手順では、移行のカットオーバーを完了します。 完了することで、Azure Virtual Machine 上の SQL Server の移行されたデータベースが使用できるようになります。 このデータベースに接続するアプリケーションにはダウンタイムが必要であり、カットオーバーのタイミングは、業務やアプリケーションの関係者と慎重に計画する必要があります。

カットオーバーを完了するには:

  1. ソース データベースに送信されるすべてのトランザクションを停止します。
  2. アプリケーション構成を変更し、Azure Virtual Machines 上の SQL Server のターゲット データベースをポイントするようにします。
  3. 指定されたバックアップ場所で、ソース データベースの最後のログのバックアップを行います
  4. ソース データベースを読み取り専用モードにします。 したがって、ユーザーはデータベースのデータを読み取ることができますが、変更はできません。
  5. 監視の詳細パッケージで、すべてのデータベース バックアップの状態が [復元された] になっていることを確認します。
  6. 監視の詳細ページで [一括を完了する] を選択します。

カットオーバー プロセス中に、移行の状態が [処理中です] から [完了しています] に変わります。 カットオーバー プロセスが完了すると、移行の状態が [成功しました] に変わります。 データベースの移行が正常に完了し、移行されたデータベースが使用できるようになりました。

制限事項

Azure Data Studio 用の Azure SQL 拡張機能を使用して Azure VM 上の SQL Server に移行する場合、次の制限があります。

  • 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 拡張機能が、軽量モードではなくフル モードであることを確認する必要があります。
  • SQL IaaS Agent 拡張機能では、既定のサーバー インスタンスまたは単一の名前付きインスタンスの管理のみがサポートされます。
  • SQL Server Azure Virtual Machine に移行できるデータベースの数は、ハードウェアの仕様とワークロードによって異なりますが、適用される制限はありません。 ただし、各データベースのすべての移行操作 (移行の開始、一括移行) には、順次数分かかります。 たとえば、100 個のデータベースを移行する場合、移行キューの作成に約 200 分 (2 x 100)、100 個のデータベースをすべて一括移行するのに約 100 分 (1 x 100) (バックアップと復元の時間を除く) かかることがあります。 そのため、データベースの数が増えるほど、移行は遅くなります。 Microsoft では、厳密な移行テストに基づき、事前に移行期間を長めにスケジュールするか、SQL Server Azure VM に移行する際に多数のデータベースをバッチにパーティション分割することを推奨しています。
  • VM がバックアップ ファイルにアクセスできるように Azure Storage アカウントのネットワークとファイアウォールを構成する以外に、 ストレージ アカウントへの送信接続を許可するように、Azure VM 上の SQL Server のネットワークとファイアウォールを構成する必要もあります。
  • SQL 移行の進行中は、Azure VM 上のターゲット SQL Server を電源オンのままにしておく必要があります。 また、新しい移行を作成する場合は、フェールオーバーするか、移行をキャンセルします。
  • エラー: 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 ファイルを削除します。 次に、もう一度移行を開始します。

次のステップ