Migrar Bancos de Dados do SQL Server usando o Serviço de Repetição de Log – o Instância Gerenciada de SQL do Azure

Applies to:Instância Gerenciada de SQL do Azure

Este artigo explica como migrar bancos de dados SQL Server para Instância Gerenciada de SQL do Azure usando Log Replay Service (LRS). O LRS é um serviço de nuvem gratuito para migrações do Instância Gerenciada de SQL do Azure, baseado na tecnologia de envio de logs do SQL Server. Aprenda o processo completo desde os pré-requisitos até à execução, incluindo as práticas recomendadas para uma migração de banco de dados bem-sucedida.

Há suporte para as fontes a seguir:

• SQL Server em Máquinas Virtuais
• Amazon EC2 (Nuvem de Computação Elástica)
• Amazon RDS (Serviço de Banco de Dados Relacional) para SQL Server
• Google Compute Engine
• SQL de nuvem para SQL Server – GCP (Google Cloud Platform)

Pré-requisitos

Antes de começar, considere os requisitos nesta seção para sua instância de SQL Server e Azure. Revise cuidadosamente as seções limitações e melhores práticas para garantir uma migração bem-sucedida.

SQL Server

Verifique se você atende aos seguintes requisitos para SQL Server:

• SQL Server versões de 2008 a 2022.
• Seu banco de dados SQL Server está usando o modelo de recuperação completa (obrigatório).
• Um backup completo de bancos de dados (um ou vários arquivos).
• Um backup diferencial (um ou vários arquivos).
• Um backup de log (não dividido para um arquivo de log de transações).
• Para versões do SQL Server de 2008 a 2016, faça um backup localmente e envie manualmente para sua conta do Armazenamento de Blobs do Azure.
• Para SQL Server 2016 e posteriores, você pode conectar seu backup diretamente para sua conta Armazenamento de Blobs do Azure.
• Embora não seja necessário habilitar CHECKSUM para backups, é altamente recomendável para evitar a migração acidental de um banco de dados corrompido e para operações de restauração mais rápidas.
• Qualquer versão do Windows Server tem suporte com base no suporte à versão SQL Server.
• Para SQL Server 2019 e posterior, a recuperação acelerada do banco de dados deve ser habilitada, com o repositório de versão persistente definido como PRIMARY. Para obter mais informações, consulte Problemas conhecidos após a migração para Instância Gerenciada de SQL neste artigo.
• Para usar o Service Broker em um banco de dados migrado para Instância Gerenciada de SQL do Azure, o Service Broker deve ser habilitado no banco de dados de origem antes da migração. Para obter mais informações, consulte Problemas conhecidos após a migração para Instância Gerenciada de SQL neste artigo.

Azure

Verifique se você atende aos seguintes requisitos para Azure:

• O módulo PowerShell Az.SQL versão 4.0.0 ou posterior (instalado ou acessado através do Azure Cloud Shell).
• CLI do Azure versão 2.42.0 ou posterior (instalado).
• Um contêiner de Armazenamento de Blobs do Azure provisionado.
• Um token de segurança SAS (Assinatura de Acesso Compartilhado) com permissões de Read e List geradas para o contêiner de Armazenamento de Blobs, ou uma identidade gerenciada que pode acessar o contêiner. Conceder mais permissões do que Read e List fará com que o LRS falhe.
• Coloque os arquivos de backup de um banco de dados individual em uma pasta separada em uma conta de armazenamento usando a estrutura de arquivo simples (obrigatório). Não há suporte para as pastas aninhadas dentro de pastas de banco de dados.

Permissões RBAC do Azure

A execução do LRS por meio dos clientes fornecidos requer uma das seguintes funções de RBAC (controle de acesso baseado em função) Azure:

• função Instância Gerenciada de SQL Colaborador
• Uma função com a seguinte permissão: Microsoft.Sql/managedInstances/databases/*

Práticas recomendadas

Ao usar o LRS, considere as seguintes melhores práticas:

• Divida os backups completos e diferenciais em vários arquivos em vez de usar um único arquivo.
• Habilite a compactação de backup para ajudar nas velocidades de transferência da rede.
• Use o Cloud Shell para executar scripts PowerShell ou CLI, pois ele estará sempre atualizado com os cmdlets mais recentes lançados.
• Configure uma janela de manutenção para que as atualizações do sistema sejam agendadas em um dia e horário específicos fora da janela de migração para evitar atrasos ou interrupções na migração.
• Planeje concluir um só trabalho de migração LRS em no máximo 30 dias. Quando esse período vencer, o trabalho do LRS será cancelado automaticamente.
• Para evitar a migração acidental de um banco de dados corrompido e para uma restauração mais rápida do banco de dados, habilite CHECKSUM ao fazer seus backups. Embora Instância Gerenciada de SQL execute uma verificação básica de integridade em backups sem CHECKSUM, a captura de todas as formas de corrupção não é garantida. Fazer backups com CHECKSUM é a única maneira de garantir que o backup restaurado para Instância Gerenciada de SQL não esteja corrompido. A verificação básica de integridade em backups sem CHECKSUM aumenta o tempo de restauração de um banco de dados.
• Ao migrar para a camada de serviço Comercialmente Crítico, considere um atraso prolongado na disponibilidade do banco de dados após a substituição, enquanto os bancos de dados são propagados para as réplicas secundárias. Para bancos de dados especialmente grandes com requisitos mínimos de tempo de inatividade, considere migrar primeiro para a camada de serviço de Uso Geral e, em seguida, atualizar para a camada de serviço Business Critical ou usar o link Instância Gerenciada para migrar seus dados.
• Carregar milhares de arquivos de banco de dados para restauração pode levar a tempos de migração excessivos e até mesmo falhas. Consolide bancos de dados em menos arquivos para acelerar o processo de migração e garantir o sucesso.
• Para minimizar o tempo de substituição e reduzir o risco de falha, verifique se o último backup é o menor possível.

Configurar uma janela de manutenção

As atualizações do sistema para Instância Gerenciada de SQL têm precedência sobre as migrações de banco de dados em andamento.

A migração é afetada de forma diferente com base na camada de serviço:

• No nível de serviço de uso geral, todas as migrações LRS pendentes são suspensas e retomadas somente após a atualização ser aplicada. Esse comportamento do sistema pode prolongar o tempo de migração, principalmente em bancos de dados grandes.
• No nível de serviço Crítico para os negócios, todas as migrações LRS pendentes são canceladas e reiniciadas automaticamente após a atualização ser aplicada. Esse comportamento do sistema pode prolongar o tempo de migração, principalmente em bancos de dados grandes.

Para obter um tempo previsível para migrações de banco de dados, considere configurar uma janela de manutenção para agendar atualizações do sistema para um dia e hora específicos, e executar e concluir trabalhos de migração fora do período de manutenção designado. Por exemplo, para uma migração que começa na segunda-feira, configure sua janela de manutenção personalizada no domingo para permitir mais tempo para concluir a migração.

A configuração de uma janela de manutenção não é necessária, mas é altamente recomendada para bancos de dados grandes.

Migrar vários bancos de dados

Se você estiver migrando vários bancos de dados usando o mesmo contêiner de Armazenamento de Blobs do Azure, deverá colocar arquivos de backup para bancos de dados diferentes em pastas separadas dentro do contêiner. Todos os arquivos de backup de um banco de dados individual precisam ser colocados em uma estrutura de arquivo simples dentro de uma pasta de banco de dados e as pastas não podem ser aninhadas. Não há suporte para as pastas aninhadas dentro de pastas de banco de dados.

Aqui está um exemplo de uma estrutura de pastas dentro de um contêiner de Armazenamento de Blobs do Azure, uma estrutura necessária para migrar vários bancos de dados usando LRS.

-- Place all backup files for database 1 in a separate "database1" folder in a flat-file structure.
-- Don't use nested folders inside the database1 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database1>/<all-database1-backup-files>

-- Place all backup files for database 2 in a separate "database2" folder in a flat-file structure.
-- Don't use nested folders inside the database2 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database2>/<all-database2-backup-files>

-- Place all backup files for database 3 in a separate "database3" folder in a flat-file structure.
-- Don't use nested folders inside the database3 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database3>/<all-database3-backup-files>

Criar uma conta de armazenamento

Você usa uma conta Armazenamento de Blobs do Azure como armazenamento intermediário para arquivos de backup entre sua instância de SQL Server e sua implantação de Instância Gerenciada de SQL. Para criar uma nova conta de armazenamento e um contêiner de blobs dentro da conta de armazenamento:

1. Criar uma conta de armazenamento.
2. Crie um contêiner de blobs na conta de armazenamento.

Configurar o armazenamento do Azure atrás de um firewall

É possível usar o Armazenamento de Blobs do Azure protegido por um firewall, mas isso requer configuração adicional. Para habilitar o acesso de leitura/gravação ao Armazenamento do Azure com o Firewall do Azure ativado, você precisa adicionar a sub-rede da SQL Managed Instance às regras de firewall da rede virtual para a conta de armazenamento usando a delegação de sub-rede da MI e o endpoint de serviço de Armazenamento. A conta de armazenamento e a instância gerenciada precisam estar na mesma região ou em duas regiões emparelhadas.

Se o armazenamento Azure estiver atrás de um firewall, você poderá ver a seguinte mensagem no log de erros da instância gerenciada do SQL:

Audit: Storage access denied user fault. Creating an email notification:

Isso gera um email que notifica você de que a auditoria para a instância gerenciada de SQL não está conseguindo gravar os logs de auditoria na conta de armazenamento. Se você vir esse erro ou receber esse email, siga as etapas desta seção para configurar o firewall.

Para configurar o firewall, siga estas etapas:

1. Acesse sua instância gerenciada de SQL no portal Azure e selecione a sub-rede para abrir a página Subnets.

   

2. Na página Sub-redes, escolha o nome da sub-rede para abrir a página de configuração da sub-rede.

   

3. Em Subnet delegation, escolha Microsoft.Sql/managedInstances da lista suspensa Delegar sub-rede para um serviço. Aguarde cerca de uma hora para que as permissões sejam propagadas e, em Endpoints de serviço, escolha Microsoft.Storage da lista suspensa Serviços.

   

4. Em seguida, vá para sua conta de armazenamento no portal do Azure, selecione Networking em Security + networking e escolha a guia Firewalls e redes virtuais.

5. Na guia Firewalls e redes virtuais da conta de armazenamento, escolha +Adicionar rede virtual existente para abrir a página Adicionar redes.

   

6. Selecione a assinatura apropriada, a rede virtual e a sub-rede da instância gerenciada nos menus de lista suspensa e, em seguida, selecione Adicionar para adicionar a rede virtual da instância gerenciada de SQL à conta de armazenamento.

Autenticar em sua conta Armazenamento de Blobs

Use um token SAS ou uma identidade gerenciada para acessar sua conta Armazenamento de Blobs do Azure.

Valide o acesso ao armazenamento da instância gerenciada

Valide se sua instância gerenciada pode acessar sua conta Armazenamento de Blobs.

Primeiro, carregue qualquer backup de banco de dados, como full_0_0.bak, no contêiner Armazenamento de Blobs do Azure.

Em seguida, conecte-se à instância gerenciada e execute um exemplo de consulta de teste para determinar se a instância gerenciada pode acessar o backup no contêiner.

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/databases]
    WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
    SECRET = '<sastoken>';

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

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

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>]
    WITH IDENTITY = 'MANAGED IDENTITY';

Carregar backups em sua conta do Armazenamento de Blobs

Quando o contêiner de blob estiver pronto e você confirmar que sua instância gerenciada pode acessar o contêiner, você pode começar a carregar seus backups em sua conta Armazenamento de Blobs. Você pode:

• Copie seus backups para sua conta de Armazenamento de Blobs.
• Faça backups de SQL Server diretamente para sua conta de Armazenamento de Blobs usando o comando BACKUP TO URL, se o ambiente permitir (começando com as versões SQL Server 2012 SP1 CU2 e SQL Server 2014).

Copiar backups existentes para sua conta Armazenamento de Blobs

Se você estiver em uma versão anterior do SQL Server ou se o ambiente não der suporte ao backup diretamente em uma URL, faça backups em sua instância de SQL Server como faria normalmente e copie-os para sua conta Armazenamento de Blobs.

Fazer backups em uma instância de SQL Server

Configure os bancos de dados que você deseja migrar para o modo de recuperação completa para permitir backups de logs.

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

Para fazer manualmente backups completos, diferenciais e de log de seu banco de dados para o armazenamento local, use os seguintes scripts de exemplo do T-SQL. CHECKSUM não é obrigató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 usa 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

Copiar backups para sua conta de Armazenamento de Blobs

Depois que os backups estiverem prontos e você quiser começar a migrar bancos de dados para uma instância gerenciada usando o LRS, você poderá usar as seguintes abordagens para copiar backups existentes para sua conta Armazenamento de Blobs:

• Baixe e instale AzCopy.
• Baixe e instale Gerenciador de Armazenamento do Azure.
• Use Gerenciador de Armazenamento no portal o Azure.

Faça backups diretamente em sua conta de Armazenamento de Blobs

Se você estiver em uma versão com suporte do SQL Server (começando com SQL Server 2012 SP1 CU2 e SQL Server 2014) e suas políticas corporativas e de rede permitirem isso, você poderá fazer backups de SQL Server diretamente para sua conta Armazenamento de Blobs usando o SQL Server nativo opção BACKUP TO URL. Se você puder usar BACKUP TO URL, não precisará fazer backups no armazenamento local e carregá-los em sua conta Armazenamento de Blobs.

Ao fazer backups nativos diretamente em sua conta de Armazenamento de Blobs, você precisa se autenticar na conta de armazenamento.

Use o seguinte comando para criar uma credencial que importe o token SAS para sua instância de SQL Server:

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>]
    WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
    SECRET = '<SAS_TOKEN>';

Para obter instruções detalhadas sobre como trabalhar com tokens SAS, examine o tutorial Use Armazenamento de Blobs do Azure com SQL Server.

Depois de criar a credencial para autenticar sua instância de SQL Server com Armazenamento de Blobs, você pode usar o comando BACKUP TO URL para fazer backups diretamente na conta de armazenamento. CHECKSUM é recomendado, mas não é obrigatório.

O exemplo a seguir usa um backup completo do banco de dados para um URL:

-- Take a full database backup to a URL
BACKUP DATABASE [SampleDB]
    TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_full.bak'
    WITH INIT, COMPRESSION, CHECKSUM;
GO

O exemplo a seguir usa um backup de banco de dados diferencial para um URL:

-- Take a differential database backup to a URL
BACKUP DATABASE [SampleDB]
    TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_diff.bak'
    WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;
GO

O exemplo a seguir usa um backup de log de transações para um URL:

-- Take a transactional log backup to a URL
BACKUP LOG [SampleDB]
    TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_log.trn'
    WITH COMPRESSION, CHECKSUM;

Entre no Azure e selecione uma assinatura

Use o seguinte cmdlet do PowerShell para entrar no Azure:

Login-AzAccount

Selecione a assinatura na qual está a instância gerenciada usando o seguinte cmdlet do PowerShell:

Select-AzSubscription -SubscriptionId <subscription ID>

Inicie a migração

Inicie a migração iniciando o LRS. Você pode iniciar o serviço no modo de preenchimento automático ou contínuo.

Ao usar o modo de preenchimento automático, a migração é finalizada automaticamente quando o último dos arquivos de backup especificados tiver sido restaurado. Essa opção exige que toda a cadeia de backup esteja disponível com antecedência e seja carregada em sua conta Armazenamento de Blobs. Ela não permite adicionar novos arquivos de backup enquanto a migração está em andamento. Essa opção requer que o comando start especifique o nome do arquivo do último backup. Recomendamos este modo para cargas de trabalho passivas que não exigem atualização de dados.

Quando você usa o modo contínuo, o serviço verifica continuamente a pasta Armazenamento de Blobs do Azure e restaura todos os novos arquivos de backup que são adicionados enquanto a migração está em andamento. A migração só é finalizada após a solicitação de substituição manual. Você precisará usar a migração de modo contínuo quando não tiver toda a cadeia de backup com antecedência e ao planejar adicionar novos arquivos de backup depois que a migração estiver em andamento. Recomendamos este modo para cargas de trabalho ativas que exigem atualização de dados.

Planeje concluir um só trabalho de migração LRS em no máximo 30 dias. Quando esse período vencer, o trabalho do LRS será cancelado automaticamente.

Iniciar o LRS no modo de preenchimento automático

Verifique se toda a cadeia de backup foi carregada em sua conta Armazenamento de Blobs do Azure. Essa opção não permite que novos arquivos de backup sejam adicionados enquanto a migração estiver em andamento.

Para iniciar o LRS no modo de preenchimento automático, use comandos do PowerShell ou CLI do Azure. Especifique o nome do último arquivo de backup usando o parâmetro -LastBackupName. Depois que a restauração do último arquivo de backup especificado for concluída, o serviço iniciará uma substituição automaticamente.

Restaure seu banco de dados da conta de armazenamento usando o token SAS ou uma identidade gerenciada.

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D" `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb -a --last-bn "backup.bak"
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity  `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

Iniciar o LRS no modo contínuo

Verifique se você carregou sua cadeia de backup inicial em sua conta Armazenamento de Blobs do Azure.

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity

Script do trabalho de migração

Clientes do PowerShell e CLI do Azure que iniciam o LRS no modo contínuo são síncronos. Nesse modo, o PowerShell e o CLI do Azure aguardam a resposta da API para relatar o êxito ou a falha antes de iniciar o trabalho.

Durante essa espera, o comando não devolverá o controle ao prompt de comando. Se você estiver criando scripts para a experiência de migração e precisar do comando “start” do LRS para devolver o controle imediatamente e continuar com o restante do script, você poderá executar o PowerShell como um trabalho em segundo plano com a opção -AsJob. Por exemplo:

$lrsjob = Start-AzSqlInstanceDatabaseLogReplay <required parameters> -AsJob

Quando você inicia um trabalho em segundo plano, obtém imediatamente como retorno um objeto de trabalho, mesmo que o trabalho demore muito tempo para ser finalizado. É possível continuar a trabalhar na sessão sem interrupção enquanto o trabalho é executado. Para obter detalhes sobre como executar o PowerShell como um trabalho em segundo plano, consulte a documentação Start-Job do PowerShell.

Da mesma forma, para iniciar um comando CLI do Azure no Linux como um processo em segundo plano, use o e comercial (&) no final do comando de início do LRS:

az sql midb log-replay start <required parameters> &

Monitorar o progresso da migração

O Az.SQL 4.0.0 e posterior fornece um relatório de progresso detalhado. Confira Detalhes de restauração do banco de dados gerenciado – GET para ver um exemplo de resultado.

Para monitorar o progresso de migração em andamento por meio do PowerShell, use o seguinte comando:

Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Para monitorar o progresso contínuo da migração por meio do CLI do Azure, use o seguinte comando:

az sql midb log-replay show -g mygroup --mi myinstance -n mymanageddb

Para acompanhar detalhes adicionais sobre uma solicitação com falha, use o comando do PowerShell Get-AzSqlInstanceOperation ou o comando do CLI do Azure az sql mi op show.

Parar a migração (opcional)

Se você precisar interromper a migração, use o PowerShell ou o CLI do Azure. Interromper a migração exclui o banco de dados sendo restaurado na sua instância gerenciada. Portanto, retomar a migração não será possível.

Para parar o processo de migração por meio do PowerShell, use o seguinte comando:

Stop-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Para interromper o processo de migração por meio do CLI do Azure, use o seguinte comando:

az sql midb log-replay stop -g mygroup --mi myinstance -n mymanageddb

Concluir a migração (modo contínuo)

Se você iniciar o LRS no modo contínuo, verifique se seu aplicativo e a carga de trabalho do SQL Server foram interrompidos para impedir que novos arquivos de backup sejam gerados. Verifique se o último backup de sua instância de SQL Server foi carregado em sua conta de Armazenamento de Blobs do Azure. Monitore o progresso da restauração em sua instância gerenciada, garantindo que o último backup da parte final do log tenha sido restaurado.

Quando o último backup da parte final do log for restaurado em sua instância gerenciada, inicie a substituição manual para concluir a migração. Depois que a substituição for concluída, o banco de dados ficará disponível para o acesso para leitura e gravação na instância gerenciada.

Para concluir o processo de migração no modo contínuo do LRS por meio do PowerShell, use o seguinte comando:

Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-LastBackupName "last_backup.bak"

Para concluir o processo de migração no modo contínuo LRS por meio do CLI do Azure, use o seguinte comando:

az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"

Limitações

Considere as seguintes limitações ao migrar com o LRS:

• Você não pode usar os bancos de dados que estão sendo restaurados por meio do LRS até que o processo de migração seja concluído.
• Durante o processo de migração, os bancos de dados que estão sendo migrados não podem ser usados para acesso somente leitura em Instância Gerenciada de SQL.
• Após a conclusão da migração, o processo de migração será finalizado e não poderá ser retomado com backups diferenciais adicionais.
• Somente os arquivos dos banco de dados .bak, .log e .diff são suportados pelo LRS. Não há suporte para arquivos Dacpac e bacpac.
• Você precisa configurar uma janela de manutenção para agendar atualizações do sistema em um dia e hora específicos. Planeje executar e concluir as migrações fora da janela de manutenção agendada.
• Backups de banco de dados que são feitos sem CHECKSUM:
  • pode potencialmente migrar bancos de dados corrompidos.
  • demoram mais para restaurar do que backups de banco de dados com CHECKSUM habilitado.
• O token SAS (assinatura de acesso compartilhado) que o LRS usa deve ser gerado para todo o contêiner de Armazenamento de Blobs do Azure e deve ter permissões Read e List. Por exemplo, se você conceder permissões Read, List e Write, o LRS não será iniciado devido à permissão extra Write.
• No momento, não há suporte para o uso de tokens SAS criados com permissões definidas por meio da política de acesso armazenada. Siga as instruções neste artigo para especificar manualmente as permissões de Leitura e Lista para o token SAS.
• Você deve colocar arquivos de backup para bancos de dados diferentes em pastas separadas na conta Armazenamento de Blobs em uma estrutura de arquivo simples. Não há suporte para as pastas aninhadas dentro de pastas de banco de dados.
• Se você estiver usando o modo de preenchimento automático, toda a cadeia de backup precisará estar disponível com antecedência na conta Armazenamento de Blobs. Não é possível adicionar novos arquivos de backup no modo de preenchimento automático. Use o modo contínuo se precisar adicionar novos arquivos de backup enquanto a migração estiver em andamento.
• Você deve iniciar o LRS separadamente para cada banco de dados que aponta para o caminho completo de URI que contém uma pasta de banco de dados individual.
• O caminho do URI de backup, o nome do contêiner ou os nomes de pasta não podem conter backup ou Backup porque são palavras-chave reservadas.
• Ao iniciar várias restaurações do Log Replay em paralelo, visando o mesmo contêiner de armazenamento, certifique-se de que o mesmo token SAS válido seja fornecido para cada operação de restauração.
• O LRS dá suporte à migração de um número total de bancos de dados para uma única instância até os limites de recursos da camada de serviço. Por exemplo, você pode restaurar até 100 bancos de dados totais na camada de serviço uso geral e até 500 bancos de dados totais na camada de serviço Uso Geral da Próxima Geração .
• O LRS dá suporte a 100 restaurações simultâneas de banco de dados para uma única instância e 150 restaurações simultâneas de banco de dados para todas as instâncias em uma única assinatura. Por exemplo, você pode restaurar 100 bancos de dados em paralelo a duas instâncias na mesma assinatura ao mesmo tempo ou 50 bancos de dados em três lotes simultâneos em paralelo a quatro instâncias separadas na mesma assinatura.
• Um único trabalho do LRS pode ser executado por no máximo 30 dias. Após esse período ele será cancelado automaticamente.
• Embora seja possível usar uma conta Armazenamento do Azure por trás de um firewall, a configuração extra é necessária e a conta de armazenamento e a instância gerenciada devem estar na mesma região ou em duas regiões emparelhadas. Confira Configurar firewall para saber mais.
• O número máximo de bancos de dados que você pode restaurar em paralelo é 150 por assinatura única. Em alguns casos, é possível aumentar esse limite abrindo um tíquete de suporte.
• Carregar milhares de arquivos de banco de dados para restauração pode levar a tempos de migração excessivos e até mesmo falhas. Consolide bancos de dados em menos arquivos para acelerar o processo de migração e garantir o sucesso.
• Há dois cenários, no início e no final do processo de migração, em que uma migração é anulada se ocorrer um failover e o trabalho de migração deve ser reiniciado manualmente desde o início à medida que o banco de dados é removido do Instância Gerenciada de SQL:
  • Se ocorrer um failover quando o primeiro backup de banco de dados completo estiver em processo de restauração para Instância Gerenciada de SQL quando o trabalho de migração for iniciado pela primeira vez, o trabalho de migração deverá ser reiniciado manualmente desde o início.
  • Se ocorrer um failover após o início da substituição de migração, o trabalho de migração deverá ser reiniciado manualmente desde o começo. Verifique se o último arquivo de backup é o menor possível para minimizar o tempo de substituição e reduzir o risco de um failover durante o processo de substituição.
• Se a recuperação acelerada de banco de dados estiver desabilitada no SQL Server 2019 e em versões posteriores do SQL Server de origem, você não poderá mais habilitá-la depois de migrar para Instância Gerenciada de SQL do Azure. Além disso, se o PVS (repositório de versão persistente) não estiver definido PRIMARY, você poderá enfrentar problemas com operações de restauração na instância gerenciada de SQL de destino.
• Se Service Broker estiver desabilitado na instância de SQL Server de origem, você não poderá usar o Service Broker na instância gerenciada de SQL de destino após a migração.

Limitações ao migrar para a camada de serviço Comercialmente Crítico

Ao migrar para um Instância Gerenciada de SQL na camada de serviço Business Critical, considere as seguintes limitações:

• Ao migrar grandes bancos de dados, pode haver um tempo de inatividade considerável, pois os bancos de dados ficam indisponíveis após a transição, enquanto os bancos de dados são inicializados em réplicas secundárias da camada de serviço Comercialmente Crítico. Soluções alternativas estão listadas na seção de transição mais longa.
• A migração é reiniciada automaticamente desde o início se for interrompida por um failover não planejado, atualização do sistema ou patch de segurança, dificultando o planejamento de uma migração previsível sem surpresas de última hora.

Transição mais demorada na camada de serviço Crítico para os Negócios

Se você estiver migrando para um Instância Gerenciada de SQL na camada de serviço Business Critical, contabilize o atraso em colocar os bancos de dados online na réplica primária enquanto eles são propagados para as réplicas secundárias. Isso é especialmente verdadeiro para bancos de dados maiores.

A migração para um Instância Gerenciada de SQL na camada de serviço Business Critical leva mais tempo para ser concluída do que na camada de serviço de Uso Geral. Depois que a transição para o Azure é concluída, os bancos de dados ficam indisponíveis até serem copiados da réplica primária para as três réplicas secundárias, o que pode demorar bastante tempo, dependendo do tamanho dos bancos de dados. Quanto maior o banco de dados, mais longa será a propagação para as réplicas secundárias. Pode levar até algumas horas.

Se for importante que os bancos de dados estejam disponíveis assim que a transição for concluída, considere as seguintes soluções alternativas:

• Migre primeiro para a camada de serviço de Uso Geral e, em seguida, atualize para a camada de serviço Comercialmente Crítico. Atualizar a camada de serviço é uma operação online que mantém seus bancos de dados online até um breve failover como a etapa final da operação de atualização.
• Use o link Instância Gerenciada para uma migração online para uma instância Business Critical sem precisar esperar que os bancos de dados fiquem disponíveis após a substituição.

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.

Resolver problemas do LRS

Depois de iniciar o LRS, use um dos seguintes cmdlets de monitoramento para ver o status da operação em andamento:

• Para o PowerShell: get-azsqlinstancedatabaselogreplay
• Para o CLI do Azure: az_sql_midb_log_replay_show

Para revisar detalhes sobre uma operação com falha:

• Para o PowerShell: Get-AzSqlInstanceOperation
• Para CLI do Azure: az sql mi op show

Se a inicialização do LRS falhar após algum tempo e você receber um erro, verifique os problemas mais comuns:

• Um banco de dados existente em sua instância gerenciada tem o mesmo nome que aquele que você está tentando migrar de sua instância de SQL Server? Resolva esse conflito renomeando um dos bancos de dados.
• As permissões concedidas pelo token SAS são apenas para Leitura e Listagem? Conceder mais permissões do que Read e List fará com que o LRS falhe.
• Você copiou o token SAS para LRS após o ponto de interrogação (?), com conteúdo semelhante a sv=2020-02-10...?
• O tempo de validade do token SAS é apropriado para a janela de tempo de inicialização e conclusão da migração? Pode haver incompatibilidades devido aos diferentes fusos horários usados para a implantação do Instância Gerenciada de SQL e o token SAS. Tente regenerar o token SAS e estender a validade da janela de tempo do token para antes e depois da data atual.
• Ao iniciar várias restaurações do Log Replay em paralelo direcionando para o mesmo contêiner de armazenamento, certifique-se de que o mesmo token SAS válido seja fornecido para cada operação de restauração.
• O nome do banco de dados, o nome do grupo de recursos e o nome da instância gerenciada estão escritos corretamente?
• Se você iniciou o LRS no modo de preenchimento automático, um nome de arquivo válido para o último arquivo de backup foi especificado?
• O caminho do URI de backup contém as palavras-chave backup ou backups? Renomeie o contêiner ou as pastas que estão usando backup ou backups, pois elas são palavras-chave reservadas.

Conteúdo relacionado

• Visão Geral do Serviço de Reprodução de Log com Instância Gerenciada de SQL do Azure
• Visão geral do link de Instância Gerenciada
• Igrate de SQL Server para Instância Gerenciada de SQL do Azure
• diferenças de T-SQL entre o SQL Server e o Instância Gerenciada de SQL do Azure
• Melhores práticas para estimar custo e dimensionar cargas de trabalho migradas para Azure
• Compare LRS com o link do Instância Gerenciada