W tym artykule przedstawiono sposób monitorowania i rozwiązywania problemów z linkiem między programem SQL Server i usługą Azure SQL Managed Instance.
Możesz sprawdzić stan łącza za pomocą Transact-SQL (T-SQL), programu Azure PowerShell lub interfejsu wiersza polecenia platformy Azure. Jeśli wystąpią problemy, możesz użyć kodów błędów, aby rozwiązać ten problem.
Jeśli wystąpią problemy z linkiem, możesz użyć Transact-SQL (T-SQL), programu Azure PowerShell lub interfejsu wiersza polecenia platformy Azure, aby uzyskać informacje o bieżącym stanie linku.
Użyj języka T-SQL, aby uzyskać szczegółowe informacje o stanie połączenia, a następnie użyj programu Azure PowerShell lub interfejsu wiersza polecenia platformy Azure, aby uzyskać kompleksowe informacje o bieżącym stanie łącza.
Użyj języka T-SQL, aby określić stan łącza w fazie rozmieszczania lub po rozpoczęciu synchronizacji danych.
Użyj następującego zapytania T-SQL, aby określić stan linku w fazie rozmieszczania w programie SQL Server lub usłudze SQL Managed Instance hostujących bazę danych wstępnie rozstawioną za pośrednictwem linku:
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
Jeśli zapytanie nie zwraca żadnych wyników, proces rozmieszczania nie został uruchomiony lub został już ukończony.
Użyj następującego zapytania T-SQL w podstawowym wystąpieniu , aby sprawdzić stan linku, gdy rozpocznie się synchronizacja danych.
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
Zapytanie zwraca następujące możliwe wartości:
brak wyniku: zapytanie zostało wykonane w instancji pomocniczej.
HEALTHY: Łącze jest w dobrym stanie, a dane są synchronizowane między replikami.
NOT_HEALTHY: łącze jest w złej kondycji, a dane nie są synchronizowane między replikami.
Użyj Get-AzSqlInstanceLink, aby uzyskać informacje o stanie połączenia za pomocą programu PowerShell.
Uruchom następujący przykładowy kod w usłudze Azure Cloud Shell lub zainstaluj lokalnie moduł Az.SQL.
$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
Użyj az sql mi link show, aby uzyskać informacje o stanie połączenia za 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
Wartość replicaState opisuje bieżący link. Jeśli stan zawiera również błąd oraz, to wystąpił błąd podczas operacji wymienionej w stanie. Na przykład LinkCreationError wskazuje, że wystąpił błąd podczas tworzenia linku.
Niektóre możliwe wartości replicaState to:
CreatingLink: początkowe rozmieszczanie
LinkSynchronizing: trwa replikacja danych
LinkFailoverInProgress: tryb przełączenia awaryjnego jest w trakcie
Istnieją dwie odrębne kategorie błędów, które można napotkać podczas korzystania z linku — błędy podczas próby zainicjowania linku i błędy podczas próby utworzenia linku.
Błędy inicjowania łącza
Podczas inicjowania łącza może wystąpić następujący błąd (stan łącza: LinkInitError):
błąd 41962: Operacja została przerwana, ponieważ łącze nie zostało zainicjowane w ciągu 5 minut. Sprawdź połączenie sieciowe i spróbuj ponownie.
błąd 41973: nie można ustanowić łącza, ponieważ certyfikat punktu końcowego z programu SQL Server nie został poprawnie zaimportowany do usługi Azure SQL Managed Instance.
Błąd 41974: nie można ustanowić łącza, ponieważ certyfikat punktu końcowego z usługi SQL Managed Instance nie został poprawnie zaimportowany do programu SQL Server.
Błąd 41976: grupa dostępności nie odpowiada. Sprawdź nazwy i parametry konfiguracji i spróbuj ponownie.
Błąd 41986: Nie można ustanowić łącza, ponieważ połączenie nie powiodło się lub replika pomocnicza nie odpowiada. Sprawdź nazwy, parametry konfiguracji i łączności sieciowej, a następnie spróbuj ponownie.
Błąd 47521: Nie można ustanowić łącza, ponieważ serwer pomocniczy nie otrzymał żądania. Upewnij się, że grupa dostępności i bazy danych są w dobrej kondycji na serwerze podstawowym i spróbuj ponownie.
Błędy podczas tworzenia łącza
Podczas tworzenia łącza może wystąpić następujący błąd (stan łącza: LinkCreationError):
Błąd 41977: docelowa baza danych nie odpowiada. Sprawdź parametry łącza i spróbuj ponownie.
Niespójny stan po wymuszonym przełączeniu awaryjnym
Po wymuszonym przełączeniu awaryjnymmoże wystąpić sytuacja podzielonego mózgu, w której obie repliki znajdują się w roli podstawowej, pozostawiając połączenie w stanie niespójnym. Może się to zdarzyć, jeśli nastąpi przełączenie do wtórnej repliki podczas awarii, a następnie replika podstawowa ponownie zacznie działać.
Najpierw upewnij się, że jesteś w scenariuszu podzielonym mózgiem. Można to zrobić przy użyciu programu SQL Server Management Studio (SSMS) lub Transact-SQL (T-SQL).
Połącz się zarówno z programem SQL Server, jak i wystąpieniem zarządzanym SQL w programie SSMS, a następnie w eksploratorze obiektów rozwiń repliki dostępności w węźle grupy dostępności w zawsze włączone. Jeśli dwie różne repliki są wymienione jako (podstawowa) i, to masz do czynienia z sytuacją split-brain.
Alternatywnie można uruchomić następujący skrypt języka T-SQL na zarówno programu SQL Server, jak i usługi SQL Managed Instance, aby sprawdzić rolę 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
Jeśli oba wystąpienia wymieniają PRIMARY w kolumnie roli Link, znajdujesz się w scenariuszu rozszczepienia mózgu.
Aby rozwiązać stan podzielonego mózgu, najpierw wykonaj kopię zapasową na tej replice, która była oryginalną główną. Jeśli oryginalny podstawowy był programem SQL Server, utwórz kopię zapasową dziennika tail. Jeśli oryginalna podstawowa instancja to SQL Managed Instance, wykonaj kompletną kopię zapasową tylko do kopiowania . Po zakończeniu tworzenia kopii zapasowej ustaw rozproszoną grupę dostępności na rolę pomocniczą dla repliki, którą była oryginalnie repliką podstawową, ale teraz będzie nową repliką pomocniczą.
Na przykład w przypadku rzeczywistej awarii, zakładając, że wymusiłeś przełączenie w tryb failover obciążenia SQL Server do usługi Azure SQL Managed Instance i zamierzasz kontynuować uruchamianie tego obciążenia, wykonaj kopię zapasową loga końcowego w SQL Server, a następnie ustaw rozproszoną grupę dostępności na rolę pomocniczą w SQL Server, jak w poniższym przykładzie:
--Execute on SQL Server
USE master
ALTER AVAILABILITY GROUP [<DAGName>]
SET (ROLE = SECONDARY)
GO
Następnie wykonaj planowane ręczne przejście w tryb failover z usługi SQL Managed Instance do programu SQL Server przy użyciu linku, takiego jak poniższy przykład:
--Execute on SQL Managed Instance
USE master
ALTER AVAILABILITY GROUP [<DAGName>] FAILOVER
GO
Testowanie łączności sieciowej
Dwukierunkowa łączność sieciowa między programem SQL Server i usługą SQL Managed Instance jest niezbędna, aby połączenie działało. Po otwarciu portów po stronie SQL Server i skonfigurowaniu reguły NSG po stronie wystąpienia zarządzanego SQL, przetestuj łączność przy użyciu programu SQL Server Management Studio (SSMS) lub języka Transact-SQL.
Przetestuj sieć, tworząc tymczasowe zadanie agenta SQL w programie SQL Server i usłudze SQL Managed Instance, aby sprawdzić połączenie między dwoma wystąpieniami. Kiedy używasz Narzędzie do sprawdzania sieci w SSMS, zadanie jest tworzone automatycznie i usuwane po zakończeniu testu. Jeśli testujesz sieć przy użyciu języka T-SQL, musisz ręcznie usunąć zadanie agenta SQL.
Notatka
Wykonywanie skryptów programu PowerShell przez agenta programu SQL Server w programie SQL Server w systemie Linux nie jest obecnie obsługiwane, więc obecnie nie można wykonać Test-NetConnection z zadania agenta programu SQL Server w programie SQL Server w systemie Linux.
Aby przetestować łączność sieciową przy użyciu agenta SQL, potrzebne są następujące wymagania:
Użytkownik wykonujący test musi mieć uprawnienia do utworzenia zadania (jako sysadmin lub należąc do roli SQLAgentOperator dla msdb) zarówno dla SQL Server, jak i SQL Managed Instance.
Usługa SQL Server Agent musi być uruchomiona na SQL Serverze. Ponieważ agent jest domyślnie włączony w usłudze SQL Managed Instance, nie jest wymagana żadna dodatkowa akcja.
Aby przetestować łączność sieciową między programem SQL Server i usługą SQL Managed Instance w programie SSMS, wykonaj następujące kroki:
Połącz się z wystąpieniem, które będzie repliką podstawową w SSMS.
W Eksploratorze obiektówrozwiń bazy danych, a następnie kliknij prawym przyciskiem myszy bazę danych, którą zamierzasz połączyć z wtórnym. Wybierz Tasks>link Azure SQL Managed Instance>Testuj Połączenie, aby otworzyć kreatora sprawdzania sieci:
Wybierz pozycję Next (Dalej) na stronie Introduction (Wprowadzenie) kreatora sprawdzania sieci .
Jeśli wszystkie wymagania zostały spełnione na stronie Wymagania wstępne, wybierz pozycję Dalej. W przeciwnym razie rozwiąż wszystkie niezaspokojone warunki wstępne, a następnie wybierz pozycję Uruchom ponownie weryfikację.
Na stronie logowania wybierz opcję Login, aby nawiązać połączenie z innym wystąpieniem, które będzie repliką pomocniczą. Wybierz pozycję Dalej.
Sprawdź szczegóły na stronie Określanie opcji sieciowych i w razie potrzeby podaj adres IP. Wybierz pozycję Dalej.
Na stronie podsumowania przejrzyj działania wykonywane przez kreatora, a następnie wybierz pozycję Zakończ, aby przetestować połączenie między dwiema replikami.
Przejrzyj stronę z wynikami, aby sprawdzić, czy istnieje łączność między dwiema replikami, a następnie wybierz Zamknij, aby zakończyć.
Aby przetestować łączność przy użyciu języka T-SQL, należy sprawdzić połączenie w obu kierunkach. Najpierw przetestuj połączenie z programu SQL Server do usługi SQL Managed Instance, a następnie przetestuj połączenie z usługi SQL Managed Instance do programu SQL Server.
Testowanie połączenia z programu SQL Server do usługi SQL Managed Instance
Użyj programu SQL Server Agent w programie SQL Server, aby uruchomić testy łączności z programu SQL Server do usługi SQL Managed Instance.
Połącz się z usługą SQL Managed Instance i uruchom następujący skrypt, aby wygenerować parametry potrzebne później:
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';
Wyniki powinny wyglądać podobnie do następującego przykładu:
Zapisz wyniki, aby wykonać następne kroki. Ponieważ te parametry mogą ulec zmianie po przejściu w tryb failover, pamiętaj, aby wygenerować je ponownie, jeśli to konieczne.
Połącz się z instancją SQL Server.
Otwórz nowe okno zapytania i wklej następujący skrypt:
--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
Zastąp parametry @node, @porti @serverName wartościami uzyskanymi w pierwszym kroku.
Uruchom skrypt i sprawdź wyniki. Powinny zostać wyświetlone wyniki, takie jak poniższy przykład:
Sprawdź wyniki:
Wynik każdego testu w TcpTestSucceeded powinien być TcpTestSucceeded : True.
Adresy zdalne powinny należeć do zakresu adresów IP dla podsieci zarządzanej instancji SQL.
Jeśli odpowiedź nie powiedzie się, sprawdź następujące ustawienia sieciowe:
Istnieją reguły zarówno w zaporze sieciowej , jak i w zaporze systemu operacyjnego hosta dla SQL Server (Windows/Linux), które umożliwiają ruch do całego zakresu adresów IP podsieci wystąpienia zarządzanego SQL.
Istnieje reguła NSG, która zezwala na komunikację na porcie 5022 dla sieci wirtualnej, która hostuje SQL Managed Instance.
Testowanie połączenia z usługi SQL Managed Instance do programu SQL Server
Aby sprawdzić, czy usługa SQL Managed Instance może nawiązać połączenie z programem SQL Server, najpierw utwórz testowy punkt końcowy. Następnie użyjesz agenta SQL Server, aby uruchomić skrypt PowerShell za pomocą polecenia tnc do pingowania SQL Server na porcie 5022 z zarządzanego wystąpienia SQL.
Aby utworzyć testowy punkt końcowy, połącz się z programem SQL Server i uruchom następujący skrypt języka 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
)
Aby sprawdzić, czy punkt końcowy programu SQL Server odbiera połączenia na porcie 5022, uruchom następujące polecenie programu PowerShell w systemie operacyjnym hosta wystąpienia programu SQL Server:
tnc localhost -port 5022
Test zakończony pomyślnie pokazuje TcpTestSucceeded : True. Następnie możesz utworzyć zadanie agenta programu SQL Server w wystąpieniu zarządzanym SQL, aby spróbować przetestować testowy punkt końcowy programu SQL Server na porcie 5022 z wystąpienia zarządzanego SQL.
Następnie utwórz zadanie agenta programu SQL Server w wystąpieniu zarządzanym SQL o nazwie NetHelper, uruchamiając następujący skrypt języka T-SQL w wystąpieniu zarządzanym SQL. Zastąp:
<SQL_SERVER_IP_ADDRESS> z adresem IP serwera SQL, do którego można uzyskać dostęp z zarządzanego wystąpienia 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)';
Napiwek
Jeśli musisz zmodyfikować adres IP serwera SQL dla sondy nawiązywania połączenia z wystąpienia zarządzanego SQL, usuń zadanie NetHelper, uruchamiając EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper', i ponownie utwórz zadanie NetHelper, korzystając z poprzedniego skryptu.
Następnie utwórz procedurę składowaną ExecuteNetHelper, która pomaga uruchomić zadanie i uzyskuje wyniki z sondy sieciowej. Uruchom następujący skrypt języka T-SQL w wystąpieniu zarządzanym 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;
Uruchom następujące zapytanie w wystąpieniu zarządzanym SQL, aby wykonać procedurę składowaną, która wykona zadanie agenta NetHelper i wyświetli wynikowy dziennik:
-- Run on managed instance
EXEC ExecuteNetHelper;
Jeśli połączenie zakończyło się pomyślnie, dziennik pokazuje True. Jeśli połączenie nie powiodło się, dziennik pokazuje False.
Jeśli połączenie nie powiodło się, sprawdź następujące elementy:
Zapora na hoście instancji programu SQL Server zezwala na komunikację przychodzącą i wychodzącą na porcie 5022.
Reguła sieciowej grupy zabezpieczeń dla sieci wirtualnej, która hostuje usługę SQL Managed Instance, umożliwia komunikację na porcie 5022.
Jeśli wystąpienie programu SQL Server znajduje się na maszynie wirtualnej Azure, reguła NSG zezwala na komunikację na porcie 5022 w sieci wirtualnej, która hostuje maszynę wirtualną.
Program SQL Server jest uruchomiony.
W programie SQL Server istnieje testowy punkt końcowy.
Po rozwiązaniu problemów ponownie uruchom sondę sieci NetHelper, uruchamiając EXEC ExecuteNetHelper w wystąpieniu zarządzanym.
Na koniec po pomyślnym zakończeniu testu sieciowego usuń punkt końcowy testu i certyfikat na serwerze SQL przy użyciu następujących poleceń języka T-SQL:
-- Run on SQL Server
DROP ENDPOINT TEST_ENDPOINT;
GO
DROP CERTIFICATE TEST_CERT;
GO
Ostrożność
Wykonaj kolejne kroki tylko wtedy, gdy sprawdzono łączność sieciową między środowiskami źródłowymi i docelowymi. W przeciwnym razie przed kontynuowaniem rozwiąż problemy z łącznością sieciową.
Powiązana zawartość
Aby uzyskać więcej informacji na temat funkcji linku, zapoznaj się z następującymi zasobami:
Azure SQL Managed Instance
