Preparar o seu ambiente para um link - Instância Gerenciada de SQL do Azure

Aplica-se a:Instância Gerenciada de SQL do Azure

Este artigo ensina como preparar seu ambiente para uma vinculação de instância gerenciada para que você possa duplicar entre o SQL Server instalado no Windows ou Linux e a Instância Gerenciada de SQL do Azure.

Observação

É possível automatizar a preparação do ambiente para o link de instância gerenciada usando um script para download. Para obter mais informações, confira Blog de configuração de link de automação.

Pré-requisitos

Para criar um link entre o SQL Server e a Instância Gerenciada de SQL do Azure, você precisa dos seguintes pré-requisitos:

• Uma assinatura ativa do Azure. Se você não tiver uma, crie uma conta gratuita.
• Uma versão com suporte do SQL Server com a atualização de serviço necessária.
• Instância Gerenciada de SQL do Azure. Comece se você não tiver um.
• Um servidor que você pretende ser o primário inicial. Essa escolha determina de onde você deve criar o link.
  • A configuração de um link de um primário da Instância Gerenciada de SQL para um secundário do SQL Server 2025 é suportada apenas com instâncias gerenciadas de SQL configuradas com a política de atualização do SQL Server 2025.
  • A configuração de um link desde uma instância gerenciada primária do SQL para uma secundária do SQL Server 2022 somente tem suporte a partir do SQL Server 2022 CU10 e com instâncias gerenciadas de SQL configuradas com a política de atualização do SQL Server 2022.

Cuidado

Ao criar sua instância gerenciada de SQL para usar com o recurso de link, leve em conta os requisitos de memória para qualquer In-Memory recursos OLTP (Processamento de Transações Online) que o SQL Server usa. Para obter mais informações, confira Visão geral dos limites de recursos da Instância Gerenciada de SQL do Azure.

Permissões

No SQL Server, você deve ter permissões sysadmin.

Na Instância Gerenciada de SQL do Azure, você deve ser membro do Colaborador de Instância Gerenciada de SQL ou ter as seguintes permissões para uma função personalizada:

Recurso Microsoft.Sql/	Permissões necessárias
Microsoft.Sql/managedInstances	/ler, /escrever
Microsoft.Sql/managedInstances/hybridCertificate	/action
Microsoft.Sql/managedInstances/databases	/ler, /excluir, /escrever, /completarRestauração/ação, /lerBackups/ação, /detalhesRestauração/ler
Microsoft.Sql/managedInstances/distributedAvailabilityGroups	/ler, /escrever, /excluir, /definirPapel/ação
Microsoft.Sql/managedInstances/endpointCertificates	/read
Microsoft.Sql/managedInstances/hybridLink	/ler, /escrever, /excluir
Microsoft.Sql/managedInstances/serverTrustCertificates	/escrever, /excluir, /ler

Prepare sua instância do SQL Server

Para preparar a instância do SQL Server, você precisará validar isso:

• Você está na versão mínima com suporte.
• Você criou uma chave mestra de banco de dados no master banco de dados.
• Você habilitou o recurso grupos de disponibilidade.
• Você adicionou os sinalizadores de rastreamento adequados na inicialização.

Será necessário reiniciar o SQL Server para que essas alterações entrem em vigor.

Instalar atualizações de serviço

Certifique-se de que sua versão do SQL Server tenha a atualização de serviço apropriada instalada, conforme listado na tabela de compatibilidade de versão. Se precisar instalar atualizações, reinicie a instância do SQL Server durante a atualização.

Para verificar sua versão do SQL Server, execute o seguinte script de Transact-SQL (T-SQL) no SQL Server:

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

Criar uma chave mestra de banco de dados no banco de dados mestre

O link usa certificados para criptografar a autenticação e a comunicação entre o SQL Server e a Instância Gerenciada de SQL. A chave mestra do banco de dados protege os certificados usados pelo link. Se você já tiver uma chave mestra de banco de dados, ignore esta etapa.

Crie uma chave mestra de banco de dados no master banco de dados. Insira sua senha no lugar de <strong_password> no script a seguir e guarde-a em um lugar confidencial e seguro. Execute este script T-SQL no SQL Server:

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

Para certificar-se de que você tem uma chave mestra do banco de dados, use o seguinte script T-SQL no SQL Server:

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

Habilitar os grupos de disponibilidade

O recurso de link depende do recurso de grupos de disponibilidade Always On, que está desabilitado por padrão. Para obter mais informações, confira Habilitar o recurso de grupos de disponibilidade Always On.

Observação

Para SQL Server em Linux, consulte Habilitar grupos de disponibilidade Always On.

Para confirmar que o recurso de grupos de disponibilidade está habilitado, execute o seguinte script de T-SQL no 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'

Importante

Para o SQL Server 2016 (13.x), se você precisar habilitar o recurso de grupos de disponibilidade, deverá concluir as etapas extras documentadas no link Preparar pré-requisitos do SQL Server 2016 – Instância Gerenciada de SQL do Azure. Essas etapas extras não são necessárias para o SQL Server 2017 (14.x) e versões posteriores compatíveis com o link.

Se o recurso de grupos de disponibilidade não estiver habilitado, siga estas etapas para habilitá-lo:

1. Abra o SQL Server Configuration Manager.

2. Selecione Serviços do SQL Server no painel à esquerda.

3. Clique com o botão direito do mouse no serviço do SQL Server e selecione Propriedades.

   

4. Vá para a aba Grupos de Disponibilidade Always On.

5. Marque a caixa de seleção Habilitar os grupos de disponibilidade AlwaysOn e selecione OK.

   

   • Se estiver usando o SQL Server 2016 (13.x) e se a opção Habilitar Grupos de Disponibilidade AlwaysOn estiver desabilitada com a mensagem This computer is not a node in a failover cluster, siga as etapas extras descritas em Preparar pré-requisitos do SQL Server 2016 – link da Instância Gerenciada de SQL do Azure. Depois de concluir essas outras etapas, volte e tente novamente esta etapa.

6. Selecione OK na caixa de diálogo.

7. Reinicie o serviço SQL Server.

Habilitar sinalizadores de rastreamento na inicialização

Para otimizar o desempenho do link, é recomendável habilitar os seguintes sinalizadores de rastreamento na inicialização:

• -T1800: esse sinalizador de rastreamento otimiza o desempenho quando os arquivos de log para as réplicas primária e secundária em um grupo de disponibilidade são hospedadas em discos com tamanhos diferentes de setor, como 512 bytes e 4 KB. Se tanto as réplicas primárias quanto as secundárias tiverem um tamanho de setor de disco de 4 KB, esse sinalizador de rastreamento não será necessário. Para obter mais informações, consulte KB3009974.
• -T9567: esse sinalizador de rastreamento habilita a compactação do fluxo de dados para grupos de disponibilidade durante a propagação automática. A compactação aumenta a carga no processador, mas pode reduzir consideravelmente o tempo de transferência durante a propagação.

Observação

Para SQL Server em Linux, consulte Habilitar sinalizadores de rastreamento.

Para habilitar esses sinalizadores de rastreamento na inicialização, use as etapas a seguir:

1. Abra o SQL Server Configuration Manager.

2. Selecione Serviços do SQL Server no painel à esquerda.

3. Clique com o botão direito do mouse no serviço do SQL Server e selecione Propriedades.

   

4. Vá para a guia Parâmetros de inicialização. Em Especificar um parâmetro de inicialização, insira -T1800 e selecione Adicionar para adicionar o parâmetro de inicialização. Em seguida, insira -T9567 e selecione adicionar para adicionar o outro sinalizador de rastreamento. Selecione Aplicar para salvar as alterações.

   

5. Clique em OK para fechar a janela Propriedades.

Para obter mais informações, consulte a sintaxe para habilitar os sinalizadores de rastreamento.

Reiniciar o SQL Server e validar a configuração

Após se certificar de que está em uma versão com suporte do SQL Server, habilitou o recurso Grupos de Disponibilidade AlwaysOn e adicionou os sinalizadores de rastreamento na inicialização, reinicie sua instância do SQL Server para aplicar todas essas alterações:

1. Abra o SQL Server Configuration Manager.

2. Selecione Serviços do SQL Server no painel à esquerda.

3. Clique com o botão direito do mouse no serviço do SQL Server e selecione Reiniciar.

   

Após a reinicialização, execute o seguinte script T-SQL no SQL Server para validar a configuração de sua instância do SQL Server:

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

Sua versão do SQL Server deve ser uma das versões compatíveis aplicadas com as atualizações de serviço apropriadas, e tanto o recurso de grupos de disponibilidade Always On quanto os sinalizadores de rastreamento -T1800 e -T9567 devem estar habilitados. A captura de tela a seguir é um exemplo do resultado esperado para uma instância do SQL Server configurada corretamente:

Configurar a conectividade de rede

Para que o link funcione, você deve ter conectividade de rede entre o SQL Server e a Instância Gerenciada de SQL. A opção de rede escolhida depende se sua instância do SQL Server está ou não em uma rede do Azure.

SQL Server em Máquinas Virtuais do Azure

Implantar o SQL Server em Máquinas Virtuais do Azure na mesma rede virtual do Azure que hospeda a Instância Gerenciada de SQL é o método mais simples, pois a conectividade de rede existe automaticamente entre as duas instâncias. Para obter mais informações, confira Início Rápido: Configure uma VM do Azure para conectar à Instância Gerenciada de SQL do Azure.

Se a instância do SQL Server em Máquinas Virtuais do Azure estiver em uma rede virtual diferente da instância gerenciada de SQL, você precisará conectar as duas redes virtuais. As redes virtuais não precisam estar na mesma assinatura para que esse cenário funcione.

Há duas opções para conectar redes virtuais:

• Emparelhamento de rede virtual do Azure
• Gateway de VPN VNET a VNET (portal do Azure, PowerShell, CLI do Azure)

O emparelhamento é preferível porque usa a rede de backbone da Microsoft. Portanto, do ponto de vista da conectividade, não há nenhuma diferença perceptível na latência entre máquinas virtuais em uma rede virtual emparelhada e na mesma rede virtual. Há suporte para emparelhamento de rede virtual entre redes na mesma região. Há suporte para emparelhamento de rede virtual global para instâncias hospedadas em sub-redes criadas após 22 de setembro de 2020. Para obter mais informações, confira as Perguntas frequentes.

SQL Server fora do Azure

Se a instância do SQL Server estiver hospedada fora do Azure, estabeleça uma conexão VPN entre o SQL Server e a Instância Gerenciada do SQL usando uma das seguintes opções:

• Conexão VPN site a site
• Conexão do Azure ExpressRoute

Dica

Quando você estiver replicando dados é recomendável o ExpressRoute para o melhor desempenho de rede. Provisionar um gateway com largura de banda suficiente para seu caso de uso.

Portas de rede entre os ambientes

Independentemente do mecanismo de conectividade, há requisitos a serem atendidos para que o tráfego de rede flua entre os ambientes:

As regras do NSG (Grupo de Segurança de Rede) na sub-rede que hospeda a Instância Gerenciada de SQL precisam permitir:

• Porta de entrada 5022 e intervalo de portas 11000-11999 para receber tráfego do IP de SQL Server de origem
• Porta de saída 5022 para enviar tráfego para o IP de SQL Server de destino

Todos os firewalls na rede que hospeda o SQL Server e o sistema operacional host precisam permitir o seguinte:

• Porta de entrada 5022 aberta para receber tráfego do intervalo de IP de origem da sub-rede MI /24 (por exemplo, 10.0.0.0/24)
• As portas de saída 5022 e o intervalo de portas 11000-11999 foram abertos para enviar tráfego para o intervalo de IP de destino da sub-rede MI (exemplo 10.0.0.0/24)

A tabela a seguir descreve as ações da porta para cada ambiente:

Ambiente	O que fazer
SQL Server (no Azure)	Abra o tráfego de entrada e de saída na porta 5022 para o firewall de rede para toda a sub-rede do intervalo de IP da Instância Gerenciada do SQL. Se necessário, faça o mesmo no firewall de sistema operacional (Windows/Linux) do host do SQL Server. Para permitir a comunicação na porta 5022, crie uma regra de NSG (grupo de segurança de rede) na rede virtual que hospeda a VM (máquina virtual).
SQL Server (fora do Azure)	Abra o tráfego de entrada e de saída na porta 5022 para o firewall de rede para toda a sub-rede do intervalo de IP da Instância Gerenciada do SQL. Se necessário, faça o mesmo no firewall de sistema operacional (Windows/Linux) do host do SQL Server.
Instância Gerenciada de SQL	Crie uma regra NSG no portal do Azure para permitir o tráfego de entrada e saída do endereço IP e da rede que hospeda o SQL Server na porta 5022 e o intervalo de portas 11000-11999.

Para abrir portas no Firewall do Windows, use o seguinte script do PowerShell no sistema operacional host do Windows da instância do SQL Server:

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

O diagrama a seguir mostra um exemplo de um ambiente de rede local, indicando que todos os firewalls no ambiente precisam ter portas abertas, incluindo o firewall do sistema operacional que hospeda o SQL Server, bem como todos os firewalls corporativos e gateways:

Importante

• As portas precisam ser abertas em todos os firewalls no ambiente de rede, incluindo o servidor host e quaisquer firewalls ou gateways corporativos na rede. Em ambientes corporativos, talvez seja necessário mostrar ao administrador de rede as informações nesta seção para ajudar a abrir portas adicionais na camada de rede corporativa.
• Embora você possa optar por personalizar o ponto de extremidade no lado SQL Server, os números da porta para a Instância Gerenciada de SQL não podem ser alterados nem personalizados.
• Os intervalos de endereços IP das sub-redes que hospedam as instâncias gerenciadas e o SQL Server não devem se sobrepor.

Adicionar URLs à lista de permissões

Dependendo das configurações de segurança de rede, talvez seja necessário adicionar URLs à sua lista de permissões para o FQDN da Instância Gerenciada de SQL e alguns dos pontos de extremidade de Gerenciamento de Recursos usados pelo Azure.

A lista a seguir lista os recursos que devem ser adicionados à sua lista de permissões:

• FQDN (nome de domínio totalmente qualificado) da Instância Gerenciada de SQL. Por exemplo: managedinstance.a1b2c3d4e5f6.database.windows.net.
• Autoridade do Microsoft Entra
• ID do recurso de ponto de extremidade do Microsoft Entra
• Ponto de Extremidade do Resource Manager
• Ponto de Extremidade do Serviço

Siga as etapas na seção Configurar o SSMS para nuvens governamentais para acessar a interface de Ferramentas no SQL Server Management Studio (SSMS) e identificar as URLs específicas para os recursos na nuvem que você precisa adicionar à sua lista de permissões.

Testar a conectividade de rede

A conectividade de rede bidirecional entre o SQL Server e a Instância Gerenciada de SQL é necessária para que o link funcione. Depois de abrir as portas no lado do SQL Server e configurar uma regra NSG no lado da Instância Gerenciada de SQL, teste a conectividade usando o SQL Server Management Studio (SSMS) ou o Transact-SQL.

Teste a rede criando um trabalho temporário do SQL Agent no SQL Server e na Instância Gerenciada de SQL para verificar a conexão entre as duas instâncias. Quando você usa o Verificador de Rede no SSMS, o trabalho é criado automaticamente para você e excluído após a conclusão do teste. Você precisará excluir manualmente o trabalho do SQL Agent se testar sua rede usando T-SQL.

Observação

No momento, não há suporte para a execução de scripts do PowerShell pelo SQL Server Agent no SQL Server em Linux, portanto, não é possível executar Test-NetConnection no trabalho do SQL Server Agent no SQL Server em Linux.

Para usar o SQL Agent para testar a conectividade de rede, você precisará cumprir os seguintes requisitos:

• O usuário que faz o teste deve ter permissões para criar um trabalho (seja como um sysadmin ou pertencendo à função SQLAgentOperator para msdb) tanto para o SQL Server quanto para a Instância Gerenciada de SQL.
• O serviço SQL Server Agent deve estar em execução no SQL Server. Como o agente está ativado por padrão na Instância Gerenciada de SQL, nenhuma ação adicional é necessária.

Considere o seguinte:

• Para evitar falsos negativos, todos os firewalls ao longo do caminho de rede devem permitir o tráfego de ICMP (Internet Control Message Protocol).
• Para evitar falsos positivos, todos os firewalls ao longo do caminho de rede devem permitir o tráfego no protocolo UCS proprietário do SQL Server. Bloquear o protocolo pode levar a um teste de conexão bem-sucedido, mas a conexão não é criada.
• As configurações avançadas de firewall com guardrails no nível de pacote no local precisam ser configuradas corretamente para permitir o tráfego entre o SQL Server e a Instância Gerenciada de SQL.

SSMS

Para testar a conectividade de rede entre o SQL Server e a instância gerenciada do SQL no SSMS, execute estas etapas:

1. Conecte-se à instância que será a réplica primária no SSMS.

2. No Pesquisador de Objetos, expanda bancos de dados e clique com o botão direito do mouse no banco de dados que você pretende vincular ao secundário. Selecione Tarefas>Instância Gerenciada SQL do Azure link>Testar Conexão para abrir o assistente do Verificador de Rede:

   

3. Selecione Avançar na página Introdução do assistente Verificador de Rede.

4. Se todos os requisitos forem atendidos na página Pré-requisitos, selecione Avançar. Caso contrário, resolva os pré-requisitos não atendidos e selecione Executar novamente a validação.

5. Na página Logon, selecione Logon para se conectar à outra instância que será a réplica secundária. Selecione Avançar.

6. Verifique os detalhes na página Especificar Opções de Rede e forneça um endereço IP, se necessário. Selecione Avançar.

7. Na página Resumo, examine as ações executadas pelo assistente e selecione Concluir para testar a conexão entre as duas réplicas.

8. Examine a página Resultados para validar a conectividade existente entre as duas réplicas e selecione Fechar para concluir.

T-SQL

Para usar o T-SQL para testar a conectividade, você precisa verificar a conexão em ambas as direções. Primeiro, teste a conexão do SQL Server com a Instância Gerenciada do SQL e, em seguida, teste a conexão da Instância Gerenciada do SQL com o SQL Server.

Testar conectividade do SQL Server para a Instância Gerenciada de SQL

Use o SQL Server Agent no SQL Server para executar testes de conectividade do SQL Server para a Instância Gerenciada de SQL.

1. Conecte-se à Instância Gerenciada de SQL e execute o seguinte script para gerar os parâmetros de que você precisará mais tarde:

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

   Os resultados devem ser semelhantes ao seguinte exemplo:

    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'
   

   Salve os resultados para usar nas próximas etapas. Como esses parâmetros podem ser alterados após qualquer failover, certifique-se de gerá-los novamente, se necessário.

2. Conecte-se à instância do SQL Server.

3. Abra um novo período de consulta e cole o seguinte script:

   --START
   -- Parameters section
   DECLARE @node NVARCHAR(512) = N''
   DECLARE @port NVARCHAR(512) = N''
   DECLARE @serverName NVARCHAR(512) = N''
   
   --Script section
   IF EXISTS (
           SELECT job_id
           FROM msdb.dbo.sysjobs_view
           WHERE name = N'TestMILinkConnection'
           )
       EXEC msdb.dbo.sp_delete_job @job_name = N'TestMILinkConnection',
           @delete_unused_schedule = 1
   
   DECLARE @jobId BINARY (16),
       @cmd NVARCHAR(MAX)
   
   EXEC msdb.dbo.sp_add_job @job_name = N'TestMILinkConnection',
       @enabled = 1,
       @job_id = @jobId OUTPUT
   
   SET @cmd = (N'tnc ' + @serverName + N' -port 5022 | select ComputerName, RemoteAddress, TcpTestSucceeded | Format-List')
   
   EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
       @step_name = N'Test Port 5022',
       @step_id = 1,
       @cmdexec_success_code = 0,
       @on_success_action = 3,
       @on_fail_action = 3,
       @subsystem = N'PowerShell',
       @command = @cmd,
       @database_name = N'master'
   
   SET @cmd = (N'tnc ' + @node + N' -port ' + @port + ' | select ComputerName, RemoteAddress, TcpTestSucceeded | Format-List')
   
   EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
       @step_name = N'Test HADR Port',
       @step_id = 2,
       @cmdexec_success_code = 0,
       @subsystem = N'PowerShell',
       @command = @cmd,
       @database_name = N'master'
   
   EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId,
       @server_name = N'(local)'
   GO
   
   EXEC msdb.dbo.sp_start_job @job_name = N'TestMILinkConnection'
   GO
   
   --Check status every 5 seconds
   DECLARE @RunStatus INT
   
   SET @RunStatus = 10
   
   WHILE (@RunStatus >= 4)
   BEGIN
       SELECT DISTINCT @RunStatus = run_status
       FROM [msdb].[dbo].[sysjobhistory] JH
       INNER JOIN [msdb].[dbo].[sysjobs] J
           ON JH.job_id = J.job_id
       WHERE J.name = N'TestMILinkConnection'
           AND step_id = 0
   
       WAITFOR DELAY '00:00:05';
   END
   
   --Get logs once job completes
   SELECT [step_name],
       SUBSTRING([message], CHARINDEX('TcpTestSucceeded', [message]), CHARINDEX('Process Exit', [message]) - CHARINDEX('TcpTestSucceeded', [message])) AS    TcpTestResult,
       SUBSTRING([message], CHARINDEX('RemoteAddress', [message]), CHARINDEX('TcpTestSucceeded', [message]) - CHARINDEX('RemoteAddress', [message])) AS    RemoteAddressResult,
       [run_status],
       [run_duration],
       [message]
   FROM [msdb].[dbo].[sysjobhistory] JH
   INNER JOIN [msdb].[dbo].[sysjobs] J
       ON JH.job_id = J.job_id
   WHERE J.name = N'TestMILinkConnection'
       AND step_id <> 0
       --END
   

4. Substitua os parâmetros @node, @port e @serverName pelos valores obtidos na primeira etapa.

5. Execute o script e verifique os resultados. Você deve ver resultados como os do seguinte exemplo:

   

6. Verifique os resultados:

   • O resultado de cada teste em TcpTestSucceeded deve ser TcpTestSucceeded : True.
   • O RemoteAddresses deve pertencer ao intervalo de IP da sub-rede da Instância Gerenciada de SQL.

   Se a resposta não for bem-sucedida, verifique as seguintes configurações de rede:

   • Há regras no firewall de rede e no firewall do sistema operacional host do SQL Server (Windows/Linux) que permitem o tráfego para todo o intervalo de IP da sub-rede da Instância Gerenciada de SQL.
   • Há uma regra de NSG, que permite comunicação na porta 5022, para a rede virtual hospedando a Instância Gerenciada de SQL.

Testar conectividade da Instância Gerenciada de SQL para o SQL Server

Para verificar se Instância Gerenciada de SQL pode alcançar o SQL Server, crie primeiro um teste de ponto de extremidade. Em seguida, use o SQL Server Agent para executar um script do PowerShell com o comando tnc executando ping do SQL Server na porta 5022 por meio da instância gerenciada de SQL.

Para criar um teste de ponto de extremidade, conecte-se ao SQL Server e execute o seguinte script 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
    )

Para verificar se o ponto de extremidade do SQL Server está recebendo conexões na porta 5022, execute o seguinte comando do PowerShell no sistema operacional do host da instância do SQL Server:

tnc localhost -port 5022

Um teste bem-sucedido mostrará TcpTestSucceeded : True. Em seguida, você pode continuar a criar um trabalho do SQL Server Agent na instância gerenciada do SQL para tentar testar o ponto de extremidade de teste do SQL Server na porta 5022 por meio da instância gerenciada do SQL.

Em seguida, crie um trabalho do SQL Server Agent na instância gerenciada do SQL chamado NetHelper executando o script T-SQL a seguir na instância gerenciada do SQL. Substitua:

• <SQL_SERVER_IP_ADDRESS> com o endereço IP do SQL Server que pode ser acessado por meio da instância gerenciada.

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

Dica

Se precisar modificar o endereço IP do SQL Server na investigação de conectividade da instância gerenciada de SQL, exclua o cargo do NetHelper executando EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper' e recrie o NetHelper usando o script anterior.

Em seguida, crie um procedimento armazenado ExecuteNetHelper que ajudará a executar o cargo e obter os resultados da investigação de rede. Execute o seguinte script T-SQL na instância gerenciada de 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;

Realize a seguinte consulta na instância gerenciada para aplicar o procedimento armazenado que executará o trabalho do agente NetHelper e mostrará o log resultante:

-- Run on managed instance
EXEC ExecuteNetHelper;

Se a conexão for bem-sucedida, o log mostrará True. Se a conexão não for bem-sucedida, o log mostrará False.

Se a conexão não foi bem-sucedida, verifique os seguintes itens:

• O firewall na instância do SQL Server hospedada permite a comunicação de entrada e saída na porta 5022.
• Uma regra de NSG para a rede virtual que hospeda a Instância Gerenciada de SQL permite comunicação na porta 5022.
• Se a instância do SQL Server estiver em uma VM do Azure, uma regra de NSG permite a comunicação na porta 5022 na rede virtual que hospeda a VM.
• O SQL Server está em execução.
• Há um ponto de extremidade de teste no SQL Server.

Depois de resolver os problemas, execute novamente a investigação de rede do NetHelper executando EXEC ExecuteNetHelper na instância gerenciada.

Por fim, depois que o teste de rede for bem-sucedido, remova o ponto de extremidade de teste e o certificado no SQL Server usando os seguintes comandos T-SQL:

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

Cuidado

Continue com as próximas etapas somente se você validou a conectividade de rede entre os ambientes de origem e de destino. Caso contrário, solucione os problemas de conectividade de rede antes de continuar.

Migrar um certificado de um banco de dados protegido por TDE (opcional)

Se você estiver vinculando um banco de dados do SQL Server protegido pela Transparent Data Encryption (TDE) a uma instância gerenciada de SQL, deverá migrar o certificado de criptografia correspondente da instância do SQL Server da VM do Azure ou local para a instância gerenciada de SQL antes de usar o link. Para etapas detalhadas, consulte Migrar um certificado de um banco de dados protegido por TDE-para a Instância Gerenciada de SQL do Azure.

Os bancos de dados da Instância Gerenciada de SQL criptografados com chaves TDE gerenciadas pelo serviço não podem ser vinculados ao SQL Server. Você só poderá vincular um banco de dados criptografado ao SQL Server se ele tiver sido criptografado com uma chave gerenciada pelo cliente e o servidor de destino tiver acesso à mesma chave usada para criptografar o banco de dados. Para obter mais informações, confira Configurar SQL Server TDE com o Azure Key Vault.

Observação

O Azure Key Vault tem suporte do SQL Server no Linux a partir da Atualização Cumulativa 14 para SQL Server 2022.

Instalar SSMS

O SSMS (SQL Server Management Studio) é a maneira mais fácil de usar o link da Instância Gerenciada. Instale a versão mais recente do SSMS (SQL Server Management Studio) no computador cliente.

Após concluir a instalação, abra o SSMS e conecte-se à instância de SQL Server com suporte. Clique com o botão direito do mouse em um banco de dados de usuário e valide que a opção link da Instância Gerenciada de SQL do Azure aparece no menu.

Configurar o SSMS para as nuvens governamentais

Se você quiser implantar a Instância Gerenciada de SQL em uma nuvem governamental, precisará modificar as configurações do SQL Server Management Studio (SSMS) para usar a nuvem correta. Se você não estiver implantando a Instância Gerenciada de SQL em uma nuvem governamental, ignore esta etapa.

Para atualizar as configurações do SSMS, siga estas etapas:

1. Abra o SSMS.
2. No menu, escolha Ferramentas e Opções.
3. Expanda Serviços do Azure e selecione Nuvem do Azure.
4. Em Selecionar uma nuvem do Azure, use a lista suspensa para escolher AzureUSGovernment ou outra nuvem do governo, como a AzureChinaCloud:

Se você quiser voltar para a nuvem pública, escolha AzureCloud na lista suspensa.

Conteúdo relacionado

Para usar o link:

• Configurar o link entre o SQL Server e a instância gerenciada do SQL com o SSMS
• Configurar o link entre o SQL Server e a instância gerenciada de SQL com os scripts
• Fazer failover do link
• Migrar com o link
• Práticas recomendadas para manter o link

Para saber mais sobre o link:

• Visão geral do Link da Instância Gerenciada
• Recuperação de desastre com link de instância gerenciada

Para outros cenários de replicação e migração, considere:

• Replicação transacional com a Instância Gerenciada de SQL
• LRS (Serviço de Reprodução de Log)