Solucionar problemas de conexão – Instância Gerenciada de SQL do Azure

Applies to:Instância Gerenciada de SQL do Azure

Este artigo ensina como monitorar e solucionar problemas com um link entre SQL Server e Instância Gerenciada de SQL do Azure.

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

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

Semeadura inicial

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

Caso a velocidade do link entre as duas instâncias seja mais lenta do que o necessário, provavelmente o tempo de propagação será significativamente 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 de propagação inicial levará antes do início da replicação de dados. Por exemplo, para um único banco de dados de 100 GB, a fase inicial de preparação levaria cerca de 1,2 horas se o link fosse capaz de transferir 84 GB por hora e se não houver nenhum outro banco de dados sendo preparado 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 a serem replicados por meio de vários links, a propagação será executada em paralelo e, quando combinada com uma velocidade de vínculo lenta, a fase de propagação inicial poderá demorar consideravelmente mais, especialmente se a propagação paralela de dados de todos os bancos de dados exceder a largura de banda do link disponível.

A fase inicial de semeadura não é resiliente a interrupções de rede e a operações de manutenção ou comutação por falha de instância. Se a conectividade bidirecional entre SQL Server e Instância Gerenciada de SQL for perdida temporariamente ou se o SQL Server ou Instância Gerenciada de SQL for reiniciado ou falhar durante a fase inicial de semeadura, a semeadura será reiniciada.

Importante

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

Verificar o estado do link

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

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

O monitoramento de link está disponível a partir do SQL Server Management Studio (SSMS) 21.0 (versão prévia).

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

Conecte-se a uma réplica que hospeda o link.
Em Pesquisador de Objetos, expanda Always On High Availability e expanda Availability Groups.
Clique com o botão direito do mouse no nome do link e selecione Propriedades para abrir a janela Propriedades do Link :
A janela Propriedades do Link exibe informações úteis sobre o link, como informações de réplica, estado do link e data de validade 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. O sys.dm_hadr_physical_seeding_stats DMV pode ser usado para acompanhar o status de propagação inicial. A coluna estimate_time_complete_utc é baseada no transfer_rate_bytes_per_second atual e no tamanho dos dados restantes descompactados (quando is_compression_enabled = 0). Para Instância Gerenciada link, a compactação de dados é usada, portanto, espera-se que estimate_time_complete_utc seja superestimado.

Use a seguinte consulta T-SQL para determinar o status do link durante a fase de propagação no SQL Server ou Instância Gerenciada de 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 resultados, 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 para verificar a integridade do link assim que a sincronização de dados começar:

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: o link não está íntegro e os dados não estão sincronizando entre as réplicas.

Use Get-AzSqlInstanceLink para obter informações de estado de 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

Use az sql mi link show para obter informações de estado de link com o 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 também incluir Erro , ocorreu um erro durante a operação listada no estado. Por exemplo, LinkCreationError indica que ocorreu um erro ao criar o link.

Alguns valores possíveis de replicaState são:

CreatingLink: propagação inicial
LinkSynchronizing: A replicação de dados está em andamento
LinkFailoverInProgress: o failover está em andamento

Para obter uma lista completa das propriedades de estado do link, examine o comando Grupos de Disponibilidade Distribuída – API REST GET .

Tempo limite de failover planejado

Se a réplica secundária não conseguir acompanhar as alterações na réplica primária e ficar para trás, o failover planejado poderá acabar e falhar com um erro.

Para resolver esse problema, siga estas etapas:

Verifique o atraso de replicação entre as duas instâncias.
Se o atraso de replicação for alto, aguarde até que a réplica secundária acompanhe a réplica primária. Talvez seja necessário executar etapas adicionais de solução de problemas se o atraso persistir, como pausar cargas de trabalho na réplica primária, melhorar a taxa de transferência de rede de vínculo entre as duas instâncias ou aumentar a capacidade do recurso na réplica secundária.
- A maneira mais fácil de parar cargas de trabalho em uma réplica primária SQL Server é cortar conexões de aplicativo com a instância.
Depois que a réplica secundária tiver alcançado a réplica primária, tente o failover planejado novamente.

Erros ao inicializar um link

O erro a seguir pode ocorrer ao inicializar um link (Estado do link: LinkInitError):

Erro 41962: Operação anulada porque o link não foi iniciado em 5 minutos. Verifique a conectividade de rede e tente novamente.
Error 41973: o link não pode ser estabelecido porque endpoint certificate from SQL Server não foi importado para Instância Gerenciada de SQL do Azure corretamente.
Error 41974: o link não pode ser estabelecido porque endpoint certificate from Instância Gerenciada de SQL não foi importado para 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 responde. Verifique os nomes, os parâmetros de configuração e a 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 responde. Verifique os parâmetros de link e tente novamente.
Truncamento de log prematuro: se o log de transações for truncado antes da conclusão da semeadura inicial, é provável que você veja um dos seguintes erros:
- Erro 1408: Falha na replicação do banco de dados remoto e não pode ser recuperada devido a uma sobreposição de arquivo de log ausente entre a réplica primária e secundária. Exclua o link existente e crie um novo link para reiniciar a replicação.
- Erro 1412: Falha na replicação para o banco de dados remoto e não pode ser recuperada devido a uma incompatibilidade de tamanho de arquivo de log com a réplica primária. Exclua o link existente e crie um novo link para reiniciar a replicação.

Erro 1412

Quando você cria um link pela primeira vez, a primeira parte do processo propaga um backup completo do banco de dados da réplica primária para a réplica secundária. Após a conclusão da propagação do backup completo, o link começa a replicar dados aplicando dados diferenciais da réplica primária à réplica secundária. Esse processo continua indefinidamente até que um comando de failover seja emitido ou o link seja removido.

Se ocorrer um backup de log de transações na réplica primária durante a propagação inicial do backup completo, o log de transações truncará. A criação de link falha com o erro 1412, pois os dados no log de transações necessários para propagação inicial não estão mais disponíveis. Se você vir o erro 1412 no log de erros do SQL Server no Instância Gerenciada de SQL do Azure, deverá drop e recriar o link.

Para evitar esse problema, pause os backups de log de transações durante a fase inicial de preparação.

Se os backups de log de transações forem necessários durante a fase inicial de propagação, especialmente para bancos de dados muito grandes, você poderá optar por impedir manualmente o truncamento de log ou automatizar o processo com um script T-SQL para pausar automaticamente os backups de log em fases críticas e quando ele estiver seguro.

Prevenção manual de truncamento de log

As etapas nesta seção demonstram como abrir uma transação em uma tabela fictícia para evitar o truncamento de log durante a fase inicial de propagação. Esse processo requer o monitoramento manual do progresso da semeadura e a sincronização cuidadosa para garantir que o truncamento de log seja evitado até que a semeadura seja concluída.

Monitore o progresso da distribuição. Você pode usar a seguinte consulta T-SQL para monitorar o progresso da propagação inicial:
```
SELECT * FROM sys.dm_exec_requests WHERE database_id = @dbId AND command = 'VDI_CLIENT_WORKER'
```
Quando a semeadura estiver perto de 90% de conclusão, emita um comando BEGIN TRAN em uma tabela fictícia sem confirmação para manter uma transação aberta e impedir o truncamento do log.
Monitore cuidadosamente o espaço em disco do log de transações para garantir que ele não exceda a capacidade de armazenamento enquanto a transação estiver aberta.
Quando a distribuição atingir 100%, conclua a transação com COMMIT TRAN.

Por exemplo, a qualquer momento antes que a propagação inicial atinja 90%, execute o seguinte comando para criar uma tabela fictícia com a finalidade de evitar o erro 1412:

-- Create table
CREATE TABLE Prevent1412
(
    Id        INT,
    CreatedAt DATETIME
);

Em seguida, quando o semeio estiver quase completo, execute o seguinte comando para evitar o truncamento de logs:

BEGIN TRAN;

INSERT INTO Prevent1412 (Id, CreatedAt)
VALUES (1, GETDATE());

Cuidado

Após o início da transação, o log de transações não é mais truncado, portanto, monitore cuidadosamente o espaço em disco do log de transações para garantir que ele não exceda a capacidade de armazenamento enquanto a transação estiver aberta.

Depois que a semeadura for concluída, você poderá confirmar a transação para truncar o log.

COMMIT TRAN;

Após a conclusão da migração, você pode remover a tabela fictícia:

DROP TABLE Prevent1412;

Automatizar a pausa automática dos backups de log

Como alternativa, você pode automatizar o processo para pausar automaticamente os backups de log em fases críticas quando ele estiver seguro com um script T-SQL.

O script a seguir pode ser executado antes do início da migração:

-- Get last backup date
SELECT TOP 1 @lastBackupTime = b.backup_finish_date
FROM master.sys.sysdatabases d 
LEFT OUTER JOIN msdb..backupSET b
ON b.database_name = d.name
AND b.type = 'L'
WHERE d.name = @dbName
ORDER BY backup_finish_date DESC
SELECT @diffInMins = DATEDIFF(minute, @lastBackupTime, CURRENT_TIMESTAMP);

-- Get database id and group database id
SELECT @agDbId = group_database_id, @dbId = database_id FROM sys.databases WHERE name = @dbName

-- If there is no group database id, no need for checks
IF (@agDbId IS NOT NULL)
BEGIN
              -- Get last seeding start time and check if backup (VDI client) is actually running
              SELECT TOP 1 @seedingStartTime = start_time, @state = current_state, @agDbId = ag_db_id FROM sys.dm_hadr_automatic_seeding ORDER BY start_time DESC

              IF (@state = 'PENDING' OR @state = 'CHECK_IF_SEEDING_NEEDED' OR @state = 'LIMIT_CONCURRENT_BACKUPS')
                             SET @seedingStarting = 1
              ELSE
                             SET @seedingStarting = 0
              
              SELECT @backupWorkers = COUNT(*) FROM sys.dm_exec_requests WHERE database_id = @dbId AND command = 'VDI_CLIENT_WORKER'

              -- Check if seeding is done by looking at remote replica state and health
              SELECT TOP 1 @db_state = synchronization_state_desc, @db_health = synchronization_health_desc FROM sys.dm_hadr_database_replica_states WHERE database_id = @dbId AND is_local = 0

              IF (@db_state = N'SYNCHRONIZING' AND @db_health = N'HEALTHY')
              SET @seedingDone = 1
              ELSE
              SET @seedingDone = 0
END

-- If X minutes has passed since last log backup, do it, we don't want to wait anymore
IF (@alreadyFailed = 1 or @diffInMins > {set_minutes})
BEGIN
              {do_log_backup}
              SET @alreadyFailed = 1
              CONTINUE;
END

-- If seeding has started and finished take log backups
IF ((@agDbId IS NOT NULL) AND (@seedingStartTime IS NOT NULL) AND (@startTime < @seedingStartTime) AND (@seedingDone = 1))
BEGIN
              {do_log_backup}
              SET @alreadyFailed = 1
              CONTINUE;
END

-- If database is not in ag or
-- If seeding has not started or
-- If seeding is ongoing 
-- Take log backups
IF ((@agDbId IS NULL) OR (@seedingStartTime IS NULL) OR (@startTime > @seedingStartTime) OR (@seedingStarting = 1) or (@backupWorkers > 0))
BEGIN
              {do_log_backup}
              CONTINUE;
END

Estado inconsistente após failover forçado

Após um failover forçado, você pode encontrar um cenário de divisão cerebral em que ambas as réplicas estão na função primária, deixando o link em um estado inconsistente. Isso poderá acontecer se você realizar uma transição para a réplica secundária durante um desastre e, em seguida, a réplica primária ficar online novamente.

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

Conectar-se tanto ao SQL Server quanto à instância gerenciada SQL no SSMS, e, em Pesquisador de Objetos, expanda Availability replicas no nó Availability group no Always On High Availability. Se duas réplicas diferentes estiverem listadas como (Primárias), você estará em um cenário de cérebro dividido.

Como alternativa, você pode executar o seguinte script T-SQL em both SQL Server e Instância Gerenciada de 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 listam PRIMARY na coluna Função do link, você está em um cenário de divisão cerebral.

Para resolver o estado de cérebro dividido, primeiro faça um backup da réplica que era a primária original. Se o primário original foi SQL Server, faça um backup de log tail. Se o primário original é uma Instância Gerenciada de SQL, então faça um backup completo somente cópia. Após a conclusão do backup, configure o grupo de disponibilidade distribuído para a função secundária da réplica que era a primária original e agora será a nova secundária.

Por exemplo, no caso de um verdadeiro desastre, supondo que você tenha forçado um failover de sua carga de trabalho do SQL Server para o Instância Gerenciada de SQL do Azure e pretenda continuar executando sua carga de trabalho no Instância Gerenciada de SQL do Azure, faça um backup de log final no SQL Server e, em seguida, defina o grupo de disponibilidade distribuída para o papel secundário no SQL Server, como no exemplo a seguir:

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

Em seguida, execute um failover manual planejado de Instância Gerenciada de SQL para SQL Server usando o link fornecido, como no 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, atualize o certificado.

Problemas conhecidos após a migração para Instância Gerenciada de SQL

Considere os seguintes problemas conhecidos após a migração para Instância Gerenciada de SQL do Azure:

Restaurar falhas de operação após a migração para Instância Gerenciada de SQL

Se você migrar um banco de dados para uma instância gerenciada do SQL na Azure a partir do SQL Server 2019 e versões posteriores, com a recuperação de banco de dados acelerada habilitada, mas se o repositório de versão persistente (PVS) estiver configurado para algo diferente do grupo de arquivos PRIMARY, poderão ocorrer falhas nas operações de restauração na instância gerenciada de SQL de destino.

Para contornar esse problema, defina o persistent version store (PVS) como PRIMARY no banco de dados de SQL Server de origem antes de migrá-lo para Instância Gerenciada de SQL. Se você já migrou o banco de dados sem definir a PVS para PRIMARY, poderá defini-lo no banco de dados de SQL Server de origem e migrar novamente o banco de dados para Instância Gerenciada de SQL.

Não é possível usar a recuperação acelerada do banco de dados após a migração para Instância Gerenciada de SQL

A partir do SQL Server 2019, se você migrar um banco de dados para Instância Gerenciada de SQL do Azure e o banco de dados de origem tiver recuperação de banco de dados com aceleração desabilitado, você não poderá usar a recuperação acelerada do banco de dados na instância gerenciada de SQL de destino.

Para contornar esse problema, verifique se você abilita recuperação acelerada de banco de dados no banco de dados de SQL Server de origem antes de migrá-lo para Instância Gerenciada de SQL. Se você já migrou o banco de dados sem habilitar a recuperação acelerada do banco de dados, poderá habilitá-lo no banco de dados de SQL Server de origem e, em seguida, migrar novamente o banco de dados para a instância gerenciada de SQL.

SQL Server 2017 e versões anteriores não dão suporte à recuperação acelerada do banco de dados, portanto, esse problema não se aplica aos bancos de dados migrados dessas versões do SQL Server.

Não é possível usar o Service Broker depois de migrar para Instância Gerenciada de SQL

Se você migrar um banco de dados para Instância Gerenciada de SQL do Azure e Service Broker estiver desabilitado no banco de dados de origem, não será possível usar o Service Broker na instância gerenciada de SQL de destino.

Para contornar esse problema, habilite o Service Broker no banco de dados de SQL Server de origem antes de migrá-lo para Instância Gerenciada de SQL. Se você já migrou o banco de dados sem habilitar o Service Broker, poderá habilitá-lo no banco de dados de SQL Server de origem e migrar novamente o banco de dados para Instância Gerenciada de SQL.

Testar a conectividade de rede

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

Teste a rede criando um trabalho temporário do SQL Agent em SQL Server e 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 do trabalho 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 está fazendo o teste deve ter permissões para criar um trabalho (como sysadmin ou pertence à função SQLAgentOperator para msdb) para SQL Server e 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 em 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 do SQL Server proprietário. 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 do pacote precisam ser configuradas corretamente para permitir o tráfego entre SQL Server e Instância Gerenciada de SQL.

SSMS
T-SQL

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

Conecte-se à instância que será a réplica primária no SSMS.
Em 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 Tasks>Instância Gerenciada de SQL do Azure link>Test Connection para abrir o Network Checker assistente:
Selecione Avançar na página Introdução do assistente Verificador de Rede.
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.
Na página Logon, selecione Logon para se conectar à outra instância que será a réplica secundária. Selecione Próximo.
Verifique os detalhes na página Especificar Opções de Rede e forneça um endereço IP, se necessário. Selecione Próximo.
Na página Resumo, examine as ações executadas pelo assistente e selecione Concluir para testar a conexão entre as duas réplicas.
Examine a página Resultados para validar a conectividade existente 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 de SQL Server para Instância Gerenciada de SQL e teste a conexão de Instância Gerenciada de SQL para SQL Server.

Testar a conexão de SQL Server para Instância Gerenciada de SQL

Use SQL Server Agent em SQL Server para executar testes de conectividade de SQL Server a Instância Gerenciada de SQL.

Conecte-se ao Instância Gerenciada de SQL e execute o seguinte script para gerar parâmetros necessários posteriormente:

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.

Conecte-se à sua instância de SQL Server.

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

Substitua os parâmetros @node, @port e @serverName pelos valores obtidos na primeira etapa.
Execute o script e verifique os resultados. Você deve ver resultados como os do seguinte exemplo:
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 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 o firewall do sistema operacional hospedeiro 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 Instância Gerenciada de SQL.

Testar a conexão de Instância Gerenciada de SQL para SQL Server

Para verificar se o Instância Gerenciada de SQL pode acessar o SQL Server, primeiro crie um ponto de extremidade de teste. Em seguida, use o SQL Server Agent para executar um script do PowerShell com o comando tnc pingando SQL Server na porta 5022 da instância gerenciada 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 endpoint SQL Server está recebendo conexões na porta 5022, execute o seguinte comando do PowerShell no sistema operacional host da 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 SQL Server Agent na instância gerenciada de SQL para tentar testar o ponto de extremidade de teste SQL Server na porta 5022 da instância gerenciada de SQL.

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

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

-- 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 seu SQL Server para a sonda de conectividade da instância gerenciada do SQL, exclua o trabalho do NetHelper executando EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper' e recrie o trabalho do NetHelper usando o script anterior.

Em seguida, crie um procedimento armazenado ExecuteNetHelper que ajudará a executar a tarefa e obter os resultados da sonda 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.

Imagem da tela que mostra a saída esperada do serviço SQL Agent NetHelper.

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

O firewall na instância de SQL Server do host permite comunicação de entrada e saída na porta 5022.
Uma regra NSG para a rede virtual que hospeda Instância Gerenciada de SQL permite a comunicação na porta 5022.
Se sua instância de SQL Server estiver em uma VM Azure, uma regra NSG permitirá a comunicação na porta 5022 na rede virtual que hospeda a VM.
SQL Server está em execução.
Existe 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