環境をリンク用に準備する - Azure SQL Managed Instance

Applies to:Azure SQL Managed Instance

この記事では、Windows または Linux にインストールされているSQL ServerとAzure SQL Managed Instanceの間でレプリケートできるように、Managed Instance リンク用に環境を準備する方法について説明します。

注意

ダウンロード可能なスクリプトを使用して、Managed Instance リンク用の環境の準備を自動化できます。詳細については、リンク設定の自動化に関するブログを参照してください。

前提条件

SQL ServerとAzure SQL Managed Instanceの間にリンクを作成するには、次の前提条件が必要です。

アクティブなAzure サブスクリプション。アカウントがない場合は、無料アカウントを作成してください。
Supported バージョンのSQL Server、必要なサービス更新プログラムを適用したもの。
Azure SQL Managed Instance は、適切なupdate ポリシーを使用して実行されます。お持ちでない場合は、作業を開始してください。
意図して最初のプライマリにする予定のサーバー。この選択により、リンクを作成する場所が決まります。
- SQL マネージドインスタンスプライマリから SQL Server 2025 セカンダリへのリンク構成は、SQL Server 2025 更新ポリシーで構成された SQL マネージドインスタンスでのみサポートされます。
- SQL マネージドインスタンスプライマリから SQL Server 2022 セカンダリへのリンクの構成は、SQL Server 2022 CU10 以降でのみサポートされており、SQL Server 2022 更新ポリシーで構成された SQL マネージドインスタンスにおいて利用可能です。

注意事項

リンク機能で使用するための SQL マネージドインスタンスを作成する際には、SQL Server が使用する In-Memory OLTP (オンライントランザクション処理) 機能のメモリ要件を考慮に入れてください。詳細については、「リソース制限の Azure SQL Managed Instance概要を参照してください。

アクセス許可

SQL Serverの場合、sysadmin アクセス許可が必要です。

Azure SQL Managed Instanceの場合は、SQL Managed Instance Contributor のメンバーであるか、カスタムロールに対して次のアクセス許可を持っている必要があります。

Microsoft。Sql/ リソース	必要な権限
Microsoft.Sql/managedInstances	/read、/write
Microsoft.Sql/managedInstances/hybridCertificate	/action
Microsoft。Sql/managedInstances/databases	/read、/delete、/write、/completeRestore/action、/readBackups/action、/restoreDetails/read
Microsoft。Sql/managedInstances/distributedAvailabilityGroups	/read、/write、/delete、/setRole/action
Microsoft。Sql/managedInstances/endpointCertificates	/read
Microsoft.Sql/managedInstances/hybridLink	/read、/write、/delete
Microsoft。Sql/managedInstances/serverTrustCertificates	/write、/delete、/read

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

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

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

SQL Server インスタンスを準備するには、次の点を検証する必要があります。

サポートされている最小バージョンを使用しています。
masterしました。
可用性グループ機能を有効にしました。
起動時に適切なトレースフラグを追加しました。
バックアップではチェックサムが使用されます。
SQL Server 2019以降を使用している場合、高速化データベース復旧を有効化し、ターゲットSQLマネージドインスタンスで使用する予定です。
ターゲット 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%';

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

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

注意

SQL Server on Linuxについては、「 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'

重要

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

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

SQL Server 構成マネージャーを開きます。
左側のウィンドウから SQL Server Services を選択します。
SQL Server サービスを右クリックし、Properties を選択します。
[Always On 可用性グループ] タブにアクセスします。
[AlwaysOn 可用性グループを有効にする] チェックボックスをオンにして、[OK] を選択します。
- SQL Server 2016 (13.x) を使用している場合、および Always On 可用性グループを有効にする場合 オプションはメッセージ This computer is not a node in a failover cluster で無効になります。 Prepare SQL Server 2016 の前提条件 - Azure SQL Managed Instance リンクで説明されている追加の手順に従ってください。これらの他の手順を完了したら、戻って、この手順をもう一度やり直してください。
ダイアログで [OK] を選択します。
SQL Server サービスを再起動します。

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

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

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

注意

SQL Server on Linuxについては、「有効なトレースフラグ」を参照してください。

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

SQL Server 構成マネージャーを開きます。
左側のウィンドウから SQL Server Services を選択します。
SQL Server サービスを右クリックし、Properties を選択します。
[起動時のパラメーター] タブに移動します。[起動時のパラメーターの指定] に「-T1800」と入力し、[追加] を選択して起動時のパラメーターを追加します。次に、「-T9567」と入力して [追加] を選択し、他のトレースフラグを追加します。 [適用] を選択して変更を保存します。
[OK] を選択して [プロパティ] ウィンドウを閉じます。

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

チェックサムでバックアップを使用する

リンクを作成する場合、プライマリレプリカとセカンダリレプリカの間の初期シード処理は、プライマリレプリカ上のデータベースの完全バックアップを取得し、セカンダリレプリカに転送し、そこで復元することによって行われます。完全バックアップを実行するときは、 WITH CHECKSUM オプションを使用して、バックアップが有効であり、破損していないことを確認することをお勧めします。詳細については、「BACKUP (Transact-SQL)を参照してください。

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

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

SQL Server 構成マネージャー を開きます。
左側のウィンドウから SQL Server Services を選択します。
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 インスタンスで予想される結果の例です。

SSMS で予想される結果を示すスクリーンショット。

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

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

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

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

SQL Serverで次のTransact-SQL スクリプトを実行して、高速データベース復旧を有効にします。
```
ALTER DATABASE [<database name>] SET ACCELERATED_DATABASE_RECOVERY = ON;
```
永続バージョンストア (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

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)」をご覧ください。

Azure外のSQL Server

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

ヒント

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

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

接続メカニズムに関係なく、ネットワークトラフィックが環境間を流れるようにするために満たさなければならない要件があります。

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

送信元からのトラフィックを受信する受信ポート 5022 とポート範囲 11000 から 11999 SQL Server IP
宛先のSQL Server IPへのトラフィック送信用のアウトバウンドポート5022

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

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

SQL Server と SQL マネージドインスタンス間のリンクを設定するためのネットワーク要件を示すDiagram.

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

環境	対処
SQL Server (Azure内)	SQL Managed Instanceのサブネット IP 範囲全体へのネットワークファイアウォールのポート 5022 で受信トラフィックと送信トラフィックの両方を開きます。必要に応じて、SQL Server ホスト OS (Windows/Linux) ファイアウォールでも同じ操作を行います。ポート 5022 での通信を許可するには、仮想マシン (VM) をホストする仮想ネットワークにネットワークセキュリティグループ (NSG) 規則を作成します。
SQL Server (Azure外)	SQL Managed Instanceのサブネット IP 範囲全体へのネットワークファイアウォールのポート 5022 で受信トラフィックと送信トラフィックの両方を開きます。必要に応じて、SQL Server ホスト OS (Windows/Linux) ファイアウォールでも同じ操作を行います。
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 ファイアウォールや、企業のファイアウォールやゲートウェイなど、ポートを開く必要があることを示しています。

SQL Server と SQL マネージドインスタンス間のリンクを設定するためのネットワークインフラストラクチャを示すダイアグラム。

重要

ポートは、ホストサーバーや、ネットワーク上のすべての企業ファイアウォールまたはゲートウェイなど、ネットワーク環境内のすべてのファイアウォールで開く必要があります。企業環境では、企業ネットワークレイヤーで追加のポートを開くため、このセクションの情報をネットワーク管理者に示すことが必要な場合があります。
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 エンドポイント
サービスエンドポイント

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

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

リンクを機能させるには、SQL ServerとSQL Managed Instanceの間の双方向ネットワーク接続が必要です。 SQL Server側でポートを開き、SQL Managed Instance側で NSG 規則を構成したら、SQL Server Management Studio (SSMS) またはTransact-SQLを使用して接続をテストします。

ネットワークをテストするには、SQL ServerとSQL Managed Instanceの両方で一時的な SQL エージェントジョブを作成して、2 つのインスタンス間の接続を確認します。 SSMS でネットワークチェッカーを使用すると、ジョブが自動的に作成され、テストの完了後に削除されます。 T-SQL を使用してネットワークをテストする場合は、SQL Agent ジョブを手動で削除する必要があります。

注意

SQL Server on LinuxでのSQL Server エージェントによる PowerShell スクリプトの実行は現在サポートされていないため、現在、SQL Server on LinuxでSQL Server エージェントジョブから Test-NetConnection を実行することはできません。

SQL Agent を使用してネットワーク接続をテストするには、次の要件が必要です。

テストを実行するユーザーは、ジョブを作成するためにアクセス許可 (sysadmin のいずれかmsdb) を持っているか、SQL ServerとSQL Managed Instanceの両方について SQLAgentOperator ロールに属している必要があります。
SQL Server エージェントサービスは、SQL Serverrunningである必要があります。 SQL Managed Instanceではエージェントが既定でオンになっているため、追加のアクションは必要ありません。

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

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

SSMS
T-SQL

SSMS でSQL ServerとSQL Managed Instanceの間のネットワーク接続をテストするには、次の手順に従います。

SSMS でプライマリレプリカとなるインスタンスに接続します。
オブジェクトエクスプローラー でデータベースを展開し、セカンダリにリンクするデータベースを右クリックします。 Tasks>Azure SQL Managed Instance link>Test Connection を選択して、Network Checker ウィザードを開きます。
ネットワークチェッカー ウィザードの [概要] ページで [次へ] を選択肢ます。
すべての要件が [前提条件] ページで満たされている場合は、[次へ] を選択します。それ以外の場合は、満たされていない前提条件を解決し、[検証の再実行] を選択します。
[ログイン] ページで、[ログイン] を選択して、セカンダリレプリカになるもう一方のインスタンスに接続します。 [次へ] を選択します。
[ネットワークオプションの指定] ページで詳細を確認し、必要に応じて IP アドレスを指定します。 [次へ] を選択します。
[概要] ページで、ウィザードが実行する操作を確認し、[完了] を選択して 2 つのレプリカ間の接続をテストします。
[結果] ページを確認して、2 つのレプリカ間に接続が存在することを確認し、[閉じる] を選択して完了します。

T-SQL を使用して接続をテストするには、双方向で接続をチェックする必要があります。まず、SQL ServerからSQL Managed Instanceへの接続をテストしてから、SQL Managed InstanceからSQL Serverへの接続をテストします。

SQL ServerからSQL Managed Instanceへの接続をテストする

SQL ServerのSQL Server エージェントを使用して、SQL ServerからSQL Managed Instanceへの接続テストを実行します。

SQL Managed Instanceに接続し、次のスクリプトを実行して、後で必要になるパラメーターを生成します。

SELECT 'DECLARE @serverName NVARCHAR(512) = N''' + value + ''''
FROM sys.dm_hadr_fabric_config_parameters
WHERE parameter_name = 'DnsRecordName'

UNION

SELECT 'DECLARE @node NVARCHAR(512) = N''' + NodeName + '.' + Cluster + ''''
FROM (
    SELECT SUBSTRING(replica_address, 0, CHARINDEX('\', replica_address)) AS NodeName,
        RIGHT(service_name, CHARINDEX('/', REVERSE(service_name)) - 1) AppName,
        JoinCol = 1
    FROM sys.dm_hadr_fabric_partitions fp
    INNER JOIN sys.dm_hadr_fabric_replicas fr
        ON fp.partition_id = fr.partition_id
    INNER JOIN sys.dm_hadr_fabric_nodes fn
        ON fr.node_name = fn.node_name
    WHERE service_name LIKE '%ManagedServer%'
        AND replica_role = 2
) t1
LEFT JOIN (
    SELECT value AS Cluster,
        JoinCol = 1
    FROM sys.dm_hadr_fabric_config_parameters
    WHERE parameter_name = 'ClusterName'
    ) t2
    ON (t1.JoinCol = t2.JoinCol)
INNER JOIN (
    SELECT [value] AS AppName
    FROM sys.dm_hadr_fabric_config_parameters
    WHERE section_name = 'SQL'
        AND parameter_name = 'InstanceName'
    ) t3
    ON (t1.AppName = t3.AppName)

UNION

SELECT 'DECLARE @port NVARCHAR(512) = N''' + value + ''''
FROM sys.dm_hadr_fabric_config_parameters
WHERE parameter_name = 'HadrPort';

結果は次の例のようになります。

 DECLARE @node NVARCHAR(512) = N'DB123.tr123456.west-us.worker.database.windows.net'
 DECLARE @port NVARCHAR(512) = N'11002'
 DECLARE @serverName NVARCHAR(512) = N'contoso-instance.12345678.database.windows.net'

結果を保存し、次の手順に使用します。これらのパラメーターはフェールオーバー後に変更される可能性があるため、必要に応じて再度生成してください。

SQL Server インスタンスに接続します。

新しいクエリウィンドウを開き、次のスクリプトを貼り付けます。

--START
-- Parameters section
DECLARE @node NVARCHAR(512) = N''
DECLARE @port NVARCHAR(512) = N''
DECLARE @serverName NVARCHAR(512) = N''

--Script section
IF EXISTS (
        SELECT job_id
        FROM msdb.dbo.sysjobs_view
        WHERE name = N'TestMILinkConnection'
        )
    EXEC msdb.dbo.sp_delete_job @job_name = N'TestMILinkConnection',
        @delete_unused_schedule = 1

DECLARE @jobId BINARY (16),
    @cmd NVARCHAR(MAX)

EXEC msdb.dbo.sp_add_job @job_name = N'TestMILinkConnection',
    @enabled = 1,
    @job_id = @jobId OUTPUT

SET @cmd = (N'tnc ' + @serverName + N' -port 5022 | select ComputerName, RemoteAddress, TcpTestSucceeded | Format-List')

EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
    @step_name = N'Test Port 5022',
    @step_id = 1,
    @cmdexec_success_code = 0,
    @on_success_action = 3,
    @on_fail_action = 3,
    @subsystem = N'PowerShell',
    @command = @cmd,
    @database_name = N'master'

SET @cmd = (N'tnc ' + @node + N' -port ' + @port + ' | select ComputerName, RemoteAddress, TcpTestSucceeded | Format-List')

EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
    @step_name = N'Test HADR Port',
    @step_id = 2,
    @cmdexec_success_code = 0,
    @subsystem = N'PowerShell',
    @command = @cmd,
    @database_name = N'master'

EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId,
    @server_name = N'(local)'
GO

EXEC msdb.dbo.sp_start_job @job_name = N'TestMILinkConnection'
GO

--Check status every 5 seconds
DECLARE @RunStatus INT

SET @RunStatus = 10

WHILE (@RunStatus >= 4)
BEGIN
    SELECT DISTINCT @RunStatus = run_status
    FROM [msdb].[dbo].[sysjobhistory] JH
    INNER JOIN [msdb].[dbo].[sysjobs] J
        ON JH.job_id = J.job_id
    WHERE J.name = N'TestMILinkConnection'
        AND step_id = 0

    WAITFOR DELAY '00:00:05';
END

--Get logs once job completes
SELECT [step_name],
    SUBSTRING([message], CHARINDEX('TcpTestSucceeded', [message]), CHARINDEX('Process Exit', [message]) - CHARINDEX('TcpTestSucceeded', [message])) AS    TcpTestResult,
    SUBSTRING([message], CHARINDEX('RemoteAddress', [message]), CHARINDEX('TcpTestSucceeded', [message]) - CHARINDEX('RemoteAddress', [message])) AS    RemoteAddressResult,
    [run_status],
    [run_duration],
    [message]
FROM [msdb].[dbo].[sysjobhistory] JH
INNER JOIN [msdb].[dbo].[sysjobs] J
    ON JH.job_id = J.job_id
WHERE J.name = N'TestMILinkConnection'
    AND step_id <> 0
    --END

@node、@port、および @serverName のパラメーターを、最初の手順で取得した値に置き換えます。
スクリプトを実行し、結果を確認します。次の例のような結果が表示されるはずです。
結果を確認します。
- TcpTestSucceeded での各テストの結果は TcpTestSucceeded : True である必要があります。
- RemoteAddresses は、SQL Managed Instance サブネットの IP 範囲に属している必要があります。
応答が失敗である場合は、次のネットワーク設定について確認します。
- SQL Server ホスト OS (Windows/Linux) ファイアウォールとネットワークファイアウォールの両方に、SQL Managed Instance のサブネット IP 範囲全体へのトラフィックを許可する規則があります。
- SQL Managed Instanceをホストする仮想ネットワークのポート 5022 での通信を許可する NSG 規則があります。

SQL Managed InstanceからSQL Serverへの接続をテストする

SQL Managed InstanceがSQL Serverに到達できることを確認するには、まずテストエンドポイントを作成します。次に、SQL Server エージェントを使用して、tnc コマンドを使用して、SQL マネージドインスタンスからポート 5022 でSQL Server ping を実行する PowerShell スクリプトを実行します。

テストエンドポイントを作成するには、SQL Serverに接続し、次の T-SQL スクリプトを実行します。

-- Run on SQL Server
-- Create the certificate needed for the test endpoint
USE MASTER
CREATE CERTIFICATE TEST_CERT
WITH SUBJECT = N'Certificate for SQL Server',
EXPIRY_DATE = N'3/30/2051'
GO

-- Create the test endpoint on SQL Server
USE MASTER
CREATE ENDPOINT TEST_ENDPOINT
    STATE=STARTED
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE TEST_CERT,
        ENCRYPTION = REQUIRED ALGORITHM AES
    )

SQL Server エンドポイントがポート 5022 で接続を受信していることを確認するには、SQL Server インスタンスのホストオペレーティングシステムで次の PowerShell コマンドを実行します。

tnc localhost -port 5022

テストが成功すると、TcpTestSucceeded : True と表示されます。その後、SQL マネージドインスタンスでSQL Server エージェントジョブの作成に進み、SQL マネージドインスタンスからポート 5022 でSQL Server テストエンドポイントのテストを試すことができます。

次に、SQL マネージドインスタンスで次の T-SQL スクリプトを実行して、NetHelper という SQL マネージドインスタンスにSQL Server エージェントジョブを作成します。置換してください。

sql マネージドインスタンスからアクセスできるSQL Serverの IP アドレスを持つ <SQL_SERVER_IP_ADDRESS>。

-- Run on SQL managed instance
-- SQL_SERVER_IP_ADDRESS should be an IP address that could be accessed from the SQL Managed Instance host machine.
DECLARE @SQLServerIpAddress NVARCHAR(MAX) = '<SQL_SERVER_IP_ADDRESS>'; -- insert your SQL Server IP address in here
DECLARE @tncCommand NVARCHAR(MAX) = 'tnc ' + @SQLServerIpAddress + ' -port 5022 -InformationLevel Quiet';
DECLARE @jobId BINARY(16);

IF EXISTS (
        SELECT *
        FROM msdb.dbo.sysjobs
        WHERE name = 'NetHelper'
        ) THROW 70000,
    'Agent job NetHelper already exists. Please rename the job, or drop the existing job before creating it again.',
    1
    -- To delete NetHelper job run: EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper'
    EXEC msdb.dbo.sp_add_job @job_name = N'NetHelper',
        @enabled = 1,
        @description = N'Test SQL Managed Instance to SQL Server network connectivity on port 5022.',
        @category_name = N'[Uncategorized (Local)]',
        @owner_login_name = N'sa',
        @job_id = @jobId OUTPUT;

EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
    @step_name = N'TNC network probe from SQL MI to SQL Server',
    @step_id = 1,
    @os_run_priority = 0,
    @subsystem = N'PowerShell',
    @command = @tncCommand,
    @database_name = N'master',
    @flags = 40;

EXEC msdb.dbo.sp_update_job @job_id = @jobId,
    @start_step_id = 1;

EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId,
    @server_name = N'(local)';

ヒント

SQL マネージドインスタンスから接続プローブのSQL Serverの IP アドレスを変更する必要がある場合は、EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper' を実行して NetHelper ジョブを削除し、前のスクリプトを使用して NetHelper ジョブを再作成します。

次に、ジョブの実行に役立つストアドプロシージャ ExecuteNetHelper を作成し、ネットワークプローブから結果を取得します。 SQL マネージドインスタンスで次の T-SQL スクリプトを実行します。

-- Run on managed instance
IF EXISTS(SELECT * FROM sys.objects WHERE name = 'ExecuteNetHelper')
    THROW 70001, 'Stored procedure ExecuteNetHelper already exists. Rename or drop the existing procedure before creating it again.', 1
GO
CREATE PROCEDURE ExecuteNetHelper AS
-- To delete the procedure run: DROP PROCEDURE ExecuteNetHelper
BEGIN
    -- Start the job.
    DECLARE @NetHelperstartTimeUtc DATETIME = GETUTCDATE();
    DECLARE @stop_exec_date DATETIME = NULL;

    EXEC msdb.dbo.sp_start_job @job_name = N'NetHelper';

    -- Wait for job to complete and then see the outcome.
    WHILE (@stop_exec_date IS NULL)
    BEGIN
        -- Wait and see if the job has completed.
        WAITFOR DELAY '00:00:01'

        SELECT @stop_exec_date = sja.stop_execution_date
        FROM msdb.dbo.sysjobs sj
        INNER JOIN msdb.dbo.sysjobactivity sja
            ON sj.job_id = sja.job_id
        WHERE sj.name = 'NetHelper'

        -- If job has completed, get the outcome of the network test.
        IF (@stop_exec_date IS NOT NULL)
        BEGIN
            SELECT sj.name JobName,
                sjsl.date_modified AS 'Date executed',
                sjs.step_name AS 'Step executed',
                sjsl.log AS 'Connectivity status'
            FROM msdb.dbo.sysjobs sj
            LEFT JOIN msdb.dbo.sysjobsteps sjs
                ON sj.job_id = sjs.job_id
            LEFT JOIN msdb.dbo.sysjobstepslogs sjsl
                ON sjs.step_uid = sjsl.step_uid
            WHERE sj.name = 'NetHelper'
        END

        -- In case of operation timeout (90 seconds), print timeout message.
        IF (datediff(second, @NetHelperstartTimeUtc, getutcdate()) > 90)
        BEGIN
            SELECT 'NetHelper timed out during the network check. Please investigate SQL Agent logs for more information.'

            BREAK;
        END
    END
END;

SQL マネージドインスタンスで次のクエリを実行します。これにより、NetHelper エージェントジョブを実行して結果のログを表示するストアドプロシージャが実行されます。

-- Run on managed instance
EXEC ExecuteNetHelper;

接続が成功すると、ログに True が表示されます。接続が失敗すると、ログに False が表示されます。

NetHelper SQL Agent ジョブの期待される出力を示すスクリーンショット。

接続が失敗である場合は、以下の項目について確認します。

ホスト SQL Server インスタンス上のファイアウォールでは、ポート 5022 での受信と送信の通信が許可されます。
SQL Managed Instanceホストする仮想ネットワークの NSG 規則により、ポート 5022 での通信が許可されます。
SQL Server インスタンスがAzure VM 上にある場合、NSG ルールでは、VM をホストする仮想ネットワーク上のポート 5022 での通信が許可されます。
SQL Serverが実行されています。
SQL Serverにテストエンドポイントが存在します。

問題を解決したら、マネージドインスタンス上で EXEC ExecuteNetHelper を実行して NetHelper ネットワークプローブを再実行します。

最後に、ネットワークテストが成功したら、次の T-SQL コマンドを使用して、SQL Serverでテストエンドポイントと証明書を削除します。

-- Run on SQL Server
DROP ENDPOINT TEST_ENDPOINT;
GO
DROP CERTIFICATE TEST_CERT;
GO

注意事項

次の手順に進むのは、ソース環境とターゲット環境の間のネットワーク接続を検証済みの場合だけにしてください。それ以外の場合は、進める前に、ネットワーク接続の問題のトラブルシューティングを行ってください。

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でサポートされます。

SSMS のインストールする

SQL Server Management Studio (SSMS) は、Managed Instance リンクを使用する最も簡単な方法です。クライアントコンピューターに最新バージョンの SQL Server Management Studio (SSMS) をインストールします。

インストールが完了したら、SSMS を開き、サポートされているSQL Server インスタンスに接続します。ユーザーデータベースを右クリックし、メニューに Azure SQL Managed Instance link オプションが表示されていることを確認します。

政府機関向けクラウド用に SSMS を構成する

SQL Managed Instanceを政府機関向けクラウドにデプロイする場合は、適切なクラウドを使用するように SQL Server Management Studio (SSMS) 設定を変更する必要があります。 SQL Managed Instanceを政府機関向けクラウドにデプロイしていない場合は、この手順をスキップします。

SSMS の設定を更新するには、次の手順のようにします。

SSMS を開きます。
メニューから [ツール] を選んだ後、[オプション] を選びます。
Azure Services を展開し、 Azure Cloud を選択します。
[Azure クラウドの選択で、ドロップダウンリストを使用して AzureUSGovernment、または別の政府機関向けクラウド (AzureChinaCloud。

AZURE クラウドが強調表示された SSMS UI、オプションページ、Azure サービスのスクリーンショット。

パブリッククラウドに戻る場合は、ドロップダウンリストから [AzureCloud] を選びます。

リンクを使用するには、次の操作を実行します。

リンクの詳細については、以下を参照してください。

他のレプリケーションおよび移行シナリオについては、以下を検討してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-04-14