Solucionar problemas de ligação - Instância SQL Gerida do Azure

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

Este artigo ensina como monitorizar e solucionar problemas com um link de entre o SQL Server e o Azure SQL Managed Instance.

Você pode verificar o estado do link com o Transact-SQL (T-SQL), o Azure PowerShell ou a CLI do Azure. Se você encontrar problemas, você pode usar os códigos de erro para solucionar o problema.

Muitos problemas com a criação do link podem ser resolvidos verificando o de rede entre as duas instâncias e validando o ambiente de foi devidamente preparado para o link.

Semeadura inicial

Ao estabelecer um vínculo entre o SQL Server e a Instância Gerenciada do SQL do Azure, há uma fase inicial de propagação antes do início da replicação de dados. A fase inicial de semeadura é a parte mais longa e cara da operação. Quando a propagação inicial é concluída, os dados são sincronizados e apenas as alterações de dados subsequentes são replicadas. O tempo necessário para a conclusão da propagação inicial depende do tamanho dos dados, da intensidade da carga de trabalho nos bancos de dados primários e da velocidade do link entre as redes das réplicas primária e secundária.

Se a velocidade da ligação entre as duas instâncias for mais lenta do que o necessário, é provável que o tempo de inicialização seja perceptivelmente afetado. Você pode usar a velocidade de propagação declarada, o tamanho total dos dados e a velocidade do link para estimar quanto tempo a fase inicial de propagação levará antes que a replicação de dados seja iniciada. Por exemplo, para um único banco de dados de 100 GB, a fase inicial de propagação levaria cerca de 1,2 horas se o link for capaz de enviar 84 GB por hora e se não houver outros bancos de dados sendo semeados para um link diferente. Se o link só puder transferir 10 GB por hora, a propagação de um banco de dados de 100 GB pode levar cerca de 10 horas. Se houver vários bancos de dados para replicar por meio de vários links, a propagação será executada em paralelo e, quando combinada com uma velocidade de link lenta, a fase inicial de propagação pode levar consideravelmente mais tempo, especialmente se a propagação paralela de dados de todos os bancos de dados exceder a largura de banda de link disponível.

A fase inicial de disseminação não é resiliente a interrupções de rede, problemas de manutenção de instâncias ou operações de failover. Se a conectividade bidirecional entre o SQL Server e a Instância Gerida do SQL for temporariamente perdida ou se o SQL Server ou a Instância Gerida do SQL for reiniciada ou sofrer um failover durante a fase inicial de seeding, o seeding será reiniciado.

Importante

A fase inicial de semeadura pode levar dias com links de velocidade extremamente baixa ou muito ocupados. Nesse caso, a criação do link pode expirar. A criação do link é cancelada automaticamente após 6 dias.

Verificar estado do link

Se você tiver problemas com um link, poderá usar o SQL Server Management Studio (SSMS), o Transact-SQL (T-SQL), o Azure PowerShell ou a CLI do Azure para obter informações sobre o estado atual do link.

Use o T-SQL para obter detalhes rápidos do status do link e, em seguida, use o Azure PowerShell ou a CLI do Azure para obter informações abrangentes sobre o estado atual do link.

SSMS

O monitoramento de links está disponível a partir do SQL Server Management Studio (SSMS) 21.0 (visualização).

Para verificar o estado do link no SSMS, siga estas etapas:

1. Conecte-se a uma réplica que hospeda o link.

2. No Pesquisador de Objetos, expanda Sempre em Alta Disponibilidade e, em seguida, expanda Grupos de Disponibilidade.

3. Clique com o botão direito do mouse no nome do link e selecione Propriedades para abrir a janela Propriedades do link :

   

4. A janela Propriedades do link exibe informações úteis sobre o link, como informações de réplica, estado do link e data de expiração do certificado do ponto de extremidade:

   

Use o T-SQL para determinar o estado do link durante a fase de propagação ou após o início da sincronização de dados.

Use a seguinte consulta T-SQL para determinar o status do link durante a fase de propagação no SQL Server ou na Instância Gerenciada do SQL que hospeda o banco de dados semeado por meio do link:

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

Se a consulta não retornar nenhum resultado, o processo de propagação não foi iniciado ou já foi concluído.

Use a seguinte consulta T-SQL na instância primária de para verificar a integridade do link a partir do momento em que a sincronização de dados começa:

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

A consulta retorna os seguintes valores possíveis:

• sem resultado: a consulta foi executada na instância secundária.
• HEALTHY: O link está íntegro e os dados estão sendo sincronizados entre as réplicas.
• NOT_HEALTHY: A ligação não está estável e os dados não estão a sincronizar entre as réplicas.

PowerShell

Utilize Get-AzSqlInstanceLink para obter informações de estado do link com o PowerShell.

Execute o código de exemplo a seguir no Azure Cloud Shell ou instale o módulo Az.SQL localmente.

$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

Utilize az sql mi link show para obter informações sobre o estado do link usando a CLI do Azure.

# 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  

O valor replicaState descreve o link atual. Se o estado incluir também Erro , ocorreu um erro durante a operação mencionada no estado. Por exemplo, LinkCreationError indica que ocorreu um erro ao criar o link.

Alguns valores possíveis replicaState são:

• CriarLigação : Semeadura inicial
• LinkSynchronizing: A replicação de dados está em andamento
• LinkFailoverInProgress: O failover está em andamento

Para obter uma lista completa das propriedades do estado do link, revise o comando Distributed Availability Groups - GET REST API.

Erros com o link

Há duas categorias distintas de erros que você pode encontrar ao usar o link - erros quando você tenta inicializar o link e erros quando você tenta criar o link.

Erros ao inicializar um link sql-server-2016-database-engine-events-and-errors-1000-1999

O seguinte erro pode ocorrer ao inicializar um link (estado do link: LinkInitError):

• Erro 41962: Operação abortada porque o link não foi iniciado em 5 minutos. Verifique a conectividade de rede e tente novamente.
• Erro 41973: O link não pode ser estabelecido porque o certificado de ponto de extremidade do SQL Server não foi importado corretamente para a Instância Gerida SQL do Azure.
• Erro 41974: A ligação não pode ser estabelecida porque o certificado de ponto de extremidade da Instância Gerida do SQL não foi importado para o SQL Server corretamente.
• Erro 41976: O grupo de disponibilidade não está respondendo. Verifique os nomes e os parâmetros de configuração e tente novamente.
• Erro 41986: O link não pode ser estabelecido porque a conexão falhou ou a réplica secundária não está respondendo. Verifique nomes, parâmetros de configuração e conectividade de rede e tente novamente.
• Erro 47521: O link não pode ser estabelecido porque o servidor secundário não recebeu a solicitação. Verifique se o grupo de disponibilidade e os bancos de dados estão íntegros no servidor primário e tente novamente.

Erros ao criar um link

Os seguintes erros podem ocorrer ao criar um link (estado do link: LinkCreationError):

• Erro 41977: O banco de dados de destino não está respondendo. Verifique os parâmetros do link e tente novamente.

• Truncamento prematuro do log: Se o log de transações for truncado antes que a propagação inicial termine, é provável que você veja um dos seguintes erros:

  • Erro 1408: A cópia remota do banco de dados "%.*ls" não é recuperada o suficiente para habilitar o espelhamento do banco de dados ou para associá-lo ao grupo de disponibilidade.
  • Erro 1412: A cópia remota do banco de dados "%.*ls" não foi avançada para um ponto no tempo que está coberto pela cópia local do log do banco de dados.

  Para resolver esse problema, você deve soltar e recriar o link.
  Para evitar esse problema, pause os backups de log de transações no SQL Server para que o banco de dados seja replicado durante a fase inicial de propagação.

Estado inconsistente após failover forçado

Após umade failover de forçada, você pode encontrar um cenário de cérebro dividido em que ambas as réplicas estão na função principal, deixando o link em um estado inconsistente. Isso pode acontecer se você fizer failover para a réplica secundária durante um desastre e, em seguida, a réplica primária voltar a ficar online.

Primeiro, confirme que você está em um cenário de cérebro dividido. Você pode fazer isso usando o SQL Server Management Studio (SSMS) ou o Transact-SQL (T-SQL).

Conecte-se à instância gerenciada do SQL Server e do SQL no SSMS e, em seguida, nodo Pesquisador de Objetos, expanda réplicas de Disponibilidade no nó grupo Disponibilidade node Alta Disponibilidade Always On . Se duas réplicas diferentes estiverem listadas como (Principal), você estará em um cenário de cérebro dividido.

Como alternativa, você pode executar o seguinte script T-SQL no SQL Server e na Instância Gerenciada do SQL para verificar a função das réplicas:

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

Se ambas as instâncias listarem PRIMÁRIO em coluna função Link, você estará em um cenário de cérebro dividido.

Para resolver o estado cerebral dividido, primeiro faça um backup em qualquer réplica que fosse a primária original. Se o primário original era o SQL Server, faça um backup de log final . Se o primário original era a Instância Gerenciada SQL, faça um backup completo somente cópia. Após a conclusão do backup, atribua a função secundária ao grupo de disponibilidade distribuída para a réplica que costumava ser a primária original, mas que agora será a nova secundária.

Por exemplo, no caso de um verdadeiro desastre, supondo que você forçou um failover de sua carga de trabalho do SQL Server para a Instância Gerenciada SQL do Azure e pretende continuar executando sua carga de trabalho na Instância Gerenciada do SQL, faça um backup de log final no SQL Server e defina o grupo de disponibilidade distribuída para a função secundária no SQL Server, como o exemplo a seguir:

--Execute on SQL Server 
USE master
ALTER AVAILABILITY GROUP [<DAGName>] 
SET (ROLE = SECONDARY) 
GO 

Em seguida, execute um failover manual planejado da Instância Gerenciada do SQL para o SQL Server usando o link, como o exemplo a seguir:

--Execute on SQL Managed Instance 
USE master
ALTER AVAILABILITY GROUP [<DAGName>] FAILOVER 
GO 

Certificado expirado

É possível que o certificado usado para o link expire. Se o certificado expirar, o link falhará. Para resolver esse problema, gire o certificado.

Testar a conectividade de rede

A conectividade de rede bidirecional entre o SQL Server e a Instância Gerenciada do SQL é necessária para que o link funcione. Depois de abrir portas no lado do SQL Server e configurar uma regra NSG no lado da Instância Gerenciada 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 do SQL para verificar a conexão entre as duas instâncias. Quando utiliza o Verificador de Rede no SSMS, a tarefa é criada automaticamente para si e eliminada 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

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

Para usar o SQL Agent para testar a conectividade de rede, você precisa dos seguintes requisitos:

• O utilizador que faz o teste deve ter permissões de para criar uma tarefa (como sysadmin ou pertença à função SQLAgentOperator em ) tanto para o SQL Server como para a Instância Gerida do SQL.
• O serviço SQL Server Agent deve estar executando no SQL Server. Como o Agente está ativado por padrão na Instância Gerenciada SQL, nenhuma ação adicional é necessária.

Considere o seguinte:

• Para evitar falsos negativos, todos os firewalls ao longo do caminho da rede devem permitir o tráfego do Protocolo de Mensagens de Controlo da Internet (ICMP).
• Para evitar falsos positivos, todos os firewalls ao longo do caminho de rede devem permitir o tráfego no protocolo proprietário SQL Server UCS. Bloquear o protocolo pode levar a um teste de ligação bem-sucedido, mas a ligação não se cria.
• Configurações avançadas de firewall com guardas ao nível de pacotes precisam de ser devidamente configuradas para permitir o tráfego entre SQL Server e SQL Managed Instance.

SSMS

Para testar a conectividade de rede entre o SQL Server e a Instância Gerenciada do SQL no SSMS, siga estas etapas:

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

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

   

3. Selecione Próximo na página de Introdução do assistente do Verificador de Rede.

4. Se todos os requisitos forem atendidos na página de Pré-requisitos , selecione Avançar. Caso contrário, resolva os pré-requisitos não atendidos e, em seguida, selecione Reexecutar Validação.

5. Na página de login , selecione a opção de login 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, revise as ações executadas pelo assistente e selecione Concluir para testar a conexão entre as duas réplicas.

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

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 a conexão do SQL Server para o SQL Managed Instance

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

1. Conecte-se à Instância Gerenciada SQL e execute o seguinte script para gerar parâmetros necessários 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 exemplo a seguir:

    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 as próximas etapas. Como esses parâmetros podem mudar após qualquer failover, certifique-se de gerá-los novamente, se necessário.

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

3. Abra uma nova janela 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, @porte @serverName pelos valores obtidos na primeira etapa.

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

   

6. Verifique os resultados:

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

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

   • Há regras no firewall de rede e 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 do SQL.
   • Há uma regra NSG que permite a comunicação na porta 5022 para a rede virtual que hospeda a Instância Gerenciada SQL.

Testar a conexão da instância gerenciada do SQL para o SQL Server

Para verificar se a Instância Gerida do SQL consegue aceder ao SQL Server, comece por criar um ponto de extremidade de teste. Em seguida, use o SQL Server Agent para executar um script do PowerShell com o comando tnc para executar um ping ao SQL Server na porta 5022 a partir da instância gerida de SQL.

Para criar um ponto de extremidade de teste, 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á a receber conexões na porta 5022, execute o seguinte comando do PowerShell no sistema operativo host da sua instância do SQL Server:

tnc localhost -port 5022

Um teste bem-sucedido mostra 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 da instância gerenciada do SQL.

Em seguida, crie um trabalho do SQL Server Agent na instância gerenciada do SQL chamada NetHelper executando o seguinte script T-SQL na instância gerenciada do SQL. Substituir:

• <SQL_SERVER_IP_ADDRESS> com o endereço IP do SQL Server que pode ser acessado a partir da instância gerenciada do 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)';

Dica

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

Em seguida, crie um procedimento armazenado ExecuteNetHelper que ajude a executar a tarefa e obtenha resultados da sonda de rede. Execute o seguinte script T-SQL na instância gerenciada do 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;

Execute a seguinte consulta na instância gerenciada SQL para executar 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 foi bem-sucedida, o log mostra True. Se a conexão não foi bem-sucedida, o log mostra False.

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

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

Depois de resolver problemas, execute novamente a sonda de rede NetHelper executando EXEC ExecuteNetHelper na instância gerenciada.

Finalmente, após o teste de rede ser bem-sucedido, elimine o endpoint de teste e o certificado no SQL Server usando os seguintes scripts T-SQL:

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

Atenção

Prossiga com as próximas etapas somente se tiver validado a conectividade de rede entre seus ambientes de origem e de destino. Caso contrário, solucione problemas de conectividade de rede antes de continuar.

Conteúdo relacionado

Para obter mais informações sobre o recurso de link, revise os seguintes recursos:

• Visão geral do link Instância Gerenciada
• Preparar seu ambiente para o link Instância gerenciada
• Configurar o link entre o SQL Server e a instância gerenciada do SQL com scripts
• Recuperação de desastres com instância gerenciada link
• Práticas recomendadas para manter o link