Problemlösungslink – Azure SQL Managed Instance

Gilt für:Azure SQL Managed Instance

In diesem Artikel erfahren Sie, wie Sie eine -Verknüpfung zwischen SQL Server und Azure SQL Managed Instance überwachen und Probleme beheben können.

Sie können den Status des Links mit Transact-SQL (T-SQL), Azure PowerShell oder der Azure CLI überprüfen. Wenn Probleme auftreten, können Sie die Fehlercodes verwenden, um das Problem zu beheben.

Viele Probleme beim Erstellen der Verbindung können behoben werden, indem das Netzwerk zwischen den beiden Instanzen überprüft und die Umgebung für die Verbindung ordnungsgemäß vorbereitet wurde.

Anfängliches Seeding

Beim Einrichten einer Verbindung zwischen SQL Server und azure SQL Managed Instance gibt es eine anfängliche Seedingphase, bevor die Datenreplikation beginnt. Die Seedingphase zu Beginn ist der längste und teuerste Teil des Vorgangs. Sobald das anfängliche Seeding abgeschlossen ist, werden die Daten synchronisiert, und nur nachfolgende Datenänderungen werden repliziert. Die Zeit, die für das anfängliche Seeding benötigt wird, ist abhängig von der Größe der Daten, der Intensität der Workloads auf den primären Datenbanken und der Geschwindigkeit der Verbindung zwischen den Netzwerken der primären und der sekundären Replikate.

Wenn die Geschwindigkeit der Verbindung zwischen den beiden Instanzen langsamer als erforderlich ist, wirkt sich dies wahrscheinlich erheblich auf die Zeit für das Seeding aus. Sie können die angegebene Seedinggeschwindigkeit, die Gesamtgröße der Daten und die Verknüpfungsgeschwindigkeit verwenden, um zu schätzen, wie lange die anfängliche Seedingphase dauert, bevor die Datenreplikation beginnt. Bei einer einzelnen Datenbank mit 100 GB würde die anfängliche Startphase etwa 1,2 Stunden dauern, wenn der Link 84 GB pro Stunde pushen kann und keine anderen Datenbanken auf eine andere Verknüpfung gesetzt werden. Wenn über die Verbindung nur 10 GB pro Stunde übertragen werden können, dauert das Seeding einer 100-GB-Datenbank ungefähr 10 Stunden. Wenn mehrere Datenbanken über mehrere Verknüpfungen repliziert werden sollen, wird das Seeding parallel ausgeführt, und in Kombination mit einer langsamen Verbindungsgeschwindigkeit kann die anfängliche Seedingphase erheblich länger dauern, insbesondere, wenn das parallele Seeding von Daten aus allen Datenbanken die verfügbare Linkbandbreite überschreitet.

Die anfängliche Seedingphase ist nicht widerstandsfähig für Netzwerkunterbrechungen und Instanzwartungs- oder Failovervorgänge. Wenn die bidirektionale Konnektivität zwischen SQL Server und SQL Managed Instance vorübergehend verloren geht oder die SQL Server- oder SQL Managed-Instanz während der ersten Seedingphase neu gestartet oder fehlerhaft ist, wird das Seeding erneut gestartet.

Von Bedeutung

Die anfängliche Phase des Seedings kann bei extrem niedrigen Geschwindigkeiten oder stark beanspruchten Verbindungen Tage dauern. In diesem Fall kann beim Erstellen der Verbindung eine Zeitüberschreitung auftreten. Das Erstellen der Verbindung wird nach 6 Tagen automatisch abgebrochen.

Überprüfen des Verknüpfungszustands

Wenn Probleme mit einem Link auftreten, können Sie SQL Server Management Studio (SSMS), Transact-SQL (T-SQL), Azure PowerShell oder die Azure CLI verwenden, um Informationen zum aktuellen Status des Links abzurufen.

Verwenden Sie T-SQL für schnelle Statusdetails des Verknüpfungszustands, und verwenden Sie dann Azure PowerShell oder die Azure CLI, um umfassende Informationen zum aktuellen Status des Links zu erhalten.

Die Linküberwachung ist ab SQL Server Management Studio (SSMS) 21.0 (Vorschau) verfügbar.

Führen Sie die folgenden Schritte aus, um den Linkstatus in SSMS zu überprüfen:

Stellen Sie eine Verbindung mit einem Replikat her, das den Link hosten soll.
Erweitern Sie im Objekt-Explorer den Eintrag Hochverfügbarkeit mit Always On, und erweitern Sie dann Verfügbarkeitsgruppen.
Klicken Sie mit der rechten Maustaste auf den Namen des Links, und wählen Sie dann "Eigenschaften " aus, um das Fenster " Verknüpfungseigenschaften " zu öffnen:
Im Fenster " Verknüpfungseigenschaften " werden nützliche Informationen zum Link angezeigt, z. B. Replikatinformationen, Linkstatus und Ablaufdatum des Endpunktzertifikats:

Verwenden Sie T-SQL, um den Zustand der Verknüpfung während der Seedingphase oder nach Beginn der Datensynchronisierung zu bestimmen.

Verwenden Sie die folgende T-SQL-Abfrage, um den Status der Verbindung während der Seedingphase in der Instanz von SQL Server oder SQL Managed Instance zu ermitteln, auf der die Datenbank gehostet wird, die über die Verbindung geseedet wurde:

SELECT
    ag.local_database_name AS 'Local database name',
    ar.current_state AS 'Current state',
    ar.is_source AS 'Is source',
    ag.internal_state_desc AS 'Internal state desc',
    ag.database_size_bytes / 1024 / 1024 AS 'Database size MB',
    ag.transferred_size_bytes / 1024 / 1024 AS 'Transferred MB',
    ag.transfer_rate_bytes_per_second / 1024 / 1024 AS 'Transfer rate MB/s',
    ag.total_disk_io_wait_time_ms / 1000 AS 'Total Disk IO wait (sec)',
    ag.total_network_wait_time_ms / 1000 AS 'Total Network wait (sec)',
    ag.is_compression_enabled AS 'Compression',
    ag.start_time_utc AS 'Start time UTC',
    ag.estimate_time_complete_utc as 'Estimated time complete UTC',
    ar.completion_time AS 'Completion time',
    ar.number_of_attempts AS 'Attempt No'
FROM sys.dm_hadr_physical_seeding_stats AS ag
    INNER JOIN sys.dm_hadr_automatic_seeding AS ar
    ON local_physical_seeding_id = operation_id

-- Estimated seeding completion time
SELECT DISTINCT CONVERT(VARCHAR(8), DATEADD(SECOND, DATEDIFF(SECOND, start_time_utc, estimate_time_complete_utc) ,0), 108) as 'Estimated complete time'
FROM sys.dm_hadr_physical_seeding_stats

Wenn die Abfrage keine Ergebnisse zurückgibt, wurde der Seedingprozess nicht gestartet oder ist bereits abgeschlossen.

Verwenden Sie die folgende T-SQL-Abfrage in der primären Instanz, um die Integrität des Links zu überprüfen, sobald die Synchronisierung beginnt:

DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   rs.synchronization_health_desc [Link sync health]
FROM
   sys.availability_groups ag 
   join sys.dm_hadr_availability_replica_states rs 
   on ag.group_id = rs.group_id 
WHERE 
   rs.is_local = 0 AND rs.role = 2 AND ag.is_distributed = 1 AND ag.name = @link_name 
GO

Die Abfrage gibt die folgenden möglichen Werte zurück:

kein Ergebnis: Die Abfrage wurde in der sekundären Instanz ausgeführt.
HEALTHY: Die Verknüpfung ist fehlerfrei, und Daten werden zwischen den Replikaten synchronisiert.
NOT_HEALTHY: Die Verbindung ist fehlerhaft, und Daten werden nicht zwischen den Replikaten synchronisiert.

Verwenden Sie Get-AzSqlInstanceLink, um Linkstatusinformationen mit PowerShell abzurufen.

Führen Sie den folgenden Beispielcode in Azure Cloud Shell aus, oder installieren Sie das Az.SQL Modul lokal.

$ManagedInstanceName = "<ManagedInstanceName>" # The name of your linked SQL Managed Instance
$DAGName = "<DAGName>" # distributed availability group name

# Find out the resource group name 
$ResourceGroupName = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName 

# Show link state details 
(Get-AzSqlInstanceLink -ResourceGroupName $ResourceGroupName -InstanceName $ManagedInstanceName -Name $DAGName).Databases

Verwenden Sie az sql mi link show, um Verbindungsstatusinformationen mit der Azure CLI abzurufen.

# type "az" to use Azure CLI
managedInstanceName = "<ManagedInstanceName>" # The name of your linked SQL Managed Instance
dagName = "<DAGName>" # distributed availability group name
rgName = "<RGName>" # the resource group for the linked SQL Managed Instance  

# Print link state details 
az sql mi link show –-resource-group $rgName –-instance-name $managedInstanceName –-name $dagName

Der Wert replicaState beschreibt den aktuellen Link. Wenn der Zustand auch Error enthält, ist während des im Zustand aufgeführten Vorgangs ein Fehler aufgetreten. Beispielsweise gibt LinkCreationError an, dass beim Erstellen der Verknüpfung ein Fehler aufgetreten ist.

Einige mögliche replicaState-Werte sind:

CreatingLink: erstes Seeding
LinkSynchronizing: Die Datenreplikation wird durchgeführt.
LinkFailoverInProgress: Failover wird ausgeführt

Eine vollständige Liste der Verbindungsstatuseigenschaften erhalten Sie mit dem REST-API-Befehl Verteilte Verfügbarkeitsgruppen – GET.

Fehler mit dem Link

Es gibt zwei verschiedene Kategorien von Fehlern, die beim Verwenden des Links auftreten können: Fehler, wenn Sie versuchen, den Link zu initialisieren, und Fehler, wenn Sie versuchen, den Link zu erstellen.

Fehler beim Initialisieren einer Verbindung: sql-server-2016-database-engine-events-and-errors-1000-1999

Der folgende Fehler kann beim Initialisieren eines Links auftreten (Linkstatus: LinkInitError):

Fehler 41962: Vorgang abgebrochen, da der Link innerhalb von 5 Minuten nicht hergestellt wurde. Überprüfen Sie die Netzwerkkonnektivität, und versuchen Sie es erneut.
Fehler 41973: Verbindung kann nicht hergestellt werden, da das Endpunktzertifikat von SQL Server nicht ordnungsgemäß in Azure SQL Managed Instance importiert wurde.
Fehler 41974: Verbindung kann nicht hergestellt werden, da das Endpunktzertifikat von der verwalteten SQL-Instanz nicht ordnungsgemäß in SQL Server importiert wurde.
Fehler 41976: Die Verfügbarkeitsgruppe reagiert nicht. Überprüfen Sie Namen und Konfigurationsparameter, und versuchen Sie es erneut.
Fehler 41986: Verknüpfung kann nicht hergestellt werden, da die Verbindung fehlgeschlagen ist oder das sekundäre Replikat nicht reagiert. Überprüfen Sie Namen, Konfigurationsparameter und Netzwerkkonnektivität, und versuchen Sie es dann erneut.
Fehler 47521: Verknüpfung kann nicht hergestellt werden, da der sekundäre Server die Anforderung nicht empfangen hat. Stellen Sie sicher, dass die Verfügbarkeitsgruppe und Datenbanken auf dem primären Server fehlerfrei sind, und versuchen Sie es erneut.

Fehler beim Erstellen eines Links

Die folgenden Fehler können beim Erstellen eines Links auftreten (Linkstatus: LinkCreationError):

Fehler 41977: Die Zieldatenbank reagiert nicht. Überprüfen Sie die Linkparameter, und versuchen Sie es erneut.
Vorzeitiges Kürzen des Protokolls: Wenn das Transaktionsprotokoll vor dem Ende des anfänglichen Seedings gekürzt wird, wird wahrscheinlich einer der folgenden Fehler angezeigt:
- Fehler 1408: Die Remotekopie der Datenbank "%.*ls" wird nicht weit genug wiederhergestellt, um die Datenbankspiegelung zu aktivieren oder der Verfügbarkeitsgruppe beizutreten.
- Fehler 1412: Für die Remotekopie der „%.*ls“-Datenbank wurde kein Rollforward bis zu einem Zeitpunkt ausgeführt, der in der lokalen Kopie des Datenbankprotokolls enthalten ist.
Um dieses Problem zu beheben, müssen Sie den Link löschen und neu erstellen.
Um dieses Problem zu vermeiden, unterbrechen Sie Transaktionsprotokollsicherungen auf SQL Server, damit die Datenbank während der ersten Seedingphase repliziert wird.

Inkonsistenter Zustand nach erzwungenem Failover

Nach einem erzwungenen Failover kann ein Split Brain-Szenario auftreten, bei dem sich beide Replikate in der primären Rolle befinden und die Verbindung in einem inkonsistenten Zustand bleibt. Dies kann passieren, wenn Sie während einer Katastrophe auf das sekundäre Replikat umschalten und das primäre Replikat wieder online geht.

Vergewissern Sie sich zunächst, dass Sie es sich um ein Split Brain-Szenario handelt. Dazu können Sie SQL Server Management Studio (SSMS) oder Transact-SQL (T-SQL) verwenden.

Stellen Sie eine Verbindung mit SQL Server und SQL Managed Instance in SSMS her, und erweitern Sie dann im Objekt-Explorer die Option Verfügbarkeitsreplikate unter dem Knoten Verfügbarkeitsgruppe in Hochverfügbarkeit mit Always On. Wenn zwei verschiedene Replikate als (Primary) aufgeführt werden, handelt es sich um ein Split Brain-Szenario.

Alternativ können Sie das folgende T-SQL-Skript sowohl auf SQL Server als auch auf SQL Managed Instance ausführen, um die Rolle der Replikas zu überprüfen.

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGName>'
SELECT
   ag.name [Link name], 
   rs.role_desc [Link role] 
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states rs 
   ON ag.group_id = rs.group_id 
WHERE 
   rs.is_local = 1 AND ag.is_distributed = 1 AND ag.name = @link_name 
GO

Wenn für beide Instanzen PRIMARY in der Spalte Verbindungsrolle steht, handelt es sich um ein Split Brain-Szenario.

Um den Split Brain-Zustand aufzuheben, führen Sie zuerst eine Sicherung des Replikats durch, das ursprünglich über die primäre Rolle verfügte. Wenn es sich bei der ursprünglichen primären Instanz um SQL Server handelt, führen Sie eine Sicherung des Protokollfragments durch. Wenn die ursprüngliche primäre Instanz eine Instanz von SQL Managed Instance war, führen Sie eine vollständige Kopiesicherung durch. Nachdem die Sicherung abgeschlossen ist, setzen Sie die verteilte Verfügbarkeitsgruppe auf die sekundäre Rolle für das Replikat fest, das ursprünglich die primäre Rolle innehatte, nun aber die neue sekundäre Rolle übernehmen wird.

Wenn Sie ein Failover Ihrer SQL Server-Arbeitsauslastung zu Azure SQL Managed Instance erzwungen haben und beabsichtigen, die Arbeitsauslastung weiterhin in SQL Managed Instance auszuführen, führen Sie bei einem tatsächlichen Notfall eine Sicherung des Protokollfragments auf SQL Server durch, und legen Sie dann wie im folgenden Beispiel für die verteilte Verfügbarkeitsgruppe die sekundäre Rolle auf SQL Server fest:

--Execute on SQL Server 
USE master
ALTER AVAILABILITY GROUP [<DAGName>] 
SET (ROLE = SECONDARY) 
GO

Führen Sie als Nächstes ein geplantes manuelles Failover von SQL Managed Instance zu SQL Server mithilfe des Links aus, z. B. das folgende Beispiel:

--Execute on SQL Managed Instance 
USE master
ALTER AVAILABILITY GROUP [<DAGName>] FAILOVER 
GO

Abgelaufenes Zertifikat

Es ist möglich, dass das Zertifikat, das für den Link verwendet wird, abläuft. Wenn das Zertifikat abläuft, schlägt der Link fehl. Um dieses Problem zu beheben, erneuern Sie das Zertifikat.

Netzwerkkonnektivität testen

Bidirektionale Netzwerkkonnektivität zwischen SQL Server und SQL Managed Instance ist erforderlich, damit die Verbindung funktioniert. Nachdem Sie Ports auf der SQL Server-Seite geöffnet und eine NSG-Regel auf der Sql Managed Instance-Seite konfiguriert haben, testen Sie die Konnektivität entweder mithilfe von SQL Server Management Studio (SSMS) oder Transact-SQL.

Testen Sie das Netzwerk, indem Sie einen temporären SQL-Agent-Auftrag sowohl in SQL Server als auch in sql Managed Instance erstellen, um die Verbindung zwischen den beiden Instanzen zu überprüfen. Wenn Sie die Netzwerküberprüfung in SSMS verwenden, wird der Auftrag automatisch für Sie erstellt und nach Abschluss des Tests gelöscht. Sie müssen den SQL-Agent-Auftrag manuell löschen, wenn Sie Ihr Netzwerk mithilfe von T-SQL testen.

Anmerkung

Das Ausführen von PowerShell-Skripts durch den SQL Server-Agent unter SQL Server unter Linux wird derzeit nicht unterstützt, sodass es derzeit nicht möglich ist, Test-NetConnection aus dem SQL Server-Agent-Auftrag auf SQL Server unter Linux auszuführen.

Um den SQL-Agent zum Testen der Netzwerkkonnektivität zu verwenden, benötigen Sie die folgenden Anforderungen:

Die testende Person muss über Berechtigungen zum Erstellen eines Auftrags sowohl für SQL Server als auch für SQL Managed Instance verfügen – entweder als sysadmin oder mit der SQLAgentOperator-Rolle für msdb.
Der SQL Server-Agent-Dienst muss auf SQL Server ausgeführt werden. Da der Agent standardmäßig in SQL Managed Instance aktiviert ist, ist keine zusätzliche Aktion erforderlich.

Beachte Folgendes:

Um falsch negative Ergebnisse zu vermeiden, müssen alle Firewalls entlang des Netzwerkpfads Internet Control Message Protocol (ICMP)-Datenverkehr zulassen.
Um falsch positive Ergebnisse zu vermeiden, müssen alle Firewalls entlang des Netzwerkpfads Datenverkehr im proprietären SQL Server UCS-Protokoll zulassen. Das Blockieren des Protokolls kann zu einem erfolgreichen Verbindungstest führen, aber der Link kann nicht erstellt werden.
Erweiterte Firewall-Setups mit Schutzmaßnahmen auf Paketebene müssen korrekt konfiguriert werden, um den Datenverkehr zwischen SQL Server und SQL Managed Instance zu ermöglichen.

SSMS
T-SQL

Führen Sie die folgenden Schritte aus, um die Netzwerkkonnektivität zwischen SQL Server und SQL Managed Instance in SSMS zu testen:

Stellen Sie eine Verbindung mit der Instanz her, die als primäres Replikat in SSMS dient.
Erweitern Sie im Objekt-Explorerdie Datenbanken, und klicken Sie mit der rechten Maustaste auf die Datenbank, die Sie mit der sekundären Datenbank verknüpfen möchten. Wählen Sie Aufgaben>Azure SQL Managed Instance-Verbindung>Testverbindung aus, um den Assistenten für die Netzwerküberprüfung zu öffnen:
Wählen Sie Weiter auf der Seite Einführung des Assistenten für die Netzwerküberprüfung aus.
Wenn alle Anforderungen auf der Seite Voraussetzungen erfüllt sind, wählen Sie Weiter aus. Sorgen Sie andernfalls dafür, dass allen nicht erfüllten Voraussetzungen entsprochen wird, und wählen Sie dann Überprüfung erneut ausführen aus.
Wählen Sie auf der Seite AnmeldenAnmelden aus, um eine Verbindung mit einer anderen Instanz herzustellen, die als sekundäres Replikat dient. Wählen Sie Weiter aus.
Überprüfen Sie die Details auf der Seite "Netzwerkoptionen angeben" und geben Sie ggf. eine IP-Adresse an. Wählen Sie Weiter aus.
Überprüfen Sie auf der Seite Ergebnisse die Aktionen, die der Assistent ausführt, und wählen Sie dann Fertig stellen aus, um die Verbindung zwischen den beiden Replikaten zu testen.
Überprüfen Sie die Seite Ergebnisse, um die Konnektivität zwischen den beiden Replikaten zu überprüfen, und wählen Sie dann Schließen aus, um den Vorgang zu beenden.

Um T-SQL zum Testen der Konnektivität zu verwenden, müssen Sie die Verbindung in beide Richtungen überprüfen. Testen Sie zunächst die Verbindung von SQL Server zu SQL Managed Instance, und testen Sie dann die Verbindung von SQL Managed Instance zu SQL Server.

Verbindung von SQL Server zu SQL Managed Instance testen

Verwenden Sie den SQL Server-Agent auf SQL Server, um Verbindungstests von SQL Server zu SQL Managed Instance auszuführen.

Stellen Sie eine Verbindung mit der verwalteten SQL-Instanz her, und führen Sie das folgende Skript aus, um parameter zu generieren, die Sie später benötigen:

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';

Die Ergebnisse sollten wie im folgenden Beispiel aussehen:

 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'

Speichern Sie die Ergebnisse, um sie in den nächsten Schritten zu verwenden. Da sich diese Parameter nach einem Failover ändern können, sollten Sie sie bei Bedarf erneut generieren.

Stellen Sie eine Verbindung mit Ihrer SQL Server-Instanz her.

Öffnen Sie ein neues Abfragefenster, und fügen Sie das folgende Skript ein:

--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

Ersetzen Sie die Parameter @node, @portund @serverName durch die Werte, die Sie aus dem ersten Schritt abgerufen haben.
Führen Sie das Skript aus, und überprüfen Sie die Ergebnisse. Ergebnisse wie das folgende Beispiel sollten angezeigt werden:
Überprüfen Sie die Ergebnisse:
- Das Ergebnis jedes Tests bei TcpTestSucceeded sollte TcpTestSucceeded : Truesein.
- „RemoteAddresses“ sollte zum IP-Adressbereich für das SQL Managed Instance-Subnetz gehören.
Wenn die Antwort nicht erfolgreich ist, überprüfen Sie die folgenden Netzwerkeinstellungen:
- Es gibt Regeln in der Netzwerkfirewall und in der Firewall des SQL Server-Hostbetriebssystems (Windows/Linux), die Datenverkehr an den gesamten IP-Adressbereich des Subnetzes von SQL Managed Instance zulassen.
- Es gibt eine NSG-Regel, die die Kommunikation an Port 5022 für das virtuelle Netzwerk ermöglicht, das SQL Managed Instance hostet.

Testen der Verbindung von SQL Managed Instance zu SQL Server

Um zu überprüfen, ob sql Managed Instance SQL Server erreichen kann, erstellen Sie zuerst einen Testendpunkt. Anschließend verwenden Sie den SQL Server-Agent, um ein PowerShell-Skript mit dem Befehl tnc auszuführen. Dadurch wird SQL Server am Port 5022 von SQL Managed Instance gepingt.

Zum Erstellen eines Testendpunkts stellen Sie eine Verbindung mit SQL Server her, und führen Sie das folgende T-SQL-Skript aus:

-- 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
    )

Um zu überprüfen, ob der SQL Server-Endpunkt Verbindungen auf Port 5022 empfängt, führen Sie den folgenden PowerShell-Befehl auf dem Hostbetriebssystem Ihrer SQL Server-Instanz aus:

tnc localhost -port 5022

Bei einem erfolgreichen Test wird TcpTestSucceeded : True angezeigt. Anschließend können Sie einen SQL Server-Agent-Auftrag in SQL Managed Instance erstellen, um den SQL Server-Testendpunkt am Port 5022 von SQL Managed Instance zu testen.

Erstellen Sie als Nächstes einen SQL Server-Agent-Auftrag in der sql-verwalteten Instanz namens NetHelper, indem Sie das folgende T-SQL-Skript auf der sql-verwalteten Instanz ausführen. Ersetzen Sie Folgendes:

<SQL_SERVER_IP_ADDRESS> durch die IP-Adresse von SQL Server, auf die von SQL Managed Instance aus zugegriffen werden kann

-- 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)';

Tipp

Wenn Sie die IP-Adresse Ihrer SQL Server-Instanz für den Verbindungstest von SQL Managed Instance aus ändern müssen, löschen Sie den NetHelper-Auftrag, indem Sie EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper' ausführen, und erstellen Sie den NetHelper-Auftrag mithilfe des vorherigen Skripts neu.

Erstellen Sie dann eine gespeicherte Prozedur ExecuteNetHelper, mit deren Hilfe Sie den Auftrag ausführen und Ergebnisse vom Netzwerktest erhalten können. Führen Sie das folgende T-SQL-Skript auf der verwalteten SQL-Instanz aus:

-- 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;

Führen Sie die folgende Abfrage für die verwaltete SQL-Instanz aus, um die gespeicherte Prozedur auszuführen, die den NetHelper-Agent-Auftrag ausführt, und zeigen Sie das resultierende Protokoll an:

-- Run on managed instance
EXEC ExecuteNetHelper;

Wenn die Verbindung erfolgreich war, wird im Protokoll Trueangezeigt. Wenn die Verbindung nicht erfolgreich war, wird im Protokoll Falseangezeigt.

Screenshot: die erwartete Ausgabe des Auftrags des NetHelper-SQL-Agents

Wenn die Verbindung nicht erfolgreich war, überprüfen Sie die folgenden Elemente:

Die Firewall auf der Host-SQL Server-Instanz ermöglicht die eingehende und ausgehende Kommunikation an Port 5022.
Eine NSG-Regel für das virtuelle Netzwerk, das SQL Managed Instance hostet, ermöglicht die Kommunikation an Port 5022.
Wenn sich Ihre SQL Server-Instanz auf einer Azure-VM befindet, ermöglicht eine NSG-Regel die Kommunikation über Port 5022 im virtuellen Netzwerk, das die VM hostet.
SQL Server läuft.
Es gibt einen Test-Endpunkt auf dem SQL Server.

Führen Sie nach dem Beheben von Problemen die NetHelper-Netzwerksonde erneut aus, indem Sie EXEC ExecuteNetHelper auf verwalteter Instanz ausführen.

Nachdem der Netzwerktest erfolgreich war, entfernen Sie den Testendpunkt und das Zertifikat auf dem SQL Server mit den folgenden T-SQL-Befehlen:

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

Vorsicht

Fahren Sie mit den nächsten Schritten nur fort, wenn Sie die Netzwerkkonnektivität zwischen Ihrer Quell- und Zielumgebung überprüft haben. Andernfalls beheben Sie Probleme mit der Netzwerkkonnektivität, bevor Sie fortfahren.

Weitere Informationen zum Linkfeature finden Sie in den folgenden Ressourcen:

Feedback

War diese Seite hilfreich?

Last updated on 2025-05-06