V tomto článku se dozvíte, jak monitorovat a řešit problémy s odkazem mezi SQL Serverem a spravovanou instancí Azure SQL.
Stav odkazu můžete zkontrolovat pomocí Transact-SQL (T-SQL), Azure PowerShellu nebo Azure CLI. Pokud narazíte na problémy, můžete k vyřešení problému použít kódy chyb.
Pokud narazíte na problémy s odkazem, můžete k získání informací o aktuálním stavu odkazu použít Transact-SQL (T-SQL), Azure PowerShell nebo Azure CLI.
K rychlému zobrazení stavu odkazu použijte T-SQL a poté pomocí Azure PowerShellu nebo Azure CLI získejte komplexní informace o aktuálním stavu odkazu.
Pomocí jazyka T-SQL můžete určit stav propojení během počáteční fáze nebo po zahájení synchronizace dat.
Pomocí následujícího dotazu T-SQL určete stav odkazu během fáze inicializace na SQL Serveru nebo ve spravované instanci SQL, která je hostitelem databáze inicializované prostřednictvím odkazu:
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
Pokud dotaz nevrátí žádné výsledky, buď se proces nasazení ještě nezačal, nebo již byl dokončen.
Pomocí následujícího dotazu T-SQL na primární instanci zkontrolujte stav propojení po zahájení synchronizace dat:
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
Dotaz vrátí následující možné hodnoty:
žádný výsledek: Dotaz byl proveden v sekundární instanci.
HEALTHY: Propojení je v pořádku a data se synchronizují mezi replikami.
NOT_HEALTHY: Propojení není v pořádku a data se mezi replikami nesynchronují.
Pomocí Get-AzSqlInstanceLink získejte informace o stavu propojení pomocí PowerShellu.
V Azure Cloud Shellu spusťte následující ukázkový kód nebo nainstalujte modul Az.SQL místně.
$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
Pomocí az sql mi link show získejte informace o stavu propojení pomocí 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
Hodnota replicaState popisuje aktuální odkaz. Pokud stav obsahuje také Chyba došlo k chybě během operace uvedené ve stavu. Například LinkCreationError značí, že při vytváření odkazu došlo k chybě.
Mezi možné hodnoty replicaState patří:
CreatingLink: Počáteční sázení
LinkSynchronizing: Probíhá replikace dat
Selhání propojení je v procesu: Probíhá selhání propojení
Chyba 41976: Skupina dostupnosti neodpovídá. Zkontrolujte názvy a parametry konfigurace a zkuste to znovu.
Chyba 41986: Propojení nejde navázat, protože připojení selhalo nebo sekundární replika nereaguje. Zkontrolujte názvy, parametry konfigurace a síťové připojení a zkuste to znovu.
Chyba 47521: Propojení nejde navázat, protože sekundární server neobdržel požadavek. Ujistěte se, že je skupina dostupnosti a databáze na primárním serveru v pořádku, a zkuste to znovu.
Chyby při vytváření odkazu
Při vytváření odkazu (stav propojení: LinkCreationError) může dojít k následující chybě:
Chyba 41977: Cílová databáze neodpovídá. Zkontrolujte parametry propojení a zkuste to znovu.
Nekonzistentní stav po vynuceném převzetí při selhání
Po vynuceném převzetí služeb při selhánímůžete narazit na scénář rozděleného mozku, ve kterém jsou obě repliky v primární roli a propojení tak zůstane v nekonzistentním stavu. K tomu může dojít, pokud během havárie přepnete na sekundární repliku a pak se primární replika vrátí online.
Nejprve ověřte, že jste ve scénáři rozděleného mozku. Můžete to provést pomocí aplikace SQL Server Management Studio (SSMS) nebo Transact-SQL (T-SQL).
Připojte se k SQL Serveru i ke spravované instanci SQL v nástroji SSMS, a potom v Průzkumníku objektůrozbalte Repliky dostupnosti pod uzlem Skupiny dostupnosti v rámci Always On High Availability. Pokud jsou dvě různé repliky uvedené jako (primární), jste ve scénáři rozděleného mozku.
Případně můžete následující skript T-SQL spustit na jak SQL Serveru, tak i SQL Managed Instance, abyste zkontrolovali roli replik.
-- 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
Pokud oba instance uvádějí PRIMÁRNÍ ve sloupci role Propojení, jste ve scénáři rozděleného mozku.
Pokud chcete vyřešit stav rozděleného mozku, nejprve vytvořte zálohu na replice, která byla původní primární. Pokud původní primární server byl SQL Server, proveďte zálohování protokolu tail. Pokud byla původní primární instance SQL Managed Instance, proveďte úplné zálohování typu copy-only. Po dokončení zálohování nastavte distribuovanou skupinu dostupnosti na sekundární roli pro repliku, která byla dříve původně primární, ale nyní bude novou sekundární.
Například v případě skutečné havárie za předpokladu, že jste vynutili převzetí služeb při selhání úlohy SQL Serveru do služby Azure SQL Managed Instance a chcete pokračovat ve spouštění úloh ve službě SQL Managed Instance, proveďte zálohu koncového protokolu na SQL Serveru a pak nastavte distribuovanou skupinu dostupnosti na sekundární roli na SQL Serveru, například v následujícím příkladu:
--Execute on SQL Server
USE master
ALTER AVAILABILITY GROUP [<DAGName>]
SET (ROLE = SECONDARY)
GO
Potom prostřednictvím odkazu spusťte plánované ruční převzetí služeb při selhání ze spravované instance SQL na SQL Server, například:
--Execute on SQL Managed Instance
USE master
ALTER AVAILABILITY GROUP [<DAGName>] FAILOVER
GO
Testování připojení k síti
Aby propojení fungovalo, je nezbytné obousměrné síťové připojení mezi SQL Serverem a službou SQL Managed Instance. Po otevření portů na straně SQL Serveru a konfiguraci pravidla NSG na straně služby SQL Managed Instance otestujte připojení pomocí aplikace SQL Server Management Studio (SSMS) nebo Transact-SQL.
Otestujte síť vytvořením dočasné úlohy agenta SQL na SQL Serveru i ve spravované instanci SQL a zkontrolujte připojení mezi těmito dvěma instancemi. Když v SSMS použijete Network Checker, úloha se pro vás automaticky vytvoří a po dokončení testu se odstraní. Pokud otestujete síť pomocí T-SQL, musíte úlohu agenta SQL ručně odstranit.
Poznámka
Spouštění skriptů PowerShellu agentem SQL Serveru na SQL Serveru v Linuxu se v současné době nepodporuje, takže v současné době není možné spustit Test-NetConnection z úlohy agenta SQL Serveru na SQL Serveru v Linuxu.
Pokud chcete k otestování připojení k síti použít agenta SQL, potřebujete následující požadavky:
Uživatel provádějící test musí mít oprávnění k vytvoření úlohy buď jako správce systému, nebo musí patřit do role SQLAgentOperator pro msdb, a to jak pro SQL Server, tak pro spravovanou instanci SQL.
Služba agenta SQL Serveru musí být spuštěná na SQL Serveru. Vzhledem k tomu, že je agent ve výchozím nastavení ve službě SQL Managed Instance zapnutý, není nutná žádná další akce.
Pokud chcete otestovat síťové připojení mezi SQL Serverem a službou SQL Managed Instance v nástroji SSMS, postupujte takto:
Připojte se k instanci, která bude primární replikou v nástroji SSMS.
V Průzkumník objektůrozbalte databáze a klikněte pravým tlačítkem myši na databázi, kterou chcete propojit se sekundární. Vyberte Úlohy>Azure SQL Managed Instance odkaz>Test připojení, abyste otevřeli průvodce Network Checker.
Na stránce Úvod v průvodci Kontrola sítě vyberte Další.
Pokud jsou splněny všechny požadavky na stránce Požadavky, vyberte Další. V opačném případě vyřešte všechny nesplněné požadavky a pak vyberte Znovu spustit ověřování.
Na stránce Přihlášení vyberte Přihlášení pro připojení k druhé instanci, která bude sekundární replikou. Vyberte Další.
Zkontrolujte podrobnosti na stránce Zadat možnosti sítě a v případě potřeby zadejte IP adresu. Vyberte Další.
Na stránce Souhrn zkontrolujte akce, které průvodce provede, a pak vyberte Dokončit a otestujte připojení mezi těmito dvěma replikami.
Zkontrolujte stránku Výsledky, abyste ověřili existenci připojení mezi těmito dvěma replikami, a poté vyberte Zavřít k dokončení.
Pokud chcete k otestování připojení použít T-SQL, musíte připojení zkontrolovat v obou směrech. Nejprve otestujte připojení z SQL Serveru ke spravované instanci SQL a pak otestujte připojení ze spravované instance SQL k SQL Serveru.
Testování připojení z SQL Serveru ke spravované instanci SQL
Pomocí agenta SQL Serveru na SQL Serveru můžete spouštět testy připojení z SQL Serveru do služby SQL Managed Instance.
Připojte se ke službě SQL Managed Instance a spuštěním následujícího skriptu vygenerujte parametry, které budete potřebovat později:
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';
Výsledky by měly vypadat jako v následující ukázce:
Výsledky uložte, abyste mohli použít další kroky. Vzhledem k tomu, že se tyto parametry můžou po přepnutí při selhání změnit, nezapomeňte je v případě potřeby znovu generovat.
Připojte se k instanci SQL Serveru.
Otevřete nové okno dotazu a vložte následující skript:
--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
Nahraďte parametry @node, @porta @serverName hodnotami, které jste získali z prvního kroku.
Spusťte skript a zkontrolujte výsledky. Měli byste vidět výsledky, jako je následující příklad:
Ověřte výsledky:
Výsledek každého testu na tcpTestSucceeded by měl být TcpTestSucceeded : True.
RemoteAddresses by měl patřit do rozsahu IP adres podsítě služby SQL Managed Instance.
Pokud odpověď není úspěšná, ověřte následující nastavení sítě:
V bráně firewall sítě i bráně firewall hostitele SQL Serveru (Windows/Linux), která umožňuje provoz do celého rozsahu IP podsítě spravované instance SQL.
Existuje pravidlo NSG, které umožňuje komunikaci na portu 5022 pro virtuální síť, která je hostitelem služby SQL Managed Instance.
Testování připojení ze spravované instance SQL k SQL Serveru
Pokud chcete zkontrolovat, že se spravovaná instance SQL může spojit s SQL Serverem, nejprve vytvořte testovací koncový bod. Potom použijte agenta SQL Serveru ke spuštění skriptu PowerShell s příkazem tnc, který provede ping na SQL Server na portu 5022 ze spravované instance SQL.
Pokud chcete vytvořit testovací koncový bod, připojte se k SQL Serveru a spusťte následující skript 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
)
Pokud chcete ověřit, že koncový bod SQL Serveru přijímá připojení na portu 5022, spusťte v hostitelském operačním systému vaší instance SQL Serveru následující příkaz PowerShellu:
tnc localhost -port 5022
Úspěšný test ukazuje TcpTestSucceeded : True. Potom můžete pokračovat vytvořením úlohy agenta SQL Serveru ve spravované instanci SQL a zkusit otestovat koncový bod testu SQL Serveru na portu 5022 ze spravované instance SQL.
Dále ve spravované instanci SQL vytvořte úlohu agenta SQL Serveru s názvem NetHelper spuštěním následujícího skriptu T-SQL ve spravované instanci SQL. Nahradit:
<SQL_SERVER_IP_ADDRESS> s IP adresou SQL Serveru, ke které je možné přistupovat ze spravované instance SQL.
-- 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)';
Rada
Pokud potřebujete upravit IP adresu SQL Serveru pro sondu připojení ze spravované instance SQL, odstraňte úlohu NetHelper spuštěním EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper'a znovu vytvořte úlohu NetHelper pomocí předchozího skriptu.
Potom vytvořte uloženou proceduru ExecuteNetHelper, která pomáhá spustit úlohu a získá výsledky ze síťové sondy. Ve spravované instanci SQL spusťte následující skript 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;
Spuštěním následujícího dotazu na spravovanou instanci SQL spusťte uloženou proceduru, která spustí úlohu agenta NetHelper a zobrazí výsledný protokol:
-- Run on managed instance
EXEC ExecuteNetHelper;
Pokud bylo připojení úspěšné, zobrazí se v protokolu True. Pokud připojení nebylo úspěšné, zobrazí se v protokolu False.
Pokud připojení nebylo úspěšné, ověřte následující položky:
Firewall na hostitelské instanci SQL Serveru umožňuje komunikaci na portu 5022 příchozím i odchozím směrem.
Pravidlo skupiny zabezpečení sítě pro virtuální síť, která je hostitelem služby SQL Managed Instance, umožňuje komunikaci na portu 5022.
Pokud je vaše instance SQL Serveru na virtuálním počítači Azure, pravidlo NSG umožňuje komunikaci na portu 5022 ve virtuální síti, která je hostitelem virtuálního počítače.
SQL Server je spuštěný.
Na SQL Serveru existuje testovací koncový bod.
Po vyřešení problémů znovu spusťte sondu sítě NetHelper spuštěním EXEC ExecuteNetHelper ve spravované instanci.
Nakonec po úspěšném testu sítě zahoďte testovací koncový bod a certifikát na SQL Serveru pomocí následujících příkazů T-SQL:
-- Run on SQL Server
DROP ENDPOINT TEST_ENDPOINT;
GO
DROP CERTIFICATE TEST_CERT;
GO
Opatrnost
Pokračujte dalšími kroky jenom v případě, že jste ověřili síťové připojení mezi zdrojovým a cílovým prostředím. V opačném případě před pokračováním vyřešte potíže s připojením k síti.
Související obsah
Další informace o funkci odkazu najdete v následujících zdrojích informací:
azure SQL Managed Instance
