Prepare o seu ambiente para um link - Azure SQL Managed Instance

Aplica-se a: Azure SQL Managed Instance

Este artigo ensina-te a preparar o teu ambiente para um link Managed Instance para que possas replicar entre SQL Server instalado no Windows ou Linux e Azure SQL Managed Instance.

Pré-requisitos

Para criar uma ligação entre o SQL Server e o Azure SQL Managed Instance, são necessários os seguintes pré-requisitos:

• Uma subscrição ativa do Azure. Se tu não tiveres uma, cria uma conta gratuita.
• Uma versão Suportada de SQL Server com a atualização de serviço necessária.
• Azure SQL Managed Instance com uma política de atualização apropriada. Comece agora se não tiver um.
• Um servidor que você pretende que seja o primário inicial. Essa escolha determina de onde você deve criar o link.
  • Configurar um link de um SQL Managed Instance primário para um secundário SQL Server 2025 só é suportado em instâncias SQL Managed configuradas com a política de atualização SQL Server 2025.
  • Configurar um link de uma Instância Gerida SQL primária para um secundário SQL Server 2022 apenas é suportado a partir de SQL Server 2022 CU10 e com Instâncias Geridas SQL configuradas com a política de atualização do SQL Server 2022.

Permissões

Para SQL Server, deves ter permissões sysadmin.

Para Azure SQL Managed Instance, deve ser membro do SQL Managed Instance Contributor, ou ter as seguintes permissões para um papel personalizado:

Combine a capacidade de desempenho entre réplicas

Quando utiliza a funcionalidade de ligação, é importante ajustar a capacidade de desempenho entre o SQL Server e o SQL Managed Instance. Esta correspondência ajuda a evitar problemas de desempenho se a réplica secundária não conseguir acompanhar a replicação a partir da réplica primária, ou após o failover. A capacidade de desempenho inclui núcleos de CPU (ou vCores no Azure), memória e largura de banda de I/O.

Prepare a sua instância de SQL Server

Para preparar a sua instância do SQL Server, precisa de validar que:

• Estás na versão mínima suportada.
• Criaste uma chave mestra da base de dados na master base de dados.
• Ativaste a funcionalidade de grupos de disponibilidade.
• Adicionaste as bandeiras de rastreamento corretas no arranque.
• Os seus backups usam somas de verificação.
• Ativaste recuperação acelerada de base de dados se estiveres em SQL Server 2019 ou posterior, e planeia utilizá-lo na instância gerida do SQL de destino.
• Ativaste o Service Broker se planeias usá-lo na instância SQL gerida de destino.

É preciso reiniciar o SQL Server para que estas alterações tenham efeito.

Instalar atualizações de serviço

Certifique-se de que a sua versão SQL Server tem a atualização de manutenção adequada instalada, conforme indicado na tabela de suporte version. Se precisar de instalar alguma atualização, deve reiniciar a sua instância do SQL Server durante a atualização.

Para verificar a sua versão do 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

A ligação utiliza certificados para encriptar autenticação e comunicação entre o SQL Server e o SQL Managed Instance. A chave mestra da base de dados protege os certificados usados pela ligação. Se já tiveres uma chave mestra de base de dados, podes saltar este passo.

Crie a chave mestra na base de dados master. Insira sua senha no lugar de <strong_password> no script a seguir e mantenha-a em um local 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 tem a chave mestra da base de dados, utilize 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 grupos de disponibilidade

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

Para confirmar que a funcionalidade de grupos de disponibilidade está ativada, 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. Abrir Gestor de Configuração do SQL Server.

2. Selecione SQL Server Serviços no painel esquerdo.

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

   

4. Vá para a aba Always On Availability Groups.

5. Marque a caixa de seleção Ativar grupos de disponibilidade Always On e selecione OK.

   

   • Se estiver a usar SQL Server 2016 (13.x), e se a opção Ativar Grupos de Disponibilidade Sempre Ativados estiver desativada com a mensagem This computer is not a node in a failover cluster, siga os passos extra descritos em Preparar SQL Server pré-requisitos de 2016 - Azure SQL Managed Instance 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.

Ativar sinalizadores de rastreamento de inicialização

Para otimizar o desempenho do seu link, recomendamos ativar 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ária e secundária em um grupo de disponibilidade são hospedados em discos com tamanhos de setor diferentes, como 512 bytes e 4 KB. Se as réplicas primária e secundária 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 sinalizador de rastreamento permite a compactação do fluxo de dados para grupos de disponibilidade durante a propagação automática. A compressão aumenta a carga no processador, mas pode reduzir significativamente o tempo de transferência durante o seeding.

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

1. Abrir o Gestor de Configuração do SQL Server.

2. Selecione SQL Server Serviços no painel esquerdo.

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

   

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

   

5. Selecione OK para fechar a janela Propriedades.

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

Utilize cópias de segurança com checksums

Quando crias uma ligação, a seed inicial entre as réplicas primária e secundária é feita fazendo uma cópia de segurança completa da base de dados na réplica primária, transferindo-a para a réplica secundária e restaurando-a aí. Quando fizer o backup completo, recomendamos que use a WITH CHECKSUM opção para garantir que o backup é válido e não tem qualquer corrupção. Para mais informações, consulte BACKUP (Transact-SQL).

Reinicie o SQL Server e valide a configuração

Depois de garantir que está numa versão suportada do SQL Server, ativou a funcionalidade de grupos de disponibilidade Always On e adicionou as suas flags de rastreio de inicialização, reinicie a sua instância do SQL Server para aplicar todas estas alterações.

1. Abrir Gestor de Configuração do SQL Server.

2. Selecione SQL Server Serviços no painel esquerdo.

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

   

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

-- Run on SQL Server
-- Shows the version and CU of SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';
GO
-- Shows if the Always On availability groups feature is enabled
SELECT SERVERPROPERTY ('IsHadrEnabled') as 'Is Always On enabled? (1 true, 0 false)';
GO
-- Lists all trace flags enabled on SQL Server
DBCC TRACESTATUS;

A sua versão do SQL Server deve ser uma das suportadas, aplicadas com as atualizações de serviço apropriadas. A funcionalidade de grupos de disponibilidade Always On deve estar ativada, e deve ter os flags de rastreamento -T1800 e -T9567 ativados. A captura de ecrã seguinte é um exemplo do resultado esperado para uma instância do SQL Server devidamente configurada:

Permitir a recuperação acelerada da base de dados

Para SQL Server versões de 2019 e posteriores, ative recuperação acelerada da base de dados e certifique-se de que o armazenamento de versões persistentes (PVS) está definido para PRIMARY. Se a recuperação acelerada da base de dados não estiver ativada na base de dados do SQL Server de origem, não pode ser ativada na instância gerida SQL de destino depois da migração da base de dados. Se o armazenamento de versões persistentes (PVS) não estiver definido para PRIMARY, pode ter problemas com operações de restauro na instância SQL gerida de destino.

Para o SQL Server 2017 e versões anteriores, a recuperação acelerada da base de dados não é suportada, por isso este passo não é necessário.

Para configurar corretamente a recuperação acelerada da base de dados no SQL Server de origem, siga estes passos:

1. Permita a recuperação acelerada da base de dados executando o seguinte script Transact-SQL no SQL Server:

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

2. O armazenamento persistente de versões (PVS) deve ser definido como PRIMARY na base de dados de origem, que é a configuração predefinida. Se isto foi alterado anteriormente, deve voltar a ser PRIMARY antes de iniciar a migração.

Ativar o Corretor de Serviços

Service Broker está ativado por defeito para todas as versões do SQL Server. Se o Service Broker estava desativado e planeias usá-lo no SQL Managed Instance, ativa o Service Broker na base de dados do SQL Server de origem antes de migrar para o SQL Managed Instance. Se o Service Broker não estiver ativado na base de dados SQL Server de origem, não pode usá-lo na instância SQL gerida de destino.

Para verificar se o Service Broker está ativado, execute o seguinte script Transact-SQL na instância do SQL Server:

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

Se o Service Broker estiver desativado, ative-o executando o seguinte script Transact-SQL na base de dados SQL Server de origem:

USE master;
GO

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

Configurar a conectividade de rede

Para o link funcionar, é necessário ter conectividade de rede entre o SQL Server e o SQL Managed Instance. A opção de rede que escolhes depende de a tua instância do SQL Server estar ou não numa rede Azure.

Servidor SQL em Máquinas Virtuais do Azure

Implementar o SQL Server nas Máquinas Virtuais do Azure na mesma rede virtual Azure que aloja o SQL Managed Instance é o método mais simples, porque a conectividade de rede existe automaticamente entre as duas instâncias. Para mais informações, consulte Quickstart: Configure uma VM Azure para se ligar ao Azure SQL Managed Instance.

Se a sua instância SQL Server nas Máquinas Virtuais do Azure estiver numa rede virtual diferente da sua instância gerida por SQL, precisa de ligar as duas redes virtuais. As redes virtuais não precisam de estar na mesma subscrição para que este cenário funcione.

Existem duas opções para ligar redes virtuais:

• Azure pareamento de rede virtual
• Gateway VPN de VNet para VNet (portal Azure, PowerShell, CLI do Azure)

O peering é preferível porque utiliza a rede backbone da Microsoft. Assim, do ponto de vista da conectividade, não há diferença notória na latência entre máquinas virtuais numa rede virtual peered e na mesma rede virtual. O peering de redes virtuais é permitido entre redes na mesma região. O emparelhamento de rede virtual global é suportado para instâncias hospedadas em sub-redes que foram criadas após 22 de setembro de 2020. Para obter mais informações, consulte Perguntas frequentes (FAQ).

SQL Server fora do Azure

Se a sua instância de SQL Server estiver alojada fora do Azure, estabeleça uma ligação VPN entre o SQL Server e a SQL Managed Instance utilizando uma destas opções:

• Conexão VPN site a site
• A ligação Azure ExpressRoute

Portas de rede entre os ambientes

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

As regras do Network Security Group (NSG) na sub-rede que aloja o SQL Managed Instance precisam de permitir:

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

Todos os firewalls na rede que hospeda o SQL Server, e no sistema operativo anfitrião, precisam de 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 IP de destino da sub-rede MI (exemplo 10.0.0.0/24)

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

Para abrir portas no Windows Firewall, utilize o seguinte script PowerShell no sistema operativo anfitrião Windows da instância do SQL Server:

New-NetFirewallRule -DisplayName "Allow TCP port 5022 inbound" -Direction inbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP
New-NetFirewallRule -DisplayName "Allow TCP port 5022 outbound" -Direction outbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP

O diagrama seguinte mostra um exemplo de ambiente de rede local, indicando que todos os firewalls no ambiente precisam de ter portas abertas, incluindo o firewall do sistema operativo que aloja o SQL Server, e quaisquer firewalls corporativos e/ou gateways:

Adicionar URLs à lista de permitir

Dependendo das suas definições de segurança de rede, pode ser necessário adicionar URLs à sua lista de autorizações para o SQL Managed Instance FQDN e alguns dos endpoints de Gestão de Recursos usados pelo Azure.

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

• O nome de domínio totalmente qualificado (FQDN) da sua Instância Gerida de SQL. Por exemplo: managedinstance.a1b2c3d4e5f6.database.windows.net.
• Microsoft Entra Authority
• Microsoft Entra Endpoint Resource ID
• Ponto Final do Gestor de Recursos
• Endereço de Serviço

Siga os passos na secção Configure SSMS para clouds governamentais para aceder à interface Tools no SQL Server Management Studio (SSMS) e identificar as URLs específicas dos recursos dentro da sua nuvem que precisa de adicionar à sua lista de autorizações.

Testar a conectividade de rede

A conectividade bidirecional da rede entre o SQL Server e o SQL Managed Instance é necessária para que a ligação funcione. Depois de abrir portas do lado do SQL Server e configurar uma regra NSG no lado da SQL Managed Instance, teste a conectividade utilizando o SQL Server Management Studio (SSMS) ou o Transact-SQL.

Teste a rede criando um trabalho SQL Agent temporário tanto no SQL Server como no SQL Managed Instance para verificar a ligação entre as duas instâncias. Quando se utiliza a Ferramenta Verificadora 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.

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

• O utilizador que realiza o teste deve ter permissões para criar uma tarefa (seja como sysadmin ou pertencer à função SQLAgentOperator para msdb) tanto para SQL Server como para SQL Managed Instance.
• O serviço SQL Server Agent deve estar a correr em SQL Server. Como o Agente está ativado por defeito na SQL Managed Instance, não é necessária qualquer ação adicional.

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 da 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 o SQL Server e a SQL Managed Instance.

-- 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 estiver a ligar uma base de dados SQL Server protegida por Encriptação de Dados Transparente (TDE) a uma instância gerida SQL, deve migrar o certificado de encriptação correspondente da instância SQL Server on-premises ou Azure VM para a instância gerida SQL antes de usar a ligação. Para passos detalhados, consulte Migrar um certificado de uma base de dados protegida por TDE para Azure SQL Managed Instance.

Bases de dados SQL Managed Instance encriptadas com chaves TDE geridas por serviços não podem ser ligadas ao SQL Server. Só pode ligar uma base de dados encriptada ao SQL Server se esta foi encriptada com uma chave gerida pelo cliente e o servidor de destino tiver acesso à mesma chave usada para encriptar a base de dados. Para mais informações, consulte Configurar SQL Server TDE com Azure Key Vault.

Instalar o SSMS

O SQL Server Management Studio (SSMS) é a forma mais fácil de usar o link Managed Instance. Instale a versão mais recente do SQL Server Management Studio (SSMS) na sua máquina cliente.

Depois de terminar a instalação, abra o SSMS e ligue-se à sua instância SQL Server suportada. Clique com o botão direito numa base de dados de utilizadores e valide que a opção Azure SQL Managed Instance link aparece no menu.

Configurar o SSMS para nuvens governamentais

Se quiser implementar a sua SQL Managed Instance numa cloud governamental, precisa de modificar as definições do SQL Server Management Studio (SSMS) para usar a cloud correta. Se não está a implementar a sua SQL Managed Instance numa cloud governamental, evite este passo.

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

1. Abra o SSMS.
2. No menu, selecione Ferramentas e, em seguida, escolha Opções .
3. Expanda Azure Serviços e selecione Azure Cloud.
4. Em Selecione uma Azure Cloud, use a lista suspensa para escolher AzureUSGovernment, ou outra cloud governamental, como AzureChinaCloud:

Se quiser voltar à nuvem pública, escolha AzureCloud na lista suspensa.

Conteúdo relacionado

Para usar o link:

• Configurar a ligação entre SQL Server e a Instância Gerida do SQL com SSMS
• Configurar a ligação entre SQL Server e a instância gerida de SQL com scripts
• Falha no link
• Migrar com o link
• Práticas recomendadas para manter o link

Para saber mais sobre o link:

• Visão geral de link da Instância Gerida
• Recuperação de desastres com Managed Instance link

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

• Replicação transacional com SQL Managed Instance
• Serviço de Reprodução de Log (LRS)