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.
Wenn Probleme mit einem Link auftreten, können Sie 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.
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.
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 eines Links
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 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
Der folgende Fehler kann beim Erstellen eines Links auftreten (Linkstatus: LinkCreationError):
Fehler 41977: Die Zieldatenbank reagiert nicht. Überprüfen Sie die Linkparameter, und versuchen Sie es erneut.
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
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.
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:
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.
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.
Verwandte Inhalte
Weitere Informationen zum Linkfeature finden Sie in den folgenden Ressourcen:
Azure SQL Managed Instance
