Preparar o ambiente para uma migração de vínculo Instância Gerenciada – migração SQL Server no Azure Arc

Applies to:SQL Server

Este artigo ajuda você a preparar seu ambiente para uma migração de link Instância Gerenciada de sua instância de SQL Server habilitada por Azure Arc para Instância Gerenciada de SQL do Azure no portal Azure.

Com o link, você pode migrar seus bancos de dados SQL Server para Instância Gerenciada de SQL do Azure usando a replicação em tempo real com um grupo de disponibilidade distribuído (migração online):

Pré-requisitos

Para migrar seus bancos de dados SQL Server para Instância Gerenciada de SQL do Azure por meio do portal Azure, você precisa dos seguintes pré-requisitos:

• Uma assinatura de Azure ativa. Se você não tiver uma, crie uma conta gratuita.
• Uma instância suportada de SQL Server habilitada pelo Azure Arc com a extensão do Azure para SQL Server versão 1.1.3238.349, que suporta a migração de um banco de dados por vez. Azure Extensão para SQL Server versão 1.1.3348.364 ou posterior é necessária para migrar até 10 bancos de dados ao mesmo tempo. Você pode atualizar sua extensão usando o portal Azure ou o CLI do Azure.

Versões de SQL Server com suporte

As camadas de serviço Geral e Business Critical do Instância Gerenciada de SQL do Azure dão suporte à conexão Instância Gerenciada. A migração com o recurso de link funciona com as edições Enterprise, Developer e Standard de SQL Server no Windows Server.

A tabela a seguir lista as versões mínimas de SQL Server com suporte para o link:

A migração reversa é suportada apenas para o SQL Server 2025 e SQL Server 2022 a partir das instâncias gerenciadas do SQL com a política correspondente de update. Você pode reverter manualmente uma migração por meio de outras ferramentas, como backup e restauração nativos, ou configurar manualmente um link no SSMS.

Permissions

Esta seção descreve as permissões necessárias para migrar sua instância de SQL Server para Instância Gerenciada de SQL por meio do portal Azure.

Na instância de SQL Server de origem, você precisa das seguintes permissões:

• Se você habilitar privilégios mínimos, as permissões necessárias, como sysadmin , serão concedidas conforme necessário durante o processo de migração de banco de dados.
• Se você não puder usar privilégios mínimos, a pessoa que está executando a migração precisará sysadmin permissões na instância de SQL Server de origem. Além disso, se você precisar cancelar uma migração, também atribua manualmente permissões de sysadmin à NT AUTHORITY\SYSTEM conta.

Para migrar com o link Instância Gerenciada, você precisa de uma das seguintes permissões no destino Instância Gerenciada de SQL:

• função Instância Gerenciada de SQL Colaborador
• Função de Colaborador ou Proprietário no nível da assinatura

Para obter permissões mínimas, consulte permissões personalizadas.

Equilibrar a capacidade de desempenho entre réplicas

Quando você usa o recurso de link, é importante equilibrar a 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, conclua as seguintes etapas:

• Valide se você está na versão com suporte.
• Crie uma chave mestra de banco de dados no master banco de dados.
• Habilite o recurso grupos de disponibilidade.
• Adicione os sinalizadores de rastreamento adequados na inicialização.
• Restart SQL Server e valide a configuração.
• Defina o banco de dados como um modelo de recuperação completa.
• Importar os certificados de autoridade de certificação confiáveis do Azure para o SQL Server.
• Habilitar recuperação acelerada de banco de dados se estiver no SQL Server 2019 ou posterior e planeja usá-la na instância gerenciada de SQL de destino.
• Habilite o Service Broker se você planeja usá-lo na instância gerenciada de SQL de destino.

Você precisa restart 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%';

Preparar instâncias do SQL Server 2016

Para o SQL Server 2016 (13.x), você deve concluir as etapas extras documentadas em Prepare os pré-requisitos do SQL Server 2016 para o link. Essas etapas adicionais não são necessárias para SQL Server 2017 (14.x) e versões posteriores compatíveis com o link.

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 Grupos de Disponibilidade AlwaysOn e selecione OK.

   

   • Se você estiver usando SQL Server 2016 (13.x) e a opção Enable Always On Availability Groups estiver desabilitada com a mensagem exibida , siga as etapas descritas em 'Pré-requisitos para preparar o SQL Server 2016 para o link' . Depois de concluir essas etapas, retorne a esta etapa e tente novamente.

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, habilite os seguintes sinalizadores de rastreamento na inicialização:

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

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.

Reiniciar SQL Server e validar a configuração

Se você não precisar atualizar a versão do SQL Server, habilitar o recurso do grupo de disponibilidade ou adicionar sinalizadores de rastreamento de inicialização, ignore esta seção.

Depois de garantir que você está em uma versão com suporte do SQL Server, habilite o recurso grupos de disponibilidade Always On e adicione os sinalizadores de rastreamento de inicialização, reinicie sua instância de 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 com as atualizações de serviço apropriadas aplicadas. O recurso grupos de disponibilidade Always On deve ser habilitado, e você deve habilitar os sinalizadores de rastreamento -T1800 e -T9567. A captura de tela a seguir é um exemplo do resultado esperado para uma instância de SQL Server configurada corretamente:

Definir o banco de dados como um modelo de recuperação completa

Os bancos de dados migrados por meio do link devem estar no modelo de recuperação completa e ter pelo menos um backup.

Execute o código a seguir em SQL Server para todos os bancos de dados que você deseja migrar. Substitua <DatabaseName> pelo nome atual do banco de dados.

-- Run on SQL Server
-- Set full recovery model for all databases you want to migrate.
ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL
GO

-- Execute backup for all databases you want to migrate.
BACKUP DATABASE [<DatabaseName>] TO DISK = N'<DiskPath>'
GO

Importar chaves de autoridade de certificação raiz Azure confiáveis para SQL Server

Para confiar nos certificados de chave pública de uma instância gerenciada do SQL emitidos pela Azure, você precisa importar certificados de autoridade de certificação raiz confiável da Azure para o SQL Server.

Você pode baixar as chaves de CA raiz dos detalhes de Autoridade de Certificação do Azure. No mínimo, baixe os certificados DigiCert Global Root G2 e Microsoft RSA Root Certificate Authority 2017 e importe-os para sua instância de SQL Server.

Salve os certificados locais na instância de SQL Server, como o caminho C:\certs\<name of certificate>.crt de exemplo e importe os certificados desse caminho usando o script Transact-SQL a seguir. Substitua <name of certificate> pelo nome do certificado real: DigiCert Global Root G2 e Microsoft RSA Root Certificate Authority 2017, que são os nomes necessários para esses dois certificados.

-- Run on SQL Server-- Import <name of certificate> root-authority certificate (trusted by Azure), if not already present
CREATE CERTIFICATE [DigiCertPKI] FROM FILE = 'C:\certs\DigiCertGlobalRootG2.crt'
DECLARE @CERTID int
SELECT @CERTID = CERT_ID('DigiCertPKI')
EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net';
GO
CREATE CERTIFICATE [MicrosoftPKI] FROM FILE = 'C:\certs\Microsoft RSA Root Certificate Authority 2017.crt'
DECLARE @CERTID int
SELECT @CERTID = CERT_ID('MicrosoftPKI')
EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net';
GO

Por fim, verifique todos os certificados criados usando a seguinte DMV (exibição de gerenciamento dinâmico):

-- Run on SQL Server
USE master
SELECT * FROM sys.certificates

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 fora da Azure

Se você hospedar sua instância de SQL Server fora do Azure, poderá estabelecer 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

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.

Você tem 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.

Portas de rede entre os ambientes

Independentemente do mecanismo de conectividade, você deve atender aos seguintes requisitos para que o tráfego de rede flua entre os ambientes:

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

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

A porta 5022 não pode ser alterada no Instância Gerenciada de SQL.

Todos os firewalls na rede que hospeda SQL Server e o sistema operacional host deve 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 porta 5022 pode ser personalizada no lado SQL Server, mas o intervalo de portas 11000-11999 deve ser aberto como está.

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 a instância SQL Server e quaisquer firewalls e gateways corporativos:

Adicionar URLs à lista de permissão

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

Adicione os seguintes recursos à 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 de 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 URLs específicas para os recursos em sua nuvem que você precisa adicionar à sua lista de permissões.

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 criptografá-lo 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.

Testar a conectividade de rede

Antes de iniciar a migração, teste a conectividade de rede entre sua instância de SQL Server e Instância Gerenciada de SQL. Você pode testar a conectividade diretamente do portal Azure como parte do processo de migração. No entanto, você também pode testar a conectividade manualmente usando Transact-SQL e o SQL Server Agent. Para obter mais informações, consulte Testar a conectividade de rede.

Para testar a conectividade por meio do portal Azure, siga estas etapas:

1. Selecione Migrate data no painel Database migration para o recurso de instância SQL Server.

2. Selecione a opção MI link.

3. Selecione os bancos de dados de destino que você deseja migrar e, em seguida , use Avançar: Configurações para ir para a próxima guia.

4. Na guia Configurações , forneça o nome do link e do grupo de disponibilidade de origem. Em seguida, use Test connection para validar a conectividade de rede entre SQL Server e Instância Gerenciada de SQL:

   

Considere os seguintes pontos:

• 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 de pacote precisam ser configuradas corretamente para permitir o tráfego entre SQL Server e Instância Gerenciada de SQL.

Limitações

Considere as seguintes limitações:

• As limitações do link Instância Gerenciada se aplicam às migrações por meio do portal Azure.
• Azure Extension for SQL Server versão 1.1.3238.349 e anterior só dá suporte à migração de um banco de dados por vez por meio do link. Para migrar vários bancos de dados ao mesmo tempo, atualize para Azure Extension para SQL Server versão 1.1.3348.364 ou posterior.
• Cancelar uma migração requer permissões sysadmin na instância de SQL Server de origem. Se sua instância de SQL Server não estiver usando privilégios mínimos, atribua manualmente permissões sysadmin à conta NT AUTHORITY\SYSTEM.
• A configuração de um link por meio do portal Azure para fins de migração não é compatível com links criados manualmente, seja por meio de SQL Server Management Studio (SSMS) ou Transact-SQL (T-SQL). Examine o problema conhecido para saber mais.
• O monitoramento da migração por meio do portal Azure está disponível apenas para as instâncias SQL Server que atendem aos requisitos de monitoramento de licenciamento.

Solução de problemas comuns

Para solucionar problemas comuns ao migrar para Instância Gerenciada de SQL do Azure, consulte Solucionar problemas de migração.

Conteúdo relacionado

• Práticas recomendadas para links do Instância Gerenciada
• Visão Geral da Migração do SQL Server no Azure Arc
• Preparar o ambiente para a migração LRS – migração do SQL Server no Azure Arc
• SQL Server habilitado pelo Azure Arc
• Enviar comentários sobre a experiência de migração diretamente para o grupo de produtos
• Migração para o Instância Gerenciada de SQL do Azure – migração do SQL Server no Azure Arc