Förbereda din miljö för en länk – Azure SQL Managed Instance

Gäller för:Azure SQL Managed Instance

I den här artikeln lär du dig hur du förbereder din miljö för en hanterad instanslänk så att du kan replikera mellan SQL Server och Azure SQL Managed Instance.

Kommentar

Du kan automatisera förberedelsen av din miljö för länken Hanterad instans med hjälp av ett nedladdningsbart skript. Mer information finns i installationsbloggen för automatisk länk.

Förutsättningar

För att skapa en länk mellan SQL Server och Azure SQL Managed Instance behöver du följande krav:

• En aktiv Azure-prenumeration. Om du inte har en skapar du ett kostnadsfritt konto.
• Version av SQL Server som stöds med nödvändig tjänstuppdatering.
• Azure SQL Managed Instance. Kom igång om du inte har det.
• Bestäm vilken server som ska vara den första primära servern för att avgöra var du ska skapa länken från. Det går bara att konfigurera en länk från den primära SQL Managed Instance-instansen till SQL Server secondary från och med SQL Server 2022 CU10.

Varning

När du skapar din SQL-hanterade instans som ska användas med länkfunktionen ska du ta hänsyn till minneskraven för alla minnesinterna OLTP-funktioner som SQL Server använder. Mer information finns i Översikt över resursbegränsningar för Azure SQL Managed Instance.

Behörigheter

För SQL Server bör du ha sysadmin-behörigheter .

För Azure SQL Managed Instance bör du vara medlem i SQL Managed Instance-deltagaren eller ha följande behörigheter för en anpassad roll:

Microsoft.Sql/-resurs	Nödvändiga behörigheter
Microsoft.Sql/managedInstances	/read, /write
Microsoft.Sql/managedInstances/hybridCertificate	/åtgärd
Microsoft.Sql/managedInstances/databases	/read, /delete, /write, /completeRestore/action, /readBackups/action, /restoreDetails/read
Microsoft.Sql/managedInstances/distributedAvailabilityGroups	/read, /write, /delete, /setRole/action
Microsoft.Sql/managedInstances/endpointCertificates	/Läsa
Microsoft.Sql/managedInstances/hybridLink	/read, /write, /delete
Microsoft.Sql/managedInstances/serverTrustCertificates	/write, /delete, /read

Förbereda SQL Server-instansen

För att förbereda SQL Server-instansen måste du verifiera att:

• Du har den lägsta versionen som stöds.
• Du har aktiverat funktionen tillgänglighetsgrupper.
• Du har lagt till rätt spårningsflaggor vid start.
• Databaserna är i den fullständiga återställningsmodellen och säkerhetskopierade.

Du måste starta om SQL Server för att ändringarna ska börja gälla.

Installera tjänstuppdateringar

Se till att SQL Server-versionen har rätt underhållsuppdatering installerad enligt listan i tabellen för versionssupport. Om du behöver installera uppdateringar måste du starta om SQL Server-instansen under uppdateringen.

Kontrollera SQL Server-versionen genom att köra följande Transact-SQL-skript (T-SQL) på SQL Server:

-- Run on SQL Server
-- Shows the version and CU of the SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';

Skapa en databashuvudnyckel i master databasen

Skapa databashuvudnyckeln master i databasen, om den inte redan finns. Infoga lösenordet i stället för <strong_password> i följande skript och förvara det på en konfidentiell och säker plats. Kör det här T-SQL-skriptet på SQL Server:

-- Run on SQL Server
-- Create a master key
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>';

Kontrollera att du har databashuvudnyckeln genom att använda följande T-SQL-skript på SQL Server:

-- Run on SQL Server
USE master;
GO
SELECT * FROM sys.symmetric_keys WHERE name LIKE '%DatabaseMasterKey%';

Aktivera tillgänglighetsgrupper

Länkfunktionen förlitar sig på funktionen AlwaysOn-tillgänglighetsgrupper, som är inaktiverad som standard. Mer information finns i Aktivera funktionen AlwaysOn-tillgänglighetsgrupper.

Kontrollera att funktionen tillgänglighetsgrupper är aktiverad genom att köra följande T-SQL-skript på SQL Server:

-- Run on SQL Server
-- Is the availability groups feature enabled on this SQL Server
DECLARE @IsHadrEnabled sql_variant = (select SERVERPROPERTY('IsHadrEnabled'))
SELECT
    @IsHadrEnabled as 'Is HADR enabled',
    CASE @IsHadrEnabled
        WHEN 0 THEN 'Availability groups DISABLED.'
        WHEN 1 THEN 'Availability groups ENABLED.'
        ELSE 'Unknown status.'
    END
    as 'HADR status'

Viktigt!

Om du behöver aktivera funktionen tillgänglighetsgrupper för SQL Server 2016 (13.x) måste du slutföra de extra steg som beskrivs i Länken Förbered SQL Server 2016-krav – Azure SQL Managed Instance. De här extra stegen krävs inte för SQL Server 2019 (15.x) och senare versioner som stöds av länken.

Om funktionen tillgänglighetsgrupper inte är aktiverad följer du de här stegen för att aktivera den:

1. Öppna SQL Server Configuration Manager.

2. Välj SQL Server Services i det vänstra fönstret.

3. Högerklicka på SQL Server-tjänsten och välj sedan Egenskaper.

   

4. Gå till fliken AlwaysOn-tillgänglighetsgrupper .

5. Markera kryssrutan Aktivera AlwaysOn-tillgänglighetsgrupper och välj sedan OK.

   

   • Om du använder SQL Server 2016 (13.x) och alternativet Aktivera AlwaysOn-tillgänglighetsgrupper är inaktiverat med meddelandet This computer is not a node in a failover cluster.följer du de extra stegen som beskrivs i Länken Förbered SQL Server 2016-krav – Azure SQL Managed Instance. När du har slutfört de här andra stegen kommer du tillbaka och försöker utföra det här steget igen.

6. Välj OK i dialogrutan.

7. Starta om SQL Server-tjänsten.

Aktivera spårningsflaggor för start

För att optimera prestanda för länken rekommenderar vi att du aktiverar följande spårningsflaggor vid start:

• -T1800: Den här spårningsflaggan optimerar prestanda när loggfilerna för de primära och sekundära replikerna i en tillgänglighetsgrupp finns på diskar med olika sektorstorlekar, till exempel 512 byte och 4 KB. Om både primära och sekundära repliker har en disksektorstorlek på 4 KB krävs inte den här spårningsflaggan. Mer information finns i KB3009974.
• -T9567: Den här spårningsflaggan möjliggör komprimering av dataströmmen för tillgänglighetsgrupper under automatisk seeding. Komprimering ökar belastningen på processorn men kan avsevärt minska överföringstiden under seeding.

Använd följande steg för att aktivera dessa spårningsflaggor vid start:

1. Öppna SQL Server Configuration Manager.

2. Välj SQL Server Services i det vänstra fönstret.

3. Högerklicka på SQL Server-tjänsten och välj sedan Egenskaper.

   

4. Gå till fliken Startparametrar . I Ange en startparameter anger -T1800 du och väljer Lägg till för att lägga till startparametern. Ange -T9567 sedan och välj Lägg till för att lägga till den andra spårningsflaggan. Tryck på Apply (Verkställ) för att spara ändringarna.

   

5. Välj OK för att stänga fönstret Egenskaper .

Mer information finns i syntaxen för att aktivera spårningsflaggor.

Starta om SQL Server och verifiera konfigurationen

När du har sett till att du har en version av SQL Server som stöds, aktiverat funktionen AlwaysOn-tillgänglighetsgrupper och lagt till dina spårningsflaggor för start startar du om SQL Server-instansen för att tillämpa alla dessa ändringar:

1. Öppna Konfigurationshanteraren för SQL Server.

2. Välj SQL Server Services i det vänstra fönstret.

3. Högerklicka på SQL Server-tjänsten och välj sedan Starta om.

   

Efter omstarten kör du följande T-SQL-skript på SQL Server för att verifiera konfigurationen av DIN SQL Server-instans:

-- Run on SQL Server
-- Shows the version and CU of SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';
GO
-- Shows if the Always On availability groups feature is enabled
SELECT SERVERPROPERTY ('IsHadrEnabled') as 'Is Always On enabled? (1 true, 0 false)';
GO
-- Lists all trace flags enabled on SQL Server
DBCC TRACESTATUS;

SQL Server-versionen bör vara en av de versioner som stöds med lämpliga tjänstuppdateringar, funktionen AlwaysOn-tillgänglighetsgrupper ska vara aktiverad och du bör ha spårningsflaggor -T1800 och -T9567 aktiverade. Följande skärmbild är ett exempel på det förväntade resultatet för en SQL Server-instans som har konfigurerats korrekt:

Konfigurera nätverksanslutning

För att länken ska fungera måste du ha nätverksanslutning mellan SQL Server och SQL Managed Instance. Vilket nätverksalternativ du väljer beror på om SQL Server-instansen finns i ett Azure-nätverk eller inte.

SQL Server på Azure Virtual Machines

Att distribuera SQL Server på virtuella Azure-datorer i samma virtuella Azure-nätverk som är värd för SQL Managed Instance är den enklaste metoden, eftersom nätverksanslutningen automatiskt finns mellan de två instanserna. Mer information finns i Snabbstart: Konfigurera en virtuell Azure-dator för att ansluta till Azure SQL Managed Instance.

Om din SQL Server på Azure Virtual Machines-instansen finns i ett annat virtuellt nätverk än den hanterade instansen måste du upprätta en anslutning mellan båda de virtuella nätverken. De virtuella nätverken behöver inte finnas i samma prenumeration för att det här scenariot ska fungera.

Det finns två alternativ för att ansluta virtuella nätverk:

• Peering för virtuella Azure-nätverk
• VNet-till-VNet VPN-gateway (Azure-portalen, PowerShell, Azure CLI)

Peering är att föredra eftersom det använder Microsofts stamnätverk, så ur anslutningsperspektiv finns det ingen märkbar skillnad i svarstid mellan virtuella datorer i ett peer-kopplat virtuellt nätverk och i samma virtuella nätverk. Peering för virtuella nätverk stöds mellan nätverken i samma region. Global peering för virtuella nätverk stöds för instanser som finns i undernät som skapats efter den 22 september 2020. Mer information finns i Vanliga frågor och svar.

SQL Server utanför Azure

Om SQL Server-instansen finns utanför Azure upprättar du en VPN-anslutning mellan SQL Server och SQL Managed Instance med något av följande alternativ:

• Plats-till-plats-VPN-anslutning
• Azure ExpressRoute-anslutning

Dricks

Vi rekommenderar ExpressRoute för bästa nätverksprestanda när du replikerar data. Etablera en gateway med tillräckligt med bandbredd för ditt användningsfall.

Nätverksportar mellan miljöer

Oavsett anslutningsmekanismen finns det krav som måste uppfyllas för att nätverkstrafiken ska kunna flöda mellan miljöerna:

NSG-reglerna (Network Security Group) på undernätet som är värd för den hanterade instansen måste tillåta:

• Inkommande port 5022 och portintervall 11000-11999 för att ta emot trafik från SQL Server-källans IP-adress
• Utgående port 5022 för att skicka trafik till SQL Server-mål-IP

Alla brandväggar i nätverket som är värd för SQL Server och värdoperativsystemet måste tillåta:

• Inkommande port 5022 öppnades för att ta emot trafik från källans IP-intervall för MI-undernätet /24 (till exempel 10.0.0.0/24)
• Utgående portar 5022 och portintervallet 11000-11999 öppnades för att skicka trafik till mål-IP-intervallet för MI-undernätet (exempel 10.0.0.0/24)

I följande tabell beskrivs portåtgärder för varje miljö:

Environment	Vad du bör göra
SQL Server (i Azure)	Öppna både inkommande och utgående trafik på port 5022 för nätverksbrandväggen till hela undernätets IP-intervall för SQL Managed Instance. Om det behövs gör du samma sak i SQL Server-värdoperativsystemets brandvägg (Windows/Linux). Om du vill tillåta kommunikation på port 5022 skapar du en NSG-regel (network security group) i det virtuella nätverk som är värd för den virtuella datorn.
SQL Server (utanför Azure)	Öppna både inkommande och utgående trafik på port 5022 för nätverksbrandväggen till hela undernätets IP-intervall för SQL Managed Instance. Om det behövs gör du samma sak i SQL Server-värdoperativsystemets brandvägg (Windows/Linux).
SQL-hanterad instans	Skapa en NSG-regel i Azure-portalen för att tillåta inkommande och utgående trafik från IP-adressen och nätverk som är värd för SQL Server på port 5022 och portintervall 11000-11999.

Använd följande PowerShell-skript i Windows-värdoperativsystemet för SQL Server-instansen för att öppna portar i Windows-brandväggen:

New-NetFirewallRule -DisplayName "Allow TCP port 5022 inbound" -Direction inbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP
New-NetFirewallRule -DisplayName "Allow TCP port 5022 outbound" -Direction outbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP

Följande diagram visar ett exempel på en lokal nätverksmiljö som anger att alla brandväggar i miljön måste ha öppna portar, inklusive OS-brandväggen som är värd för SQL Server och eventuella företagsbrandväggar och/eller gatewayer:

Viktigt!

• Portar måste vara öppna i varje brandvägg i nätverksmiljön, inklusive värdservern, samt eventuella företagsbrandväggar eller gatewayer i nätverket. I företagsmiljöer kan du behöva visa nätverksadministratören informationen i det här avsnittet för att öppna ytterligare portar i företagsnätverksskiktet.
• Du kan välja att anpassa slutpunkten på SQL Server-sidan, men portnummer för SQL Managed Instance kan inte ändras eller anpassas.
• IP-adressintervall för undernät som är värdar för hanterade instanser och SQL Server får inte överlappa varandra.

Lägg till URL:er i allowlist

Beroende på dina nätverkssäkerhetsinställningar kan det vara nödvändigt att lägga till URL:er för SQL Managed Instance FQDN och några av de Resource Management-slutpunkter som används av Azure i listan över tillåtna.

Följande visar de resurser som ska läggas till i listan över tillåtna resurser:

• Det fullständigt kvalificerade domännamnet (FQDN) för din SQL Managed Instance. Till exempel: managedinstance1.6d710bcf372b.database.windows.net.
• Microsoft Entra-utfärdare
• Microsoft Entra-slutpunktsresurs-ID
• Resource Manager-slutpunkt
• Tjänstslutpunkt

Följ stegen i avsnittet Konfigurera SSMS för myndighetsmoln för att få åtkomst till verktygsgränssnittet i SQL Server Management Studio (SSMS) och identifiera specifika URL:er för de resurser i molnet som du behöver lägga till i listan över tillåtna.

Testa nätverksanslutning

Dubbelriktad nätverksanslutning mellan SQL Server och SQL Managed Instance krävs för att länken ska fungera. När du har öppnat portar på SQL Server-sidan och konfigurerat en NSG-regel på SQL Managed Instance-sidan testar du anslutningen med antingen SQL Server Management Studio (SSMS) eller Transact-SQL.

SSMS

Följ dessa steg för att testa nätverksanslutningen mellan SQL Server och SQL Managed Instance i SSMS:

1. Anslut till den instans som ska vara den primära repliken i SSMS.

2. I Object Explorer expanderar du databaser och högerklickar på den databas som du vill länka till den sekundära. Välj Uppgifter>Azure SQL Managed Instance-länken>Testa Anslut ion för att öppna guiden Nätverkskontroll:

   

3. Välj Nästa på sidan Introduktion i guiden Nätverkskontroll .

4. Om alla krav uppfylls på sidan Förutsättningar väljer du Nästa. Lös annars eventuella ouppfyllda krav och välj sedan Kör validering igen.

5. På sidan Inloggning väljer du Logga in för att ansluta till den andra instansen som ska vara den sekundära repliken. Välj Nästa.

6. Kontrollera informationen på sidan Ange nätverksalternativ och ange en IP-adress om det behövs. Välj Nästa.

7. På sidan Sammanfattning granskar du de åtgärder som guiden vidtar och väljer sedan Slutför för att testa anslutningen mellan de två replikerna.

8. Granska sidan Resultat för att verifiera att anslutningen finns mellan de två replikerna och välj sedan Stäng för att slutföra.

T-SQL

Om du vill använda T-SQL för att testa anslutningen måste du kontrollera anslutningen i båda riktningarna. Testa först anslutningen från SQL Server till SQL Managed Instance och testa sedan anslutningen från SQL Managed Instance till SQL Server.

Testa anslutningen från SQL Server till SQL Managed Instance

Använd SQL Server Agent på SQL Server för att köra anslutningstester från SQL Server till SQL Managed Instance.

1. Anslut till SQL Managed Instance och kör följande skript för att generera parametrar som du behöver senare:

   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';
   

   Resultaten bör se ut som i följande exempel:

   

   Spara resultatet om du vill använda nästa steg. Eftersom dessa parametrar kan ändras efter en redundansväxling måste du generera dem igen, om det behövs.

2. Anslut till SQL Server.

3. Öppna ett nytt frågefönster och klistra in följande 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. Ersätt parametrarna @node, @portoch @serverName med de värden som du fick från det första steget.

5. Kör skriptet och kontrollera resultatet. Du bör se resultat, till exempel följande exempel:

   

6. Kontrollera resultatet:

   • Resultatet av varje test vid TcpTestSucceeded bör vara TcpTestSucceeded : True.
   • RemoteAddresses ska tillhöra IP-intervallet för undernätet SQL Managed Instance.

   Om svaret misslyckas kontrollerar du följande nätverksinställningar:

   • Det finns regler i både nätverksbrandväggen och SQL Server-värdoperativsystemets brandvägg (Windows/Linux) som tillåter trafik till hela undernätets IP-intervall för SQL Managed Instance.
   • Det finns en NSG-regel som tillåter kommunikation på port 5022 för det virtuella nätverk som är värd för SQL Managed Instance.

Testa anslutningen från SQL Managed Instance till SQL Server

Om du vill kontrollera att SQL Managed Instance kan nå SQL Server skapar du först en testslutpunkt. Sedan använder du SQL Server-agenten för att köra ett PowerShell-skript med tnc kommandot pinga SQL Server på port 5022 från den SQL-hanterade instansen.

Om du vill skapa en testslutpunkt ansluter du till SQL Server och kör följande T-SQL-skript:

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

Kontrollera att SQL Server-slutpunkten tar emot anslutningar på port 5022 genom att köra följande PowerShell-kommando på värdoperativsystemet för SQL Server-instansen:

tnc localhost -port 5022

Ett lyckat test visar TcpTestSucceeded : True. Du kan sedan fortsätta att skapa ett SQL Server Agent-jobb på den SQL-hanterade instansen för att testa SQL Server-testslutpunkten på port 5022 från den SQL-hanterade instansen.

Skapa sedan ett SQL Server Agent-jobb på den SQL-hanterade instansen som anropas NetHelper genom att köra följande T-SQL-skript på den SQL-hanterade instansen. Ersätta:

• <SQL_SERVER_IP_ADDRESS> med IP-adressen för SQL Server som kan nås från EN SQL-hanterad instans.

-- 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)';

Dricks

Om du behöver ändra IP-adressen för din SQL Server för anslutningsavsökningen från sql-hanterad instans tar du bort NetHelper-jobbet genom att köra EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper'och återskapa NetHelper-jobbet med hjälp av föregående skript.

Skapa sedan en lagrad procedur ExecuteNetHelper som hjälper dig att köra jobbet och hämta resultat från nätverksavsökningen. Kör följande T-SQL-skript på SQL-hanterad instans:

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

Kör följande fråga på sql-hanterad instans för att köra den lagrade proceduren som ska köra NetHelper-agentjobbet och visa den resulterande loggen:

-- Run on managed instance
EXEC ExecuteNetHelper;

Om anslutningen lyckades visar Trueloggen . Om anslutningen misslyckades visar Falseloggen .

Om anslutningen misslyckades kontrollerar du följande:

• Brandväggen på SQL Server-värdinstansen tillåter inkommande och utgående kommunikation på port 5022.
• En NSG-regel för det virtuella nätverket som är värd för SQL Managed Instance tillåter kommunikation på port 5022.
• Om SQL Server-instansen finns på en virtuell Azure-dator tillåter en NSG-regel kommunikation på port 5022 i det virtuella nätverk som är värd för den virtuella datorn.
• SQL Server körs.
• Det finns en testslutpunkt på SQL Server.

När du har löst problem kör du NetHelper-nätverksavsökningen igen genom att köra EXEC ExecuteNetHelper på en hanterad instans.

När nätverkstestet har slutförts släpper du slutligen testslutpunkten och certifikatet på SQL Server med hjälp av följande T-SQL-kommandon:

-- Run on SQL Server
DROP ENDPOINT TEST_ENDPOINT;
GO
DROP CERTIFICATE TEST_CERT;
GO

Varning

Fortsätt endast med nästa steg om du har verifierat nätverksanslutningen mellan käll- och målmiljöerna. Annars kan du felsöka problem med nätverksanslutningen innan du fortsätter.

Migrera ett certifikat för en TDE-skyddad databas (valfritt)

Om du länkar en SQL Server-databas som skyddas av transparent datakryptering (TDE) till en hanterad instans måste du migrera motsvarande krypteringscertifikat från den lokala SQL Server-instansen eller Azure VM SQL Server-instansen till den hanterade instansen innan du använder länken. Detaljerade steg finns i Migrera ett certifikat för en TDE-skyddad databas till Azure SQL Managed Instance.

SQL Managed Instance-databaser som krypteras med tjänsthanterade TDE-nycklar kan inte länkas till SQL Server. Du kan bara länka en krypterad databas till SQL Server om den krypterades med en kundhanterad nyckel och målservern har åtkomst till samma nyckel som används för att kryptera databasen. Mer information finns i Konfigurera SQL Server TDE med Azure Key Vault.

Installera SSMS

SQL Server Management Studio (SSMS) är det enklaste sättet att använda länken Hanterad instans. Ladda ned SSMS version 19.0 eller senare och installera den på klientdatorn.

När installationen är klar öppnar du SSMS och ansluter till din SQL Server-instans som stöds. Högerklicka på en användardatabas och kontrollera att länkalternativet Azure SQL Managed Instance visas på menyn.

Konfigurera SSMS för myndighetsmoln

Om du vill distribuera din SQL Managed Instance till ett myndighetsmoln måste du ändra inställningarna för SQL Server Management Studio (SSMS) för att använda rätt moln. Om du inte distribuerar din SQL Managed Instance till ett myndighetsmoln hoppar du över det här steget.

Följ dessa steg för att uppdatera SSMS-inställningarna:

1. Öppna SSMS.
2. På menyn väljer du Verktyg och sedan Alternativ.
3. Expandera Azure Services och välj Azure Cloud.
4. Under Välj ett Azure-moln använder du listrutan för att välja AzureUSGovernment eller ett annat myndighetsmoln, till exempel AzureChinaCloud:

Om du vill gå tillbaka till det offentliga molnet väljer du AzureCloud i listrutan.

Relaterat innehåll

• Översikt över länkfunktionen För hanterad instans
• Konfigurera länk mellan SQL Server och SQL Managed Instance med SSMS
• Konfigurera länk mellan SQL Server och SQL Managed Instance med skript