Managed Instance のリンク接続移行の環境を準備する - Azure ArcでのSQL Server移行

Applies to:SQL Server

この記事は、Azure Arc によって有効化された SQL Server インスタンスの Managed Instance リンク移行 のために、Azure ポータルで Azure SQL Managed Instance に向けた環境を準備するのに役立ちます。

このリンクを使用すると、分散型可用性グループを使用したリアルタイム レプリケーション (オンライン移行) を使用して、SQL Server データベースをAzure SQL Managed Instanceに移行できます。

注

• 移行エクスペリエンスに関するフィードバックを 製品グループに直接提供できます。
• SQL Server バージョン 1.1.3348.364 の Azure 拡張機能以降、一度に最大 10 個のデータベースを移行します。

[前提条件]

Azure ポータルを使用して SQL Server データベースをAzure SQL Managed Instanceに移行するには、次の前提条件が必要です。

• アクティブなAzure サブスクリプション。 アカウントがない場合は、無料アカウントを作成してください。
• Azure Arc によって有効になっている SQL Server のサポートされているインスタンスで、Azure Extension for SQL Server の最新バージョンを備えています。 拡張機能をアップグレードするには、「拡張機能 のアップグレード」を参照してください。

サポートされているSQL Serverバージョン

Azure SQL Managed Instanceの General Purpose サービス レベルと Business Critical サービス レベルの両方が、Managed Instance リンクをサポートしています。 リンク機能を使用した移行は、Windows Server上のSQL Serverの Enterprise、Developer、Standard の各エディションで動作します。

次の表に、リンクでサポートされている最小SQL Serverバージョンを示します。

SQL Server バージョン	最低限必要なサービス更新プログラム
SQL Server 2025 (17.x)	SQL Server 2025 RTM (17.0.1000.7)
SQL Server 2022 (16.x)	SQL Server 2022 RTM (16.0.1000.6)
SQL Server 2019 (15.x)	SQL Server 2019 CU20 (15.0.4312.2)
SQL Server 2017 (14.x)	SQL Server 2017 CU31 (14.0.3456.2) 以降と一致する SQL Server 2017 Azure Connect パック (14.0.3490.10) ビルド
SQL Server 2016 (13.x)	SQL Server 2016 SP3 (13.0.6300.2) と一致する SQL Server 2016 Azure Connect パック (13.0.7000.253) ビルド
SQL Server 2014 (12.x) 以前	SQL Server 2016 より前のバージョンはサポートされていません。

逆移行は、対応する update ポリシー を持つ SQL マネージド インスタンスから SQL Server 2025 および SQL Server 2022 への場合にのみサポートされます。 ネイティブ バックアップや復元などの他のツールを使用して移行を手動で元に戻したり、SSMS でリンクを手動で構成したりできます。

Permissions

このセクションでは、Azure ポータルを使用してSQL Server インスタンスをSQL Managed Instanceに移行するために必要なアクセス許可について説明します。

ソース SQL Server インスタンスでは、次のアクセス許可が必要です。

• 最小限の特権を有効にした場合、データベース移行プロセス中に sysadmin などの必要なアクセス許可が必要に応じて付与されます。
• 最小限の特権を使用できない場合、移行を実行するユーザーには、ソース SQL Server インスタンスに対する sysadmin アクセス許可が必要です。 さらに、移行をキャンセルする必要がある場合は、 アカウントに NT AUTHORITY\SYSTEM アクセス許可を手動で割り当てます。

Managed Instance リンクを使用して移行するには、SQL Managed Instance ターゲットに対する次のいずれかのアクセス許可が必要です。

• SQL Managed Instance 共同作成者 役割
• サブスクリプション レベルの共同制作者の役割または所有者の役割

最小限のアクセス許可については、「 カスタムアクセス許可」を参照してください。

注

SqlServerAvailabilityGroups_CreateManagedInstanceLink、SqlServerAvailabilityGroups_failoverMiLink、および SqlServerAvailabilityGroups_deleteMiLink アクセス許可を持つユーザーは、Azure内の Database migration ペインで、拡張機能で使用されるアカウントのSQL Serverアクセス許可 (sysadmin ロールを含む) を昇格させるアクションを実行できます。

レプリカ間でパフォーマンスキャパシティを一致させる

リンク機能を使用する場合は、SQL ServerとSQL Managed Instanceのパフォーマンス容量を一致することが重要です。 この照合は、セカンダリ レプリカがプライマリ レプリカからのレプリケーションやフェールオーバー後に対応できない場合に、パフォーマンスの問題を回避するのに役立ちます。 パフォーマンス容量には、CPU コア (または Azure 内の仮想コア)、メモリ、および I/O スループットが含まれます。

SQL Server インスタンスを準備する

SQL Server インスタンスを準備するには、次の手順を実行します。

• サポートされているバージョンを確認します。
• masterします。
• 可用性グループ機能を有効にします。
• 起動時に適切なトレース フラグを追加します。
• Restart SQL Serverし、構成を検証します。
• データベースを完全復旧モデルに設定します。
• 信頼されたルート証明機関AzureキーをSQL Serverにインポートします。
• 2019 以降をSQL Serverしている場合は>データベースの高速復旧
• ターゲット SQL マネージド インスタンスで Service Broker を使用する予定の場合は、Service Broker を有効にします。

これらの変更を有効にするにはSQL Serverを開始する必要があります。

サービスの更新プログラムをインストールする

SQL Serverバージョンに、バージョンのサポートテーブルに記載されているように、適切なサービス更新プログラムがインストールされていることを確認します。 更新プログラムをインストールする必要がある場合は、更新中にSQL Server インスタンスを再起動する必要があります。

SQL Serverのバージョンを確認するには、SQL Serverで次のTransact-SQL (T-SQL) スクリプトを実行します。

-- Run on SQL Server
-- Shows the version and CU of the SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';

マスター データベースにデータベース マスター キーを作成する

このリンクでは、証明書を使用して、SQL ServerとSQL Managed Instance間の認証と通信を暗号化します。 データベース マスター キーは、リンクによって使用される証明書を保護します。 データベース マスター キーが既にある場合は、この手順をスキップできます。

master データベースにデータベース マスター キーを作成します。 次のスクリプトの <strong_password> の代わりにご自分のパスワードを挿入し、機密情報として安全な場所に保管します。 SQL Serverで次の T-SQL スクリプトを実行します。

-- Run on SQL Server
-- Create a master key
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>';

データベース マスター キーがあることを確認するには、SQL Serverで次の T-SQL スクリプトを使用します。

-- Run on SQL Server
USE master;
GO
SELECT * FROM sys.symmetric_keys WHERE name LIKE '%DatabaseMasterKey%';

SQL Server 2016 インスタンスを準備する

SQL Server 2016 (13.x) の場合は、Prepare SQL Server 2016 のリンクの前提条件に記載されている追加の手順を完了する必要があります。 リンクでサポートされている SQL Server 2017 (14.x) 以降のバージョンでは、これらの追加の手順は必要ありません。

可用性グループを有効にする

リンク機能は、Always On 可用性グループ機能に依存しており、これは既定では有効になっていません。 詳細については、「Always On 可用性グループ機能を有効にする」を参照してください。

可用性グループ機能が有効になっていることを確認するには、SQL Serverで次の T-SQL スクリプトを実行します。

-- Run on SQL Server
-- Is the availability groups feature enabled on this SQL Server
DECLARE @IsHadrEnabled sql_variant = (select SERVERPROPERTY('IsHadrEnabled'))
SELECT
    @IsHadrEnabled as 'Is HADR enabled',
    CASE @IsHadrEnabled
        WHEN 0 THEN 'Availability groups DISABLED.'
        WHEN 1 THEN 'Availability groups ENABLED.'
        ELSE 'Unknown status.'
    END
    as 'HADR status'

可用性グループ機能が有効になっていない場合は、以下の手順に従って有効にします。

1. SQL Server 構成マネージャー を開きます。

2. 左側のウィンドウから SQL Server Services を選択します。

3. SQL Server サービスを右クリックし、Properties

   

4. [Always On 可用性グループ] タブに移動します。

5. [ Always On 可用性グループを有効にする ] チェック ボックスをオンにし、[ OK] を選択します。

   

   • SQL Server 2016 (13.x) を使用していて、メッセージ で This computer is not a node in a failover cluster オプションが無効になっている場合は、 Prepare SQL Server 2016 のリンクの前提条件で説明されている手順に従ってください。 これらの手順を完了したら、この手順に戻り、もう一度やり直してください。

6. ダイアログで [OK] を選択します。

7. SQL Server サービスを再起動します。

起動時のトレース フラグを有効にする

リンクのパフォーマンスを最適化するには、起動時に次のトレース フラグを有効にします。

• -T1800: このトレース フラグは、可用性グループ内のプライマリ レプリカとセカンダリ レプリカのログ ファイルが、512 バイトや 4 KB などの異なるセクター サイズのディスク上にある場合のパフォーマンスを最適化します。 プライマリ レプリカとセカンダリ レプリカの両方で 4 KB のディスク セクター サイズが使用されている場合、このトレース フラグは必要ありません。 詳しくは、KB3009974 を参照してください。
• -T9567: このトレース フラグは、自動シード処理時の可用性グループのデータ ストリーム圧縮を有効にします。 圧縮によってプロセッサの負荷が増加しますが、シード処理中の転送時間が大幅に短縮されます。

起動時にこれらのトレース フラグを有効にするには、次の手順を使用します。

1. SQL Server 構成マネージャーを開きます。

2. 左側のウィンドウから SQL Server Services を選択します。

3. SQL Server サービスを右クリックし、Properties を選択します。

   

4. [起動時のパラメーター] タブに移動します。[起動時のパラメーターの指定] に「-T1800」と入力し、[追加] を選択して起動時のパラメーターを追加します。 次に、「-T9567」と入力して [追加] を選択し、他のトレース フラグを追加します。 [適用] を選択して変更を保存します。

   

5. [OK] を選択して [プロパティ] ウィンドウを閉じます。

詳細については、「トレース フラグを有効にするための構文」を参照してください。

SQL Server再起動して構成を検証する

SQL Serverのバージョンをアップグレードしたり、可用性グループ機能を有効にしたり、スタートアップ トレース フラグを追加したりする必要がない場合は、このセクションをスキップできます。

サポートされているバージョンのSQL Serverを使用していることを確認したら、Always On 可用性グループ機能を有効にして、スタートアップ トレース フラグを追加し、SQL Server インスタンスを再起動して、次のすべての変更を適用します。

1. SQL Server 構成マネージャー を開きます。

2. 左側のウィンドウから SQL Server Services を選択します。

3. SQL Server サービスを右クリックし、Restart を選択します。

   

再起動後、SQL Serverで次の T-SQL スクリプトを実行して、SQL Server インスタンスの構成を検証します。

-- Run on SQL Server
-- Shows the version and CU of SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';
GO
-- Shows if the Always On availability groups feature is enabled
SELECT SERVERPROPERTY ('IsHadrEnabled') as 'Is Always On enabled? (1 true, 0 false)';
GO
-- Lists all trace flags enabled on SQL Server
DBCC TRACESTATUS;

SQL Serverバージョンは、適切なサービス更新プログラムが適用されたサポートされているバージョンのいずれかである必要があります。 Always On 可用性グループ機能を有効にする必要があり、 -T1800 と -T9567 トレース フラグが有効になっている必要があります。 次のスクリーンショットは、適切に構成されたSQL Server インスタンスで予想される結果の例です。

データベースを完全復旧モデルに設定する

リンクを介して移行されたデータベースは、完全復旧モデルにあり、少なくとも 1 つのバックアップを持っている必要があります。

移行するすべてのデータベースのSQL Serverで次のコードを実行します。 <DatabaseName> を実際のデータベース名に置き換えます。

-- Run on SQL Server
-- Set full recovery model for all databases you want to migrate.
ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL
GO

-- Execute backup for all databases you want to migrate.
BACKUP DATABASE [<DatabaseName>] TO DISK = N'<DiskPath>'
GO

信頼されたルート証明機関AzureキーをSQL Serverにインポートする

Azure が発行する SQL Managed Instance 公開キー証明書を信頼するためには、SQL Server に Azure 信頼済みのルート証明機関 (CA) キーをインポートする必要があります。

ルート CA キーは、Azure 証明機関の詳細からダウンロードできます。 少なくとも、DigiCert Global Root G2 および Microsoft RSA Root Certificate Authority 2017 証明書をダウンロードし、SQL Server インスタンスにインポートします。

注

SQL Managed Instance公開キー証明書の証明書パスのルート証明書は、Azure信頼されたルート証明機関 (CA) によって発行されます。 特定のルート CA は、Azure が信頼された CA リストを更新する時、時間の経過とともに変化する可能性があります。 セットアップを簡略化するために、Azure ルート証明機関に記載されているすべてのルート CA 証明書をインストールします。 以前にインポートしたSQL Managed Instance公開キーの発行者を識別することで、必要な CA キーのみをインストールできます。

サンプルの C:\certs\<name of certificate>.crt パスなど、SQL Server インスタンスにローカルに証明書を保存し、次のTransact-SQL スクリプトを使用してそのパスから証明書をインポートします。 <name of certificate> を実際の証明書名 (DigiCert Global Root G2 と Microsoft RSA Root Certificate Authority 2017) に置き換えます。これは、これら 2 つの証明書に必要な名前です。

-- Run on SQL Server-- Import <name of certificate> root-authority certificate (trusted by Azure), if not already present
CREATE CERTIFICATE [DigiCertPKI] FROM FILE = 'C:\certs\DigiCertGlobalRootG2.crt'
DECLARE @CERTID int
SELECT @CERTID = CERT_ID('DigiCertPKI')
EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net';
GO
CREATE CERTIFICATE [MicrosoftPKI] FROM FILE = 'C:\certs\Microsoft RSA Root Certificate Authority 2017.crt'
DECLARE @CERTID int
SELECT @CERTID = CERT_ID('MicrosoftPKI')
EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net';
GO

ヒント

sp_certificate_add_issuer ストアド プロシージャがSQL Server環境に存在しない場合、SQL Server インスタンスに appropriate サービス更新プログラムがインストールされていない可能性があります。

最後に、次の動的管理ビュー (DMV) を使用して、作成されたすべての証明書を確認します。

-- Run on SQL Server
USE master
SELECT * FROM sys.certificates

高速データベース復旧を有効にする

SQL Server 2019 以降のバージョンでは、高速データベース復旧を有効にし、永続バージョン ストア (PVS) が PRIMARY に設定されていることを確認します。 ソース SQL Server データベースで高速データベース復旧が有効になっていない場合、データベースの移行後にターゲット SQL マネージド インスタンスで有効にすることはできません。 永続バージョン ストア (PVS) が PRIMARYに設定されていない場合は、ターゲット SQL マネージド インスタンスでの復元操作に関する問題が発生する可能性があります。

SQL Server 2017 以前のバージョンでは、高速データベース復旧はサポートされていないため、この手順は必要ありません。

ソース SQL Server データベースで高速データベース復旧を適切に構成するには、次の手順に従います。

1. SQL Serverで次のTransact-SQL スクリプトを実行して、高速データベース復旧を有効にします。

   ALTER DATABASE [<database name>] SET ACCELERATED_DATABASE_RECOVERY = ON;
   

2. 永続バージョン ストア (PVS) は、既定の構成であるソース データベースで PRIMARY に設定する必要があります。 これが以前に変更された場合は、移行を開始 する前に PRIMARY に戻す 必要があります。

Service Broker を有効にする

Service Broker は、すべてのバージョンのSQL Serverに対して既定で有効になっています。 Service Broker が無効になっており、SQL Managed Instanceで使用する予定の場合は、SQL Managed Instanceに移行する前に、ソース SQL Server データベースで Service Broker を有効にします。 ソース SQL Server データベースで Service Broker が有効になっていない場合、ターゲット SQL マネージド インスタンスでは使用できません。

Service Broker が有効になっているかどうかを確認するには、SQL Server インスタンスで次のTransact-SQL スクリプトを実行します。

SELECT name AS [Database Name], is_broker_enabled AS [Service Broker Enabled]
FROM sys.databases
WHERE name = '<database name>';

Service Broker が無効になっている場合は、ソース SQL Server データベースで次のTransact-SQL スクリプトを実行して有効にします。

USE master;
GO

ALTER DATABASE [<database name>]
    SET ENABLE_BROKER;
GO

ネットワーク接続を構成する

リンクを機能させるには、SQL ServerとSQL Managed Instanceの間にネットワーク接続が必要です。 選択するネットワーク オプションは、SQL Server インスタンスがAzure ネットワーク上にあるかどうかによって異なります。

Azure外のSQL Server

Azureの外部でSQL Server インスタンスをホストする場合は、次のいずれかのオプションを使用して、SQL ServerとSQL Managed Instanceの間に VPN 接続を確立できます。

• サイト間 VPN 接続
• Azure ExpressRoute接続

ヒント

データをレプリケートするときに最適なネットワーク パフォーマンスを得る場合は、ExpressRoute を使用します。 実際のユース ケースに十分な帯域幅を持つゲートウェイをプロビジョニングしてください。

Azure 仮想マシン上の SQL Server

SQL Managed Instanceをホストするのと同じAzure仮想ネットワークにSQL Server on Azure Virtual Machinesをデプロイするのが最も簡単な方法です。これは、2 つのインスタンス間にネットワーク接続が自動的に存在するためです。 詳細については、「Quickstart: Azure SQL Managed Instanceを参照してください。

SQL Server on Azure Virtual Machines インスタンスが SQL マネージド インスタンスとは異なる仮想ネットワーク内にある場合は、2 つの仮想ネットワークを接続する必要があります。 このシナリオを機能させるために、仮想ネットワークが同じサブスクリプションに存在する必要はありません。

仮想ネットワークを接続するには、次の 2 つのオプションがあります。

• Azure仮想ネットワーク ピアリング
• VNet 間 VPN ゲートウェイ (Azure ポータル、PowerShell、Azure CLI)

ピアリングは、Microsoftバックボーン ネットワークを使用するため、推奨されます。 そのため、接続の観点からは、ピアリングされた仮想ネットワーク内の仮想マシンと同じ仮想ネットワーク内の仮想マシン間の待機時間に顕著な違いはありません。 仮想ネットワーク ピアリングは、同じリージョン内のネットワーク間でサポートされます。 グローバル仮想ネットワーク ピアリングは、2020 年 9 月 22 日より後に作成されたサブネットでホストされているインスタンスでサポートされています。 詳細については、「よく寄せられる質問 (FAQ)」をご覧ください。

環境間のネットワーク ポート

接続メカニズムに関係なく、ネットワーク トラフィックが環境間を流れるには、次の要件を満たす必要があります。

SQL Managed Instanceホストするサブネット上のネットワーク セキュリティ グループ (NSG) 規則では、次のことが許可されている必要があります。

• 送信元のSQL ServerのIPアドレスからのトラフィックを受信する受信ポート5022とポート範囲11000〜11999
• 送信先にトラフィックを送信する送信ポート 5022 SQL Server IP アドレス

SQL Managed Instanceで 5022 ポートを変更することはできません。

SQL Serverをホストするネットワーク上のすべてのファイアウォールと、ホスト OS で次のことが許可されている必要があります。

• MI サブネット /24 (10.0.0.0/24 など) の送信元 IP 範囲からのトラフィックを受信するために開かれたインバウンド ポート 5022
• MI サブネット (例: 10.0.0.0/24) の送信先 IP 範囲にトラフィックを送信するために開かれたアウトバウンド ポート 5022 とポート範囲 11000-11999

5022 ポートはSQL Server側でカスタマイズできますが、ポート範囲 11000 から 11999 をそのまま開く必要があります。

次の表で、各環境でのポートのアクションについて説明します。

環境	対処
SQL Server (Azure外)	SQL Managed Instanceのサブネット IP 範囲全体へのネットワーク ファイアウォールのポート 5022 で受信トラフィックと送信トラフィックの両方を開きます。 必要に応じて、SQL Server ホスト OS Windows ファイアウォールでも同じ操作を行います。
SQL Server (Azure内)	SQL Managed Instanceのサブネット IP 範囲全体へのネットワーク ファイアウォールのポート 5022 で受信トラフィックと送信トラフィックの両方を開きます。 必要に応じて、SQL Server ホスト OS Windows ファイアウォールでも同じ操作を行います。 ポート 5022 での通信を許可するには、仮想マシン (VM) をホストする仮想ネットワークにネットワーク セキュリティ グループ (NSG) 規則を作成します。
SQL マネージド インスタンス	AZURE ポータルで NSG 規則を作成し、IP アドレスとポート 5022 とポート範囲 11000 から 11999 でSQL Serverをホストするネットワークからの受信トラフィックと送信トラフィックを許可します。

Windows ファイアウォールでポートを開くには、SQL Server インスタンスの Windows ホスト OS で次の PowerShell スクリプトを使用します。

New-NetFirewallRule -DisplayName "Allow TCP port 5022 inbound" -Direction inbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP
New-NetFirewallRule -DisplayName "Allow TCP port 5022 outbound" -Direction outbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP

次の図は、オンプレミスネットワーク環境の例を示しています。環境内のすべてのファイアウォールで、SQL Server インスタンスをホストする OS ファイアウォール>、企業のファイアウォールとゲートウェイなど、ポート

Important

• ホスト サーバー、ネットワーク上のすべての企業ファイアウォールまたはゲートウェイなど、ネットワーク環境内のすべてのファイアウォールでポートを開く必要があります。 企業環境では、企業ネットワーク レイヤーで追加のポートを開くため、このセクションの情報をネットワーク管理者に示すことが必要な場合があります。
• SQL Server側でエンドポイントをカスタマイズすることもできますが、SQL Managed Instanceのポート番号を変更したりカスタマイズしたりすることはできません。
• マネージド インスタンスをホストするサブネットの IP アドレス範囲と、SQL Serverが重複しないようにする必要があります。

許可リストに URL を追加する

ネットワーク セキュリティ設定によっては、SQL Managed Instance FQDN と、Azureで使用されるリソース管理エンドポイントの一部の URL を許可リストに追加することが必要になる場合があります。

許可リストに次のリソースを追加します。

• SQL マネージド インスタンスの完全修飾ドメイン名、すなわち FQDN。 たとえば、 managedinstance.a1b2c3d4e5f6.database.windows.netと指定します。
• Microsoft Entraオーソリティ
• Microsoft Entra エンドポイントリソースID
• Resource Manager エンドポイント
• サービス エンドポイント

SQL Server Management Studio (SSMS) の Tools> インターフェイスにアクセスし、許可リストに追加する必要があるクラウド内のリソースの特定の URL を特定するには、「政府向けクラウド用 SSMS の構成」セクションの手順に従います。

TDE で保護されたデータベースの証明書を移行する (省略可能)

Transparent Data Encryption (TDE) によって保護されたSQL Server データベースを SQL マネージド インスタンスにリンクする場合は、リンクを使用する前に、対応する暗号化証明書をオンプレミスまたはAzure VM SQL Server インスタンスから SQL マネージド インスタンスに移行する必要があります。 詳細な手順については、「TDE で保護されたデータベースの証明書をAzure SQL Managed Instanceに取得する」を参照してください。

サービスで管理される TDE キーで暗号化されたSQL Managed InstanceデータベースをSQL Serverにリンクすることはできません。 暗号化されたデータベースをSQL Serverにリンクできるのは、カスタマー マネージド キーを使用して暗号化し、宛先サーバーがデータベースの暗号化に使用したのと同じキーにアクセスできる場合のみです。 詳細については、Azure Key Vault を使用して SQL Server TDE を設定するを参照してください。

注

Azure Key Vaultは、SQL Server 2022 の Cumulative Update 14 以降のSQL Server on Linuxでサポートされます。

ネットワーク接続をテストする

移行を開始する前に、SQL Server インスタンスとSQL Managed Instanceの間のネットワーク接続をテストします。 移行プロセスの一環として、Azure ポータルから直接接続をテストできます。 ただし、Transact-SQLとSQL Server エージェントを使用して、接続を手動でテストすることもできます。 詳細については、「 ネットワーク接続のテスト」を参照してください。

Azure ポータルを使用して接続をテストするには、次の手順に従います。

1. SQL Server インスタンス リソースの Database migration> ペインで Migrate data を選択します。

2. MI リンク オプションを選択します。

3. 移行するターゲット データベースを選択し、[ 次へ: 設定] を使用して次のタブに移動します。

4. [ 設定] タブで、リンクの名前とソース可用性グループを指定します。 次に、Test connection を使用して、SQL ServerとSQL Managed Instanceの間のネットワーク接続を検証します。

   

次の点を考慮してください。

• 誤検知を回避するには、ネットワーク パス上のすべてのファイアウォールでインターネット制御メッセージ プロトコル (ICMP) トラフィックを許可する必要があります。
• 誤検知を回避するには、ネットワーク パス上のすべてのファイアウォールで、独自のSQL Server UCS プロトコル上のトラフィックを許可する必要があります。 プロトコルをブロックすると、接続テストが成功する可能性がありますが、リンクの作成に失敗します。
• パケット レベルのガードレールを使用する高度なファイアウォールセットアップは、SQL ServerとSQL Managed Instance間のトラフィックを許可するように適切に構成する必要があります。

制限事項

次の制限が適用されます。

• Managed Instance リンクの制限は、Azure ポータルを介した移行に適用されます。
• SQL Server バージョン 1.1.3238.349 以前のバージョンのAzure拡張機能では、リンクを介した一度に 1 つのデータベースの移行のみがサポートされています。 複数のデータベースを同時に移行するには、SQL Server バージョン 1.1.3348.364 以降のAzure拡張機能にアップグレードします。
• 移行をキャンセルするには、ソース SQL Server インスタンスに対する sysadmin アクセス許可が必要です。 SQL Server インスタンスが最小限の特権を使用していない場合は、sysadmin アクセス許可を NT AUTHORITY\SYSTEM アカウントに手動で割り当てます。
• 移行のために Azure ポータルを使用してリンクを構成することは、SQL Server Management Studio (SSMS) または Transact-SQL (T-SQL) を使用して手動で作成されたリンクと互換性がありません。 詳細については、 既知の問題 を確認してください。
• Azure ポータルを使用した移行の監視は、監視ライセンス要件を満たすSQL Serverインスタンスでのみ使用できます。

一般的な問題のトラブルシューティング

Azure SQL Managed Instanceに移行するときの一般的な問題をトラブルシューティングするには、移行の問題を参照してください。

次のステップ

Azure SQL Managed Instance に移行します

関連コンテンツ

• マネージドインスタンスリンクのベストプラクティス
• Azure Arc における SQL Server 移行の概要
• LRS 移行のための準備環境 - Azure Arc での SQL Server 移行
• Azure Arc によって有効化された SQL Server
• 移行エクスペリエンスのフィードバックを製品グループに直接送信する
• Azure SQL Managed Instance への移行 - Azure Arc での SQL Server 移行