Odkaz pro řešení potíží – Azure SQL Managed Instance

platí pro:azure SQL Managed Instance

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.

Mnoho problémů s vytvořením propojení je možné vyřešit kontrolou síťového mezi dvěma instancemi a ověřením prostředí bylo správně připravené pro propojení.

Počáteční setí

Při vytváření propojení mezi SQL Serverem a službou Azure SQL Managed Instance probíhá nejprve počáteční fáze před zahájením replikace dat. Počáteční fáze osévání je nejdelší a nejdražší částí operace. Po dokončení počátečního seedingu se data synchronizují a replikují se pouze následné změny dat. Doba trvání počátečního osévání závisí na velikosti dat, intenzitě zátěže na primárních databázích a rychlosti spojení mezi sítěmi primárních a sekundárních replik.

Pokud je rychlost propojení mezi těmito dvěma instancemi pomalejší než to, co je potřeba, je pravděpodobné, že doba potřebná k osázení bude výrazně ovlivněna. Můžete použít uvedenou počáteční rychlost, celkovou velikost dat a přenosovou rychlost k odhadu, jak dlouho bude počáteční fáze trvat před zahájením replikace dat. Například v případě jedné databáze o velikosti 100 GB by počáteční fáze trvala přibližně 1,2 hodiny, pokud je propojení schopné přenést 84 GB za hodinu a pokud se žádné jiné databáze nezasívají na jiné propojení. Pokud propojení může přenášet pouze 10 GB za hodinu, může počáteční rozdělení databáze o velikosti 100 GB trvat přibližně 10 hodin. Pokud existuje více databází, které se mají replikovat přes více propojení, provede se šíření paralelně, a v kombinaci s pomalou rychlostí linky může počáteční fáze trvat výrazně déle, zejména pokud paralelní počáteční šíření dat ze všech databází překročí dostupnou šířku pásma linky.

Úvodní fáze seedingu není odolná vůči výpadkům sítě, údržbě instancí nebo přepnutí při selhání. Pokud dojde k dočasné ztrátě obousměrného připojení mezi SQL Serverem a SQL Managed Instance, nebo pokud dojde k restartování SQL Serveru či SQL Managed Instance nebo k převzetí služeb při selhání během počáteční fáze nasazení, seedování bude restartováno.

Důležité

Počáteční fáze počátečního seedingu může trvat dny s extrémně nízkými rychlostmi nebo zaneprázdněnými spojeními. V takovém případě může vytvoření odkazu vypršet časový limit. Vytvoření odkazu se po 6 dnech automaticky zruší.

Kontrola stavu propojení

Pokud narazíte na problémy s odkazem, můžete získat informace o aktuálním stavu odkazu pomocí aplikace SQL Server Management Studio (SSMS), Transact-SQL (T-SQL), Azure PowerShellu 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.

SSMS

Monitorování propojení je k dispozici od aplikace SQL Server Management Studio (SSMS) 21.0 (Preview).

Pokud chcete zkontrolovat stav propojení v nástroji SSMS, postupujte takto:

1. Připojte se k replice, která hostí odkaz.

2. V Průzkumníku objektů rozbalte položku Always On s vysokou dostupností a potom rozbalte Skupiny dostupnosti.

3. Klikněte pravým tlačítkem myši na název odkazu a potom výběrem možnosti Vlastnosti otevřete okno Vlastnosti odkazu :

   

4. V okně Vlastnosti odkazu se zobrazí užitečné informace o odkazu, například informace o replice, stav propojení a datum vypršení platnosti certifikátu koncového bodu:

   

T-SQL

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

PowerShell

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

Azure CLI

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í

Úplný seznam vlastností stavu propojení najdete v distribuovaných skupinách dostupnosti – PŘÍKAZ GET REST API.

Chyby s odkazem

Při použití odkazu existují dvě různé kategorie chyb – chyby při pokusu o inicializaci odkazu a chyby při pokusu o vytvoření odkazu.

Chyby inicializace propojení sql-server-2016-database-engine-events-and-errors-1000-1999

K následující chybě může dojít při inicializaci propojení (stav propojení: LinkInitError):

• Chyba 41962: Operace byla přerušena, protože propojení nebylo zahájeno během 5 minut. Zkontrolujte připojení k síti a zkuste to znovu.
• Chyba 41973: Propojení nejde navázat, protože certifikát koncového bodu z SQL Serveru nebyl správně importován do služby Azure SQL Managed Instance.
• Chyba 41974: Propojení nejde navázat, protože certifikát koncového bodu ze služby SQL Managed Instance nebyl správně importován do SQL Serveru.
• 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

K následujícím chybám může dojít při vytváření odkazu (stav propojení: LinkCreationError):

• Chyba 41977: Cílová databáze neodpovídá. Zkontrolujte parametry propojení a zkuste to znovu.

• Předčasné zkrácení protokolu: Pokud se transakční protokol zkrátí před dokončením počátečního nastavení, pravděpodobně uvidíte jednu z následujících chyb:

  • Chyba 1408: Vzdálená kopie databáze%.*ls není dostatečně obnovena do potřebného stavu, neumožňuje zrcadlení databáze ani její připojení ke skupině dostupnosti.
  • Chyba 1412: Vzdálená kopie databáze%.*ls nebyla převedena vpřed k časovému bodu, který je zahrnut v místní kopii protokolu databáze.

  Pokud chcete tento problém vyřešit, musíte odstranit a znovu vytvořit odkaz.
  Aby jste se tomuto problému vyhnuli, pozastavte zálohování transakčních protokolů na SQL Serveru pro databázi, která je replikována během počáteční fáze nasazení.

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 

Prošlý certifikát

Platnost certifikátu použitého pro odkaz může vypršet. Pokud platnost certifikátu vyprší, odkaz selže. Pokud chcete tento problém vyřešit, otočte certifikát.

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.

Vezměte v úvahu následující skutečnosti:

• Aby se zabránilo falešně negativním výsledkům, musí všechny brány firewall v síťové cestě umožňovat provoz protokolu ICMP (Internet Control Message Protocol).
• Aby se zabránilo falešně pozitivním výsledkům, musí všechny brány firewall na síťové cestě umožňovat provoz na proprietárním protokolu SQL Server UCS. Blokování protokolu může vést k úspěšnému testu připojení, ale propojení se nepodaří vytvořit.
• Pokročilá nastavení brány firewall s mantinely na úrovni paketů musí být správně nakonfigurovaná tak, aby umožňovala správně provoz mezi SQL Serverem a spravovanou instancí SQL.

SSMS

Pokud chcete otestovat síťové připojení mezi SQL Serverem a službou SQL Managed Instance v nástroji SSMS, postupujte takto:

1. Připojte se k instanci, která bude primární replikou v nástroji SSMS.

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

   

3. Na stránce Úvod v průvodci Kontrola sítě vyberte Další.

4. 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í.

5. Na stránce Přihlášení vyberte Přihlášení pro připojení k druhé instanci, která bude sekundární replikou. Vyberte Další.

6. Zkontrolujte podrobnosti na stránce Zadat možnosti sítě a v případě potřeby zadejte IP adresu. Vyberte Další.

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

8. 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í.

T-SQL

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.

1. 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:

    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'
   

   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.

2. Připojte se k instanci SQL Serveru.

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

4. Nahraďte parametry @node, @porta @serverName hodnotami, které jste získali z prvního kroku.

5. Spusťte skript a zkontrolujte výsledky. Měli byste vidět výsledky, jako je následující příklad:

   

6. 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í:

• Přehled odkazů na spravovanou instanci
• Příprava prostředí na propojení spravované instance
• Konfigurace propojení mezi SQL Serverem a spravovanou instancí SQL pomocí skriptů
• zotavení po havárii pomocí odkazu na spravovanou instanci
• osvědčené postupy pro udržování propojení