Partilhar via


Preparar o ambiente para migração do LRS - Migração do SQL Server no Azure Arc

Aplica-se a: SQL Server

Este artigo ajuda-o a preparar o seu ambiente para uma migração Log Replay Service (LRS) da sua instância de SQL Server habilitada por Azure Arc para Azure SQL Managed Instance no portal Azure.

Com o LRS, pode migrar as suas bases de dados do SQL Server para o Azure SQL Managed Instance usando backup e restauro através do envio de log (migração online):

Diagrama a mostrar a migração do Log Replay Service.

Observação

Pode fornecer feedback sobre a sua experiência de migração diretamente ao grupo de produtos.

Pré-requisitos

Para migrar as suas bases de dados SQL Server para o Azure SQL Managed Instance através do portal Azure, precisa dos seguintes pré-requisitos:

Versões suportadas para SQL Server

A migração com LRS funciona com todas as edições do SQL Server no Windows. Embora a migração para os níveis de serviço de Propósito Geral e Crítico de Negócio do SQL Managed Instance seja suportada, migrar diretamente para o nível de serviço Crítico de Negócio tem algumas limitações importantes a considerar.

A tabela seguinte lista as versões mínimas suportadas do SQL Server para LRS:

Versão do SQL Server Atualização mínima obrigatória de manutenção
SQL Server 2025 (17.x) SQL Server 2025 RTM (17.0.1000.7)
SQL Server 2022 (16.x) SQL Server 2022 RTM (16.0.1000.6)
SQL Server 2019 (15.x) SQL Server 2019 RTM (15.0.2000.5)
SQL Server 2017 (14.x) SQL Server 2017 RTM (14.0.1000.169)
SQL Server 2016 (13.x) SQL Server 2016 RTM (13.0.1400.361)
SQL Server 2014 (12.x) SQL Server 2014 RTM (12.0.2000.8)
SQL Server 2012 (11.x) SQL Server 2012 RTM (11.0.2100.60)

A migração reversa é suportada apenas até SQL Server 2025 e SQL Server 2022 a partir de instâncias geridas SQL com a correspondente política atualização. Pode reverter manualmente uma migração através de outras ferramentas, como backup e restauro nativos, ou configurar manualmente um link no SSMS.

Observação

Para instâncias SQL Server não suportadas, como antes de SQL Server de 2012, ou no Linux, considere usar o Log Replay Service diretamente para migrar para Azure SQL Managed Instance.

Permissions

Esta secção descreve as permissões necessárias para migrar a sua instância do SQL Server para a SQL Managed Instance através do portal Azure.

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

  • Se ativar o privilégio mínimo, as permissões necessárias, como administrador de sistemas , são concedidas conforme necessário durante o processo de migração da base de dados.
  • Se não conseguires usar o privilégio mínimo, precisas de permissões sysadmin na instância SQL Server fonte.

Para migrar com LRS, precisa de uma das seguintes permissões no SQL Managed Instance target:

Criar uma conta de armazenamento

Usas uma conta Armazenamento de Blobs do Azure como armazenamento intermédio para ficheiros de backup entre a tua instância SQL Server e a implementação da SQL Managed Instance. A conta de armazenamento tem de estar na mesma subscrição do Azure que o seu SQL Managed Instance target.

Para criar uma nova conta de armazenamento e um contêiner de blob dentro da conta de armazenamento:

  1. Crie uma conta de armazenamento:
    1. Procure por Storage accounts no portal Azure e selecione Create.
    2. No separador Básicos , selecione a sua subscrição e grupo de recursos. A região deve ser a mesma que o seu SQL Managed Instance target.
    3. Deixe o tipo de armazenamento preferencial em branco.
    4. Utilize as definições padrão para as abas restantes e selecione Rever + criar.
    5. Depois que a validação for aprovada, selecione Criar.
  2. Crie um contêiner de blob dentro da conta de armazenamento.
    1. Vai à tua nova conta de armazenamento no portal Azure.
    2. Em Armazenamento de dados, selecione Contêineres.
    3. Use Adicionar recipiente para abrir o novo painel de contentores .
    4. Introduza um nome para o seu contentor, deixe as opções nos valores predefinidos e selecione Criar para criar o seu contentor.
  3. (Opcional) Se o seu Armazenamento do Azure estiver atrás de um firewall, o seu armazenamento de Azure Blob requer configuração adicional depois de a sua instância gerida SQL ser provisionada.

Concede permissões a Armazenamento de Blobs do Azure

A migração do SQL Server no Azure Arc com LRS utiliza uma identidade gerida para autenticar no Armazenamento de Blobs do Azure.

Precisa de conceder as seguintes permissões:

Conceder acesso ao utilizador à conta de armazenamento

Para aceder às cópias de segurança da base de dados durante o processo de migração, atribua ao utilizador que inicia sessão no portal do Azure e realiza a migração ao papel Storage Blob Data Reader para a conta de armazenamento que contém as cópias de segurança.

Para atribuir o papel, siga estes passos:

  1. No portal Azure, vai ao grupo de recursos que contém a tua conta de armazenamento.

  2. Selecione Controle de acesso (IAM) no menu de recursos.

  3. Use + Adicionar para selecionar Adicionar atribuição de função e abra o painel Adicionar atribuição de funções .

  4. Procure e selecione a função Leitor de Dados de Blob de Armazenamento. Em seguida, selecione Avançar.

    Captura de ecrã que mostra a função Storage Blob Data Reader na página IAM para a conta de armazenamento no portal Azure.

  5. Use + Selecionar membros para abrir o painel Selecionar membros e procure a conta de utilizador da pessoa que realiza a migração. Se várias pessoas estiverem a migrar dados, conceda este acesso a todos esses utilizadores. Selecione a conta de utilizador e depois use Select para guardar a sua seleção. Verifique a opção de atribuir acesso a Utilizador, grupo ou principal de serviço.

  6. Selecione Rever + atribuir para ir ao separador Rever + atribuir , e depois selecione Rever + atribuir novamente para completar a atribuição de funções.

Conceder acesso aos utilizadores ao grupo de recursos

Para aceder às cópias de segurança da base de dados durante o processo de migração, o utilizador que inicia sessão no portal Azure e realiza a migração precisa de ser atribuído ao papel Reader no grupo de recursos que contém a conta de armazenamento.

Para atribuir o papel, siga estes passos:

  1. No portal Azure, vai ao grupo de recursos que contém a tua conta de armazenamento.

  2. Selecione Controle de acesso (IAM) no menu de recursos.

  3. Use + Adicionar para selecionar Adicionar atribuição de função e abra o painel Adicionar atribuição de funções .

  4. Procure e selecione a função Leitor . Em seguida, selecione Avançar.

    Captura de ecrã da localização da função de Leitor na página IAM para o grupo de recursos no portal Azure.

  5. Use + Selecionar membros para abrir o painel Selecionar membros e procure a conta de utilizador da pessoa que realiza a migração. Se várias pessoas estiverem a migrar dados, conceda este acesso a todos esses utilizadores. Selecione a conta de utilizador e depois use Select para guardar a sua seleção. Verifique a opção de atribuir acesso a Utilizador, grupo ou principal de serviço e depois use Próximo para continuar.

  6. No separador Tipo de Atribuição , defina o tipo de Atribuição para Ativo e a duração da Atribuição para Permanente:

    Captura de ecrã de definir o tipo de Atribuição para Ativo e a duração da Atribuição para Permanente no separador de tipo de Atribuição no portal Azure.

  7. Selecione Rever + atribuir para ir ao separador Rever + atribuir , e depois selecione Rever + atribuir novamente para completar a atribuição de funções.

Conceder acesso de identidade gerida à conta de armazenamento

Depois de a sua instância gerida SQL ser provisionada, precisa de atribuir à identidade gerida da sua instância gerida SQL o papel Storage Blob Data Reader para que possa aceder à sua conta Armazenamento de Blobs do Azure durante o processo de migração.

Primeiro, deve determinar que tipo de identidade gerida a sua instância SQL gerida utiliza. Para fazer isso, execute as seguintes etapas:

  1. Aceda à sua instância gerida SQL no Portal do Azure.
  2. Em Segurança, selecione Identidade.
    1. Se em Identidade gerida atribuída pelo Utilizador vir Nenhuma identidade gerida atribuída pelo utilizador encontrada, a sua instância gerida SQL usa a identidade gerida atribuída pelo sistema por defeito.
    2. Se vires uma entrada no campo Identidade Primária , então a tua instância gerida SQL usa uma identidade gerida personalizada atribuída pelo utilizador. Anote esta identidade para usar na etapa em que seleciona esta identidade gerida ao conceder acesso de Storage Blob Data Reader à conta de armazenamento.

Para conceder acesso à conta de armazenamento, siga estes passos:

  1. Vai à conta Armazenamento de Blobs do Azure no portal Azure que pretendes usar para a migração.
  2. Selecione Controle de acesso (IAM) no menu de recursos.
  3. Use + Adicionar para selecionar Adicionar atribuição de função e abra o painel Adicionar atribuição de funções .
  4. Procure e selecione a função Leitor de Dados de Blob de Armazenamento. Em seguida, selecione Avançar.
  5. No Atribuir acesso a, marque a opção Identidade Gerida.
  6. Use membros selecionados para abrir o painel de membros selecionados .
  7. Se a sua instância gerida SQL usar a identidade gerida atribuída por padrão ao sistema:
    1. Em Identidade Gerida, selecione Instância Gerida SQL.
    2. Pesquise e selecione o nome da sua instância gerida por SQL.
    3. Use Select para guardar a sua seleção.
  8. Se a sua instância gerida SQL usar uma identidade gerida atribuída pelo utilizador:
    1. Em Identidade Gerida, selecione Identidade gerida atribuída pelo Utilizador.
    2. Procura o nome de identidade primário que mencionaste anteriormente na página de Identidade da tua instância gerida em SQL e seleciona-o.
    3. Use Select para guardar a sua seleção.
  9. Selecione Rever + atribuir para ir ao separador Rever + atribuir , e depois selecione Rever + atribuir novamente para completar a atribuição de funções.

Depois de carregares pelo menos um backup completo para esta conta de armazenamento, podes executar o seguinte comando na tua instância gerida SQL para verificar se ela pode aceder à tua conta Armazenamento de Blobs do Azure:

RESTORE HEADERONLY
    FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak';

Configurar base de dados SQL Server de origem

Ative a recuperação acelerada da base de dados e o Service Broker na sua instância de SQL Server de origem se planeia usar estas funcionalidades na SQL Managed Instance de destino após a migração, pois estas funcionalidades não podem ser ativadas após a migração se não estiverem já ativadas na instância SQL Server de origem.

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

Faça upload de backups para a sua conta Armazenamento de Blobs

Quando o seu contentor de blob estiver pronto e confirmar que a sua instância gerida por SQL pode aceder ao contentor, pode começar a carregar os seus backups para a sua conta Armazenamento de Blobs do Azure. Quando todas as suas cópias de segurança forem carregadas para a sua conta de armazenamento, está pronto para avançar com a migração.

Para carregar os seus backups no Azure:

Considere as seguintes práticas recomendadas:

  • Efetue backups com as opções COMPRESSION e CHECKSUM para reduzir o tamanho dos ficheiros de backup e evitar a migração de uma base de dados corrompida.
  • Faça backups em lotes mais pequenos.
  • Utilize linhas de upload paralelas.
  • Faça o último ficheiro de backup o mais pequeno possível.
  • Para migrar múltiplas bases de dados usando o mesmo contentor do Armazenamento de Blobs do Azure, coloque todos os ficheiros de backup de uma base de dados individual numa pasta separada dentro do contentor. Use a estrutura de arquivo simples para cada pasta de banco de dados. Não há suporte para aninhamento de pastas dentro de pastas de banco de dados.

Fazer backups numa instância do SQL Server

Os passos desta secção mostram-lhe como fazer backup localmente, mas também é possível fazer backup diretamente para URL.

Defina os bancos de dados que você deseja migrar para o modelo de recuperação completa para permitir backups de log.

-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master;

ALTER DATABASE SampleDB
SET RECOVERY FULL;
GO

Se ainda não tiver backups existentes, para fazer manualmente backups completos, diferenciais e de registo da sua base de dados para armazenamento local, use os seguintes scripts T-SQL de exemplo. CHECKSUM não é necessário, mas é recomendado para evitar a migração de um banco de dados corrompido e para tempos de restauração mais rápidos.

O exemplo a seguir faz um backup completo do banco de dados para o disco local:

-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_full.bak'
    WITH INIT, COMPRESSION, CHECKSUM;
GO

O exemplo a seguir usa um backup diferencial para o disco local:

-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_diff.bak'
    WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;
GO

O exemplo a seguir usa um backup de log de transações para o disco local:

-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_log.trn'
    WITH COMPRESSION, CHECKSUM;
GO

Copie cópias de segurança para a sua conta Armazenamento de Blobs

Depois de os seus backups estarem prontos e quiser começar a migrar bases de dados para uma instância gerida SQL usando o LRS, use as seguintes abordagens para copiar backups existentes para a sua conta Armazenamento de Blobs:

Observação

Para migrar múltiplas bases de dados usando o mesmo contentor do Armazenamento de Blobs do Azure, coloque todos os ficheiros de backup de uma base de dados individual numa pasta separada dentro do contentor. Use a estrutura de arquivo simples para cada pasta de banco de dados. Não há suporte para aninhamento de pastas dentro de pastas de banco de dados.

Limitações

As limitações de LRS aplicam-se às migrações através do portal Azure.

Limitações ao migrar para a camada de serviço Crítica para os Negócios

Ao migrar para um SQL Managed Instance no nível de serviço Business Critical, considere as seguintes limitações:

  • Ao migrar grandes bases de dados, pode experimentar um tempo considerável de inatividade porque as bases de dados ficam indisponíveis após a troca, enquanto são implementadas nas réplicas secundárias do nível de serviço Business Critical. As soluções alternativas estão listadas na secção de transição mais longa.
  • A migração reinicia automaticamente desde o início se um failover imprevisto, uma atualização do sistema ou um patch de segurança interromper a migração. Esta limitação dificulta o planeamento de uma migração previsível sem surpresas de última hora.

Importante

Estas limitações só se aplicam ao migrar para Azure SQL Managed Instance no nível de serviço Business Critical, e não ao nível de serviço General Purpose.

Transição mais longa no nível de serviço Criticamente Importante para os Negócios

Ao migrar para um SQL Managed Instance no nível de serviço "Business Critical", considere o atraso para colocar as bases de dados online na réplica principal, enquanto são replicadas para as réplicas secundárias. Este atraso é especialmente verdadeiro para bases de dados maiores.

Migrar para um SQL Managed Instance no nível de serviço Business Critical demora mais tempo a concluir do que no nível de serviço de Uso Geral. Depois de concluída a transição para o Azure, as bases de dados não estão disponíveis até serem replicadas da réplica primária para as três réplicas secundárias. O processo de semeadura pode demorar um período prolongado dependendo do tamanho da sua base de dados. Quanto maior o banco de dados, mais tempo o processo de propagação para as réplicas secundárias leva - potencialmente até várias horas.

Se for importante que as bases de dados estejam disponíveis assim que o cutover terminar, considere as seguintes soluções alternativas:

  • Migre primeiro para o nível de serviço de Uso Geral e depois atualize para o nível de serviço Crítico de Negócio . A atualização da camada de serviço é uma operação online que mantém os bancos de dados online até que, como etapa final da operação de atualização, ocorra um breve failover.
  • Use o link Managed Instance para uma migração online para uma instância Business Critical sem ter de esperar que as bases de dados estejam disponíveis após o cutover.

A monitorização da migração através do portal Azure está disponível apenas para instâncias de SQL Server que cumpram os requisitos de licenciamento.

Resolver problemas comuns

Para resolver problemas comuns ao migrar para Azure SQL Managed Instance, consulte Resolver problemas de migração.

Próximo passo