In dit artikel leert u hoe u problemen kunt bewaken en oplossen met een koppeling tussen SQL Server en Azure SQL Managed Instance.
U kunt de status van de koppeling controleren met Transact-SQL (T-SQL), Azure PowerShell of de Azure CLI. Als u problemen ondervindt, kunt u de foutcodes gebruiken om het probleem op te lossen.
Veel problemen met het maken van de koppeling kunnen worden opgelost door het netwerk tussen de twee exemplaren te controleren en te valideren dat de -omgeving goed is voorbereid voor de koppeling.
Koppelingsstatus controleren
Als u problemen ondervindt met een koppeling, kunt u Transact-SQL (T-SQL), Azure PowerShell of de Azure CLI gebruiken om informatie over de huidige status van de koppeling op te halen.
Gebruik T-SQL voor een snelle status van de koppelingsstatus en gebruik vervolgens Azure PowerShell of de Azure CLI voor uitgebreide informatie over de huidige status van de koppeling.
Gebruik T-SQL om de status van de koppeling te bepalen tijdens de seedingfase of nadat de gegevenssynchronisatie is gestart.
Gebruik de volgende T-SQL-query om de status van de koppeling te bepalen tijdens de seedingfase op de SQL Server of SQL Managed Instance die als host fungeert voor de database die via de koppeling wordt geseed:
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
Als de query geen resultaten retourneert, is het seedingproces niet gestart of is het al voltooid.
Gebruik de volgende T-SQL-query op het primaire-exemplaar om de status van de koppeling te controleren zodra de gegevenssynchronisatie is gestart:
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
De query retourneert de volgende mogelijke waarden:
geen resultaat: de query is uitgevoerd op het secundaire exemplaar.
HEALTHY: de koppeling is in orde en gegevens worden gesynchroniseerd tussen de replica's.
NOT_HEALTHY: de koppeling is beschadigd en gegevens worden niet gesynchroniseerd tussen de replica's.
Gebruik Get-AzSqlInstanceLink om statusinformatie over koppelingen op te halen met PowerShell.
Voer de volgende voorbeeldcode uit in Azure Cloud Shell of installeer de Az.SQL-module lokaal.
$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
Gebruik az sql mi link show om informatie over de linkstatus te verkrijgen met de Azure CLI.
# 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
In de replicaState waarde wordt de huidige koppeling beschreven. Als de status ook Fout bevat, is er een fout opgetreden tijdens de bewerking die wordt vermeld in de status. Bijvoorbeeld, LinkCreationError geeft aan dat er een fout is opgetreden tijdens het maken van de koppeling.
Enkele mogelijke replicaState waarden zijn:
CreatingLink: Eerste zaadjes planten
LinkSynchroniseren: gegevensreplicatie wordt uitgevoerd
LinkFailoverInProgress-: Failover wordt uitgevoerd
Er zijn twee verschillende foutencategorieën die u kunt tegenkomen bij het gebruik van de koppeling: fouten bij het initialiseren van de koppeling en fouten bij het maken van de koppeling.
Fouten bij het initialiseren van een koppeling
De volgende fout kan optreden bij het initialiseren van een koppeling (koppelingsstatus: LinkInitError):
Fout 41962: Bewerking is afgebroken omdat de koppeling niet binnen 5 minuten is gestart. Controleer netwerkverbinding en probeer het opnieuw.
Fout 41976: De beschikbaarheidsgroep reageert niet. Controleer de namen en configuratieparameters en probeer het opnieuw.
Fout 41986: Koppeling kan niet tot stand worden gebracht omdat de verbinding is mislukt of omdat de secundaire replica niet reageert. Controleer de namen, configuratieparameters en netwerkverbinding en probeer het opnieuw.
Fout 47521: Koppeling kan niet tot stand worden gebracht omdat de secundaire server de aanvraag niet heeft ontvangen. Zorg ervoor dat de beschikbaarheidsgroep en databases in orde zijn op de primaire server en probeer het opnieuw.
Fouten bij het maken van een koppeling
De volgende fout kan optreden bij het maken van een koppeling (koppelingsstatus: LinkCreationError):
fout 41977: de doeldatabase reageert niet. Controleer de koppelingsparameters en probeer het opnieuw.
Inconsistente toestand na geforceerde failover
Na een geforceerde failover, kan er een split-brain-scenario optreden waarbij beide replica's de primaire rol hebben, waardoor de koppeling in een inconsistente toestand blijft. Dit kan gebeuren als u tijdens een noodgeval een failover naar de secundaire replica uitvoert en de primaire replica weer online komt.
Controleer eerst of u zich in een split-brain scenario bevindt. U kunt dit doen met behulp van SQL Server Management Studio (SSMS) of Transact-SQL (T-SQL).
Maak verbinding met zowel de SQL Server als de SQL Managed Instance in SSMS, en vouw vervolgens in Objectverkenner, de Beschikbaarheidsreplica's uit onder het knooppunt Beschikbaarheidsgroep in Always On High Availability. Als twee verschillende replica's als (Primair) enworden vermeld, bevindt u zich in een split-brain scenario.
U kunt ook het volgende T-SQL-script uitvoeren op zowel SQL Server als SQL Managed Instance om de rol van de replica's te controleren:
-- 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
Als beide instellingen PRIMAIRE in de Koppelingsrol kolom vermelden, bevindt u zich in een split-brain scenario.
Als je de split-brain-toestand wilt oplossen, maak je eerst een back-up op de replica die oorspronkelijk de primaire was. Als de oorspronkelijke primaire sql Server was, neemt u een back-up van het tail-logboek. Als het oorspronkelijke primaire exemplaar een SQL Managed Instance was, maakt u een alleen-kopiëren volledige back-up van . Nadat de back-up is voltooid, stelt u de gedistribueerde beschikbaarheidsgroep in op de secundaire rol voor de replica die eerst de primaire replica was, maar nu secundair wordt.
Als er bijvoorbeeld sprake is van een noodgeval, ervan uitgaande dat u een failover van uw SQL Server-workload naar Azure SQL Managed Instance hebt geforceerd en u uw workload wilt blijven uitvoeren op SQL Managed Instance, neemt u een back-up van het taillogboek op SQL Server en stelt u vervolgens de gedistribueerde beschikbaarheidsgroep in op de secundaire rol op SQL Server, zoals in het volgende voorbeeld:
--Execute on SQL Server
USE master
ALTER AVAILABILITY GROUP [<DAGName>]
SET (ROLE = SECONDARY)
GO
Voer vervolgens een geplande handmatige failover uit van SQL Managed Instance naar SQL Server met behulp van de koppeling, zoals het volgende voorbeeld:
--Execute on SQL Managed Instance
USE master
ALTER AVAILABILITY GROUP [<DAGName>] FAILOVER
GO
Netwerkconnectiviteit testen
Bidirectionele netwerkconnectiviteit tussen SQL Server en SQL Managed Instance is nodig om de koppeling te laten werken. Nadat u poorten aan de zijde van SQL Server hebt geopend en een NSG-regel aan de zijde van SQL Managed Instance hebt geconfigureerd, test u de connectiviteit met behulp van SQL Server Management Studio (SSMS) of Transact-SQL.
Test het netwerk door een tijdelijke SQL Agent-taak te maken op zowel SQL Server als SQL Managed Instance om de verbinding tussen de twee exemplaren te controleren. Wanneer u Network Checker in SSMS gebruikt, wordt de taak automatisch voor u gemaakt en verwijderd nadat de test is voltooid. U moet de SQL Agent-taak handmatig verwijderen als u uw netwerk test met behulp van T-SQL.
Notitie
Het uitvoeren van PowerShell-scripts door de SQL Server Agent op SQL Server op Linux wordt momenteel niet ondersteund, dus het is momenteel niet mogelijk om Test-NetConnection uit te voeren vanuit de SQL Server Agent-taak op SQL Server op Linux.
Als u de SQL Agent wilt gebruiken om de netwerkverbinding te testen, hebt u de volgende vereisten nodig:
De gebruiker die de test uitvoert, moet machtigingen hebben om een job te maken (ofwel als een sysadmin of als hij tot de rol SQLAgentOperator voor msdbbehoort) voor zowel SQL Server als SQL Managed Instance.
De SQL Server Agent service moet draaien op SQL Server. Omdat de agent standaard is ingeschakeld voor SQL Managed Instance, is er geen extra actie nodig.
Voer de volgende stappen uit om de netwerkverbinding tussen SQL Server en SQL Managed Instance in SSMS te testen:
Maak verbinding met het exemplaar dat als primaire replica in SSMS fungeert.
Vouw in Objectverkennerdatabases uit en klik met de rechtermuisknop op de database die u met de secundaire database wilt koppelen. Selecteer Taken >Azure SQL Managed Instance link> Verbinding testen om de Netwerkcontrole-wizard te openen.
Selecteer Volgende op de Inleidingspagina van de wizard Netwerkcontrole.
Als aan alle vereisten wordt voldaan op de pagina Voorwaarden, selecteert u Volgende. Los anders eventuele onvervulde vereisten op en selecteer vervolgens Validatie opnieuw uitvoeren.
Op de Aanmelden pagina, selecteer Aanmelden om verbinding te maken met het andere exemplaar, dat als de secundaire replica zal dienen. Selecteer Volgende.
Controleer de details op de pagina Netwerkopties opgeven en geef indien nodig een IP-adres op. Selecteer Volgende.
Controleer op de pagina Samenvatting de acties die de wizard uitvoert en selecteer vervolgens Voltooien om de verbinding tussen de twee replica's te testen.
Controleer de pagina resultaten om te controleren of er connectiviteit bestaat tussen de twee replica's en selecteer vervolgens sluiten om te voltooien.
Als u T-SQL wilt gebruiken om connectiviteit te testen, moet u de verbinding in beide richtingen controleren. Test eerst de verbinding van SQL Server met SQL Managed Instance en test vervolgens de verbinding van SQL Managed Instance naar SQL Server.
Verbinding van SQL Server met SQL Managed Instance testen
Gebruik SQL Server Agent op SQL Server om connectiviteitstests van SQL Server naar SQL Managed Instance uit te voeren.
Maak verbinding met SQL Managed Instance en voer het volgende script uit om parameters te genereren die u later nodig hebt:
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';
De resultaten moeten eruitzien als in het volgende voorbeeld:
Sla de resultaten op om de volgende stappen te gebruiken. Aangezien deze parameters na een failover kunnen worden gewijzigd, moet u deze indien nodig opnieuw genereren.
Maak verbinding met uw SQL Server-exemplaar.
Open een nieuw queryvenster en plak het volgende script:
--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
Vervang de parameters @node, @porten @serverName door de waarden die u hebt verkregen uit de eerste stap.
Voer het script uit en controleer de resultaten. U zou resultaten moeten zien zoals het volgende voorbeeld:
Controleer de resultaten:
Het resultaat van elke test bij TcpTestSucceeded moet worden TcpTestSucceeded : True.
De RemoteAddresses moeten deel uitmaken van het IP-bereik voor het subnet sql Managed Instance.
Als het antwoord mislukt, controleert u de volgende netwerkinstellingen:
Er zijn regels in zowel de netwerkfirewall als de FIREWALL van het SQL Server-host-besturingssysteem (Windows/Linux) waarmee verkeer naar het volledige IP-adresbereik van subnet van SQL Managed Instance wordt toegestaan.
Er is een NSG-regel die communicatie op poort 5022 toestaat voor het virtuele netwerk dat als host fungeert voor SQL Managed Instance.
Verbinding van SQL Managed Instance naar SQL Server testen
Als u wilt controleren of SQL Managed Instance SQL Server kan bereiken, maakt u eerst een testeindpunt. Vervolgens gebruikt u de SQL Server Agent om een PowerShell-script uit te voeren met de tnc-opdracht die SQL Server op poort 5022 pingt vanuit het beheerde SQL-exemplaar.
Als u een testeindpunt wilt maken, maakt u verbinding met SQL Server en voert u het volgende T-SQL-script uit:
-- 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
)
Als u wilt controleren of het SQL Server-eindpunt verbindingen ontvangt op poort 5022, voert u de volgende PowerShell-opdracht uit op het hostbesturingssysteem van uw SQL Server-exemplaar:
tnc localhost -port 5022
Een geslaagde test toont TcpTestSucceeded : True. Vervolgens kunt u doorgaan met het maken van een SQL Server Agent-taak op het met SQL beheerde exemplaar om het SQL Server-testeindpunt te testen op poort 5022 vanuit het beheerde SQL-exemplaar.
Maak vervolgens een SQL Server Agent-taak in het met SQL beheerde exemplaar met de naam NetHelper door het volgende T-SQL-script uit te voeren op het beheerde SQL-exemplaar. Vervangen:
<SQL_SERVER_IP_ADDRESS> met het IP-adres van SQL Server dat toegankelijk is vanuit een beheerd SQL-exemplaar.
-- 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)';
Tip
Als u het IP-adres van uw SQL Server voor de connectiviteitstest van het beheerde SQL-exemplaar wilt wijzigen, verwijdert u de NetHelper-taak door EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper'uit te voeren en maakt u de NetHelper-taak opnieuw met behulp van het vorige script.
Maak vervolgens een opgeslagen procedure ExecuteNetHelper waarmee de taak kan worden uitgevoerd en resultaten worden verkregen van de netwerktest. Voer het volgende T-SQL-script uit op een met SQL beheerd exemplaar:
-- 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;
Voer de volgende query uit op sql Managed Instance om de opgeslagen procedure uit te voeren waarmee de NetHelper-agenttaak wordt uitgevoerd en het resulterende logboek wordt weergegeven:
-- Run on managed instance
EXEC ExecuteNetHelper;
Als de verbinding is geslaagd, wordt in het logboek Trueweergegeven. Als de verbinding is mislukt, wordt in het logboek Falseweergegeven.
Als de verbinding mislukt, controleert u de volgende items:
De firewall op het SQL Server-hostexemplaar staat binnenkomende en uitgaande communicatie toe op poort 5022.
Een NSG-regel voor het virtuele netwerk dat als host fungeert voor SQL Managed Instance, staat communicatie toe op poort 5022.
Als uw SQL Server-exemplaar zich op een Azure-VM bevindt, staat een NSG-regel communicatie toe op poort 5022 op het virtuele netwerk waarop de VIRTUELE machine wordt gehost.
SQL Server draait.
Er bestaat een testeindpunt in SQL Server.
Nadat u problemen hebt opgelost, voert u de NetHelper-netwerktest opnieuw uit door EXEC ExecuteNetHelper uit te voeren op een beheerd exemplaar.
Als de netwerktest is geslaagd, verwijdert u ten slotte het testeindpunt en -certificaat op SQL Server met behulp van de volgende T-SQL-opdrachten:
-- Run on SQL Server
DROP ENDPOINT TEST_ENDPOINT;
GO
DROP CERTIFICATE TEST_CERT;
GO
Voorzichtigheid
Ga alleen verder met de volgende stappen als u de netwerkverbinding tussen uw bron- en doelomgevingen hebt gevalideerd. Los anders problemen met de netwerkverbinding op voordat u doorgaat.
Verwante inhoud
Raadpleeg de volgende bronnen voor meer informatie over de koppelingsfunctie:
Azure SQL Managed Instance
