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

Applies to:Instância Gerenciada de SQL do Azure

Este artigo ensina como preparar seu ambiente para um link Instância Gerenciada para que você possa replicar entre SQL Server instaladas em Windows ou Linux e Instância Gerenciada de SQL do Azure.

Pré-requisitos

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

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

Permissões

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

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

Equilibrar a capacidade de desempenho entre réplicas

Quando você usa a função de link, é importante o alinhamento da capacidade de desempenho entre o SQL Server e o Instância Gerenciada de SQL. Essa correspondência auxilia a evitar problemas de performance caso a réplica secundária não consiga acompanhar a replicação da réplica primária ou após o failover. A capacidade de desempenho inclui núcleos de CPU (ou vCores em Azure), memória e taxa de transferência de E/S.

Preparar sua instância de SQL Server

Para preparar sua instância de SQL Server, você precisa 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.
• Seus backups usam somas de verificação.
• Você habilitou recuperação acelerada de banco de dados se você estiver no SQL Server 2019 ou posterior e planeja usá-la na instância gerenciada de SQL de destino.
• Você habilitou o Service Broker se planeja usá-lo na instância gerenciada de SQL de destino.

Você precisa reiniciar SQL Server para que essas alterações entrem em vigor.

Instalar atualizações de serviço

Verifique se a versão do SQL Server tem a atualização de manutenção apropriada instalada, conforme listado na tabela de suporte version. Se precisar instalar atualizações, reinicie sua instância de SQL Server durante a atualização.

Para verificar sua versão SQL Server, execute o seguinte script 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 SQL Server e 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 garantir que você tenha a 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.

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

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

1. Abra SQL Server Configuration Manager.

2. Selecione SQL Server Services no painel esquerdo.

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

   

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 SQL Server 2016 (13.x) e se a opção Enable Always On Availability Groups estiver desabilitada com a mensagem This computer is not a node in a failover cluster, siga as etapas extras descritas em Prepare SQL Server 2016 prerequisites - Instância Gerenciada de SQL do Azure link. 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: Este flag de rastreamento habilita a compactação do fluxo de dados para grupos de disponibilidade durante a semeadura automática. A compactação aumenta a carga no processador, mas pode reduzir consideravelmente o tempo de transferência durante a distribuição.

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

1. Abra SQL Server Configuration Manager.

2. Selecione SQL Server Services no painel esquerdo.

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

   

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.

Usar backups com somas de verificação

Quando você cria um link, a propagação inicial entre as réplicas primária e secundária é feita fazendo um backup completo do banco de dados na réplica primária, transferindo-o para a réplica secundária e restaurando-o lá. Ao fazer o backup completo, recomendamos que você use a opção WITH CHECKSUM para garantir que o backup seja válido e não tenha nenhuma corrupção. Para obter mais informações, consulte BACKUP (Transact-SQL).

Reiniciar SQL Server e validar a configuração

Depois de garantir que você está em uma versão com suporte do SQL Server, habilitou o recurso grupos de disponibilidade Always On e adicionou os sinalizadores de rastreamento de inicialização, reinicie sua instância SQL Server para aplicar todas essas alterações:

1. Abra SQL Server Configuration Manager.

2. Selecione SQL Server Services no painel esquerdo.

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

   

Após a reinicialização, execute o seguinte script T-SQL no SQL Server para validar a configuração de sua instância de 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 SQL Server deve ser uma das versões com suporte aplicadas com as atualizações de serviço apropriadas, o recurso grupos de disponibilidade Always On deve ser habilitado e você deve ter os sinalizadores de rastreamento -T1800 e -T9567 habilitados. A captura de tela a seguir é um exemplo do resultado esperado para uma instância de SQL Server configurada corretamente:

Habilitar a recuperação acelerada do banco de dados

Para SQL Server 2019 e versões posteriores, habilite a recuperação de banco de dados accelerado e verifique se o repositório de versão persistente (PVS) está definido como PRIMARY. Se a recuperação acelerada do banco de dados não estiver habilitada no banco de dados de SQL Server de origem, você não poderá habilitá-la na instância gerenciada de SQL de destino após a migração do banco de dados. Se o repositório de versão persistente (PVS) não estiver definido PRIMARY, você poderá enfrentar problemas com operações de restauração na instância gerenciada de SQL de destino.

Para SQL Server 2017 e versões anteriores, não há suporte para a recuperação acelerada do banco de dados, portanto, essa etapa não é necessária.

Para configurar a recuperação acelerada do banco de dados corretamente no banco de dados de SQL Server de origem, siga estas etapas:

1. Habilite a recuperação acelerada do banco de dados executando o seguinte script de Transact-SQL no SQL Server:

   ALTER DATABASE [<database name>] SET ACCELERATED_DATABASE_RECOVERY = ON;
   

2. O PVS (repositório de versão persistente) deve ser definido PRIMARY no banco de dados de origem, que é a configuração padrão. Se isso tiver sido alterado anteriormente, você deverá alterá-lo de volta para PRIMARY antes de iniciar a migração.

Habilitar o Service Broker

Service Broker está habilitado por padrão para todas as versões do SQL Server. Se o Service Broker estiver desabilitado e você planeja usá-lo no Instância Gerenciada de SQL, habilite o Service Broker no banco de dados de SQL Server de origem antes de migrar para Instância Gerenciada de SQL. Se o Service Broker não estiver habilitado no banco de dados de SQL Server de origem, você não poderá usá-lo na instância gerenciada de SQL de destino.

Para verificar se o Service Broker está habilitado, execute o seguinte script de Transact-SQL em SQL Server instância:

SELECT name AS [Database Name], is_broker_enabled AS [Service Broker Enabled]
FROM sys.databases
WHERE name = '<database name>';

Se o Service Broker estiver desabilitado, habilite-o executando o seguinte script de Transact-SQL no banco de dados de SQL Server de origem:

USE master;
GO

ALTER DATABASE [<database name>]
    SET ENABLE_BROKER;
GO

Configurar a conectividade de rede

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

SQL Server em Azure Virtual Machines

Implantar SQL Server em Máquinas Virtuais do Azure na mesma rede virtual Azure que hospeda 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, consulte Quickstart: Configurar uma VM Azure para se conectar ao Instância Gerenciada de SQL do Azure.

Se sua instância de 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:

• Azure Virtual Network Peering
• Gateway de VPN de VNet para VNet (Azure portal, PowerShell, CLI do Azure)

Peering é 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 da Azure

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

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

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 de hospedagem 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 hospedam SQL Server e o sistema operacional host precisa permitir:

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

Para abrir portas no Firewall Windows, use o seguinte script do PowerShell no sistema operacional de host Windows da instância de 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 e quaisquer firewalls corporativos e/ou gateways:

Adicionar URLs à lista de permissão

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

O seguinte lista os recursos que devem ser adicionados à sua lista de permissões:

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

Siga as etapas na seção Configure SSMS para nuvens governamentais para acessar a interface Tools no SSMS (SQL Server Management Studio) 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 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.

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.

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

tnc localhost -port 5022

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

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

-- Run on managed instance
EXEC ExecuteNetHelper;

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

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

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

Instância Gerenciada de SQL bancos de dados que são 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 a 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, consulte Set up SQL Server TDE with Azure Key Vault.

Instalar SSMS

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

Após a conclusão da 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 do usuário e valide se a opção Instância Gerenciada de SQL do Azure link aparece no menu.

** Captura de tela que mostra a opção de link do Instância Gerenciada de SQL do Azure no menu de contexto.

Configurar o SSMS para as nuvens governamentais

Se você quiser implantar seu Instância Gerenciada de SQL em uma nuvem governamental, precisará modificar suas configurações de SQL Server Management Studio (SSMS) para usar a nuvem correta. Se você não estiver implantando seu Instância Gerenciada de SQL em uma nuvem do governo, 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 Azure Services e selecione Azure Cloud.
4. Na opção Selecionar uma Nuvem Azure, use a lista suspensa para escolher AzureUSGovernment ou outra nuvem governamental, como AzureChinaCloud:

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

Conteúdo relacionado

Para usar o link:

• Configurar link entre SQL Server e Instância Gerenciada do SQL com SSMS
• Configurar link entre SQL Server e instância gerenciada do SQL com scripts
• Alternar para o link de backup
• Migrar com o Link
• Práticas recomendadas para manter o link

Para saber mais sobre o link:

• Visão geral do link de Instância Gerenciada
• Recuperação de desastres com link de Instância Gerenciada

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

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