Compartilhar via

Migrar bancos de dados do SQL Server usando o Serviço de Reprodução de Log – Instância Gerenciada de SQL do Azure

  • Artigo

Aplica-se a: Instância Gerenciada de SQL do Azure

Este artigo explica como migrar bancos de dados para a Instância Gerenciada de SQL do Azure usando o LRS (Serviço de Reprodução de Log). O LRS é um serviço de nuvem gratuito que está disponível para a Instância Gerenciada de SQL do Azure, baseado na tecnologia de envio de logs do SQL Server.

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 a seguir para sua instância de SQL Server e para o Azure. Revise cuidadosamente as seções limitações e melhores práticas para garantir uma migração bem-sucedida.

Importante

  • Antes de migrar bancos de dados para a camada de serviço Crítico para os negócios, considere essas limitações, que não se aplicam à camada de serviço de Uso geral.
  • 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.
  • O LRS não dá suporte a acesso somente leitura a bancos de dados durante a migração.
  • 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.

Antes de migrar bancos de dados para a camada de serviço Crítico para os negócios, considere essas limitações, que não se aplicam à camada de serviço de Uso geral.

SQL Server

Verifique se você tem os seguintes requisitos para o SQL Server:

  • Versões do SQL Server 2008 a 2022.
  • Seu banco de dados do 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 as versões do SQL Server 2008 a 2016, faça um backup localmente e carregue-o manualmente em sua conta do Armazenamento de Blobs do Azure.
  • A partir do SQL Server 2016 e posterior, você pode levar seu backup diretamente para a conta de 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.

Azure

Verifique se você tem os seguintes requisitos para o Azure:

  • Módulo Az.SQL do PowerShell versão 4.0.0 ou posterior (instalado ou acessado por meio do Azure Cloud Shell).
  • CLI do Azure versão 2.42.0 ou posterior (instalada).
  • Um contêiner provisionado do Armazenamento de Blobs do Azure.
  • Um token de segurança de assinatura de acesso compartilhado (SAS) com permissões 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 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) do Azure:

Práticas recomendadas

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

  • Execute o Assistente de Migração de Dados para validar que os bancos de dados estão prontos para serem migrados para a Instância Gerenciada de SQL.
  • 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 sempre será atualizado para usar os cmdlets lançados mais recentemente.
  • 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 o SQL Managed Instance execute uma verificação de integridade básica em backups sem CHECKSUM, não há garantia de que todas as formas de corrupção sejam detectadas. Fazer backups com CHECKSUM é a única maneira de garantir que o backup restaurado na Instância Gerenciada do 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 o nível de serviço Crítico para os negócios, considere um atraso prolongado na disponibilidade do banco de dados após a transferência, enquanto os bancos de dados são propagados para réplicas secundárias. Para bancos de dados especialmente grandes com requisitos mínimos de tempo de inatividade, considere migrar primeiro para o nível de serviço de uso geral e depois atualizar para o nível de serviço Comercialmente Critico ou usar o link de Instância Gerenciada do Banco de Dados SQL do Azure 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 seu sucesso.

Configurar uma janela de manutenção

As atualizações do sistema na Instância Gerenciada de SQL terão precedência em relação às migrações de banco de dados em andamento.

A migração é impactada de forma diferente com base no nível 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.

Configurar uma janela de manutenção não é obrigatório, mas é altamente recomendado para bancos de dados grandes.

Observação

Embora uma janela de manutenção controle a previsibilidade de atualizações planejadas, ela não garante que failovers não planejados ou atualizações de patches de segurança não ocorrerão. Um failover não planejado ou um patch de segurança (que tem precedência sobre todas as outras atualizações) ainda pode interromper sua migração.

Migrar vários bancos de dados

Caso esteja migrando vários bancos de dados usando o mesmo contêiner do Armazenamento de Blobs do Azure, você deverá colocar os arquivos de backup de 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 pastas aninhadas dentro de pastas de banco de dados.

Aqui está um exemplo de uma estrutura de pasta dentro de um contêiner de Armazenamento de Blobs do Azure, uma estrutura necessária para migrar vários bancos de dados usando o 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 de Armazenamento de Blobs do Azure como armazenamento intermediário para arquivos de backup entre sua instância do SQL Server e sua implantação da 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 com a proteção de um firewall

Há suporte para o uso do Armazenamento de Blobs do Azure protegido por um firewall, mas isso exige uma 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 instância gerenciada do SQL às regras de firewall da rede virtual para a conta de armazenamento usando a delegação de sub-rede MI e o ponto de extremidade do 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 seu armazenamento do 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 cofre, siga estas etapas:

  1. Acesse a instância gerenciada no portal do Azure e selecione a sub-rede para abrir a página Sub-redes.

    Captura de tela da página Visão geral da instância gerenciada de SQL do portal do Azure, com a sub-rede selecionada.

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

    Captura de tela da página Sub-rede da instância gerenciada de SQL do portal do Azure, com a sub-rede selecionada.

  3. Em Delegação de sub-rede, escolha Microsoft.Sql/managedInstances no menu suspenso Delegar sub-rede para um serviço. Aguarde cerca de uma hora para que as permissões sejam propagadas e, em Pontos de extremidade de serviço, escolha Microsoft.Storage na lista suspensa Serviços.

    Captura de tela da página de configuração Sub-rede da instância gerenciada de SQL do portal do Azure.

  4. Em seguida, acesse sua conta de armazenamento no portal do Azure, selecione Rede em Segurança + rede 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.

    Captura de tela da página Rede da conta de armazenamento do portal do Azure, com a opção Adicionar rede virtual existente selecionada.

  6. Escolha a assinatura apropriada, a rede virtual e a sub-rede da instância gerenciada nos menus suspensos e selecione Adicionar para adicionar a rede virtual da instância gerenciada de SQL à conta de armazenamento.

Autenticar em sua conta de Armazenamento de Blobs

Acesse sua conta Armazenamento de Blobs do Azure usando um token SAS ou uma identidade gerenciada.

Aviso

Não é possível usar um token SAS e uma identidade gerenciada em paralelo na mesma conta de armazenamento. Você pode usar tanto um token SAS quanto uma identidade gerenciada, mas não ambos.

Gerar um token de autenticação SAS do Armazenamento de Blobs para o LRS

Acesse sua conta de Armazenamento de Blobs do Azure usando um token SAS.

Você pode usar uma conta de Armazenamento de Blobs do Azure como armazenamento intermediário para arquivos de backup entre sua instância do SQL Server e sua implantação da Instância Gerenciada de SQL. Gere um token de autenticação SAS para LRS apenas com permissões de Leitura e Lista. O token permite que o LRS acesse sua conta do Armazenamento de Blobs e use os arquivos de backup para restaurá-los para sua instância gerenciada.

Siga estas etapas para gerar o token:

  1. No portal do Azure, abra o Gerenciador de Armazenamento.

  2. Expanda Contêineres de Blob.

  3. Clique com o botão direito do mouse no contêiner de blob e selecione Obter Assinatura de Acesso Compartilhado.

    Captura de tela que mostra as seleções para gerar um token de autenticação SAS.

  4. Selecione o período de duração do token. Verifique se o token é válido durante a migração.

  5. Selecione o fuso horário para o token: UTC ou seu horário local.

    Importante

    O fuso horário do token e sua instância gerenciada podem não ser compatíveis. Verifique se o token SAS tem a validade de tempo apropriada, levando os fusos horários em consideração. Para contabilizar as diferenças de fuso horário, defina o valor A PARTIR DE da validade bem antes do início da janela de migração e o valor ATÉ bem depois de esperar que a migração termine.

  6. Selecione apenas as permissões de Leitura e Lista.

    Importante

    Não selecione nenhuma outra permissão. Se você fizer isso, o LRS não será iniciado. Esse requisito de segurança é proposital.

  7. Selecione Criar.

    Captura de tela que mostra seleções de vencimento, fuso horário e permissões de tokens SAS, juntamente com o botão Criar.

A autenticação SAS é gerada com a validade de tempo especificada. Você precisa da versão URI do token, conforme mostrado na captura de tela a seguir:

Captura de tela que mostra um exemplo da versão URI de um token SAS.

Observação

No momento, não há suporte para o uso de tokens SAS criados com permissões definidas durante a configuração da política de acesso armazenada. Siga as instruções neste procedimento para especificar manualmente as permissões de Leitura e Lista para o token SAS.

Copiar parâmetros do token SAS

Acesse sua conta Armazenamento de Blobs do Azure usando um token SAS ou uma identidade gerenciada.

Antes de usar o token SAS para iniciar o LRS, você precisa entender a estrutura dele. O URI do token SAS gerado consiste em duas partes separadas por um ponto de interrogação (?), conforme mostrado neste exemplo:

Exemplo de URI de um token SAS gerado para o Serviço de Reprodução de Log.

A primeira parte, começando com https:// até o ponto de interrogação (?), é usada para o parâmetro StorageContainerURI que é alimentado como a entrada no LRS. Ele fornece ao LRS informações sobre a pasta em que os arquivos de backup dos bancos de dados são armazenados.

A segunda parte, depois do ponto de interrogação (?) até o final da cadeia de caracteres, é o parâmetro StorageContainerSasToken. Essa parte é o token de autenticação assinado real, que é válido durante a duração do tempo especificado. Essa parte não precisa necessariamente começar com sp=, como mostrado no exemplo. Seu cenário pode ser diferente.

Edite os seguintes parâmetros:

  1. Copie a primeira parte do token, de https:// até, mas não incluindo, o ponto de interrogação (?). Use-o como o parâmetro StorageContainerUri no PowerShell ou na CLI do Azure ao iniciar o LRS.

    Captura de tela que mostra onde copiar a primeira parte do token.

  2. Copie a segunda parte do token, depois do ponto de interrogação (?) até o final da cadeia de caracteres. Use-o como o parâmetro StorageContainerSasToken no PowerShell ou na CLI do Azure ao iniciar o LRS.

    Captura de tela que mostra onde copiar a segunda parte do token.

Observação

Não inclua o ponto de interrogação (?) ao copiar qualquer parte do token.

Validar o acesso de armazenamento da instância gerenciada

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

Primeiro, carregue qualquer backup de banco de dados, como full_0_0.bak, no contêiner do 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.

Se você estiver usando um token SAS para se autenticar na sua conta de armazenamento, substitua o <sastoken> pelo token SAS e execute a seguinte consulta na instância:

CREATE CREDENTIAL [https://mitutorials.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'

Carregar backups em sua conta de Armazenamento de Blobs

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

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

Copiar backups existentes para sua conta de Armazenamento de Blobs

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

Fazer backups em uma Instância do 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 os bancos de dados para uma instância gerenciada usando o LRS, use as seguintes abordagens para copiar os backups existentes para sua conta de Armazenamento de Blobs:

Observação

Para migrar vários bancos de dados usando o mesmo contêiner do Armazenamento de Blobs do Azure, coloque todos os arquivos de backup de um banco de dados individual em uma pasta separada dentro do contêiner. Use a estrutura de arquivo simples para cada pasta de banco de dados. Não há suporte para pastas aninhadas dentro de pastas de banco de dados.

Fazer backups diretamente na sua conta de Armazenamento de Blobs

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

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

Use o seguinte comando para criar uma credencial que importa o token SAS para a instância do 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, confira o tutorial Usar o Armazenamento de Blobs do Azure com o SQL Server.

Depois de criar a credencial para autenticar sua instância do SQL Server com o Armazenamento de Blobs, use 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

Entrar no Azure e selecionar uma assinatura

Use o seguinte cmdlet do PowerShell para conectar 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 na sua conta de Armazenamento de Blobs do Azure. 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 examina continuamente a pasta do Armazenamento de Blobs do Azure e restaura os novos arquivos de backup que foram 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.

Observação

Ao migrar vários bancos de dados, cada banco de dados deve estar em sua própria pasta. O LRS deve ser iniciado separadamente para cada banco de dados, apontando para o caminho completo do URI do contêiner do Armazenamento de Blobs do Azure e a pasta individual do banco de dados. Não há suporte para pastas aninhadas dentro de pastas de banco de dados.

Iniciar o LRS no modo de preenchimento automático

Verifique se toda a cadeia de backup foi carregada na sua conta de 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 os comandos do PowerShell ou do 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.

Importante

  • Verifique se toda a cadeia de backup foi carregada em sua conta de Armazenamento de Blobs do Azure antes de iniciar a migração no modo de preenchimento automático. Esse modo não permite que novos arquivos de backup sejam adicionados enquanto a migração estiver em andamento.
  • Verifique se você especificou o último arquivo de backup corretamente e que não carregou mais arquivos depois dele. Se o sistema detectar mais arquivos de backup além do último arquivo de backup especificado, a migração falhará.

O exemplo seguinte do PowerShell inicia o LRS no modo de preenchimento automático usando um token SAS:

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"

O exemplo seguinte da CLI do Azure inicia o LRS no modo de preenchimento automático usando um token SAS:

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"

Iniciar o LRS no modo contínuo

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

Importante

Depois de iniciar o LRS no modo contínuo, você poderá adicionar novos logs e backups diferenciais a sua conta de armazenamento até que ocorra a substituição manual. Depois que a substituição manual for iniciada, nenhum arquivo diferencial adicional poderá ser adicionado nem restaurado.

O exemplo seguinte do PowerShell inicia o LRS no modo contínuo usando um token SAS:

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"

O exemplo da CLI do Azure a seguir inicia o LRS no modo contínuo:

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"

Script do trabalho de migração

Os clientes do PowerShell e da CLI do Azure que irão iniciar o LRS no modo contínuo são síncronos. Nesse modo, o PowerShell e a CLI do Azure aguardarão a resposta da API para relatar o sucesso 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 do CLI do Azure no Linux como um processo em segundo plano, use o “e” comercial (&) no final do comando “start” 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 saída.

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 da migração em andamento por meio da 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 Get-AzSqlInstanceOperation do PowerShell ou use o comando az sql mi op show da CLI do Azure.

Parar a migração (opcional)

Se você precisar interromper a migração, use o PowerShell ou a 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 parar 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 o aplicativo e a carga de trabalho do SQL Server foram interrompidos para evitar que novos arquivos de backup sejam gerados. Verifique se o último backup de sua instância do SQL Server foi carregado no 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 acesso de 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 do 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 o acesso somente leitura na 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 de assinatura de acesso compartilhado (SAS) usado pelo LRS deve ser gerado para todo o contêiner do Armazenamento de Blobs do Azure Read e List deve ter apenas permissões e. 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 de bancos de dados diferentes em pastas separadas do Armazenamento de Blobs em uma estrutura de arquivos simples. Não há suporte para pastas aninhadas dentro de pastas de banco de dados.
  • Se estiver usando o modo de preenchimento automático, toda a cadeia de backup precisará estar disponível com antecedência na conta do Armazenamento de Blobs do Azure. 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 das pastas não devem conter backup ou backups, pois essas 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 pode dar suporte a até 100 processos de restauração simultâneos para cada instância gerenciada.
  • 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 do Armazenamento do Azure com a proteção de um firewall, uma configuração extra é necessária, e a conta de armazenamento e a instância gerenciada precisam 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 é 200 por assinatura única. Em alguns casos, é possível aumentar esse limite via 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 seu sucesso.

Observação

Se você precisar que um banco de dados seja acessível somente leitura durante a migração, com um prazo muito maior para executar a migração e com tempo de inatividade mínimo, considere usar o recurso Link de instância gerenciada como uma solução de migração recomendada.

Limitações ao migrar para o nível de serviço Comercialmente Crítico

Ao migrar para uma instância gerenciada de SQL na camada de serviço Comercialmente Crítico, 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 transferência enquanto são propagados para 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.

Importante

Essas limitações são aplicáveis ​​somente ao migrar para o nível de serviço Comercialmente Crítico e não para o nível de serviço Propósito geral.

Maior transição no nível de serviço Comercialmente Crítico

Se você estiver migrando para uma instância gerenciada de SQL na camada de serviço Comercialmente Crítico, considere o atraso em colocar os bancos de dados online na réplica primária enquanto eles são propagados nas réplicas secundárias. Isso é especialmente verdadeiro para bancos de dados maiores.

A migração para uma instância gerenciada de SQL na camada de serviço Comercialmente Crítico leva mais tempo para ser concluída do que na camada de serviço de uso geral. Após a conclusão da transferência para o Azure, os bancos de dados ficarão indisponíveis até que sejam propagados da réplica primária para as três réplicas secundárias, o que pode levar muito tempo, dependendo do tamanho do seu banco de dados. Quanto maior o banco de dados, mais demorado será o seeding nas réplicas secundárias - até várias horas, potencialmente.

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 o nível de serviço de uso geral e depois atualize para o nível de serviço Comercialmente Crítico durante uma janela de manutenção subsequente. Atualizar seu nível de serviço é uma operação online que mantém seus bancos de dados online até um breve failover como etapa final da operação de atualização.
  • Use o link Instância Gerenciada para uma migração online para uma instância Comercialmente Critico sem precisar esperar que os bancos de dados estejam disponíveis após a transição.

Solução de problemas de LRS

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

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

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

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

  • Há na sua instância gerenciada um banco de dados com o mesmo nome que aquele que você está tentando migrar de sua instância do SQL Server? Resolva esse conflito renomeando um dos bancos de dados.
  • As permissões concedidas pelo token SAS são apenas de Leitura e Lista? 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 sua implantação da 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.

Próximas etapas