Partilhar via

Migre bases de dados do SQL Server usando o Log Replay Service - Azure SQL Managed Instance

Aplica-se a: Azure SQL Managed Instance

Este artigo explica como migrar bases de dados SQL Server para Azure SQL Managed Instance usando Log Replay Service (LRS). O LRS é um serviço cloud gratuito para migrações de Azure SQL Managed Instance, construído com base na tecnologia de log-shipping do SQL Server. Aprenda o processo completo, desde os pré-requisitos até a substituição, incluindo as práticas recomendadas para uma migração bem-sucedida do banco de dados.

Observação

Agora é possível migrar a sua instância SQL Server habilitada pelo Azure Arc para o Azure SQL Managed Instance diretamente através do portal Azure. Para saber mais, consulte Migrar para Azure SQL Managed Instance.

As seguintes fontes são suportadas:

  • SQL Server em Máquinas Virtuais
  • Amazon EC2 (nuvem de computação elástica)
  • Amazon RDS (Serviço de Base de Dados Relacional) para SQL Server
  • Google Compute Engine
  • Cloud SQL para SQL Server - GCP (Google Cloud Platform)

Pré-requisitos

Importante

  • Antes de migrar bases de dados para o nível de serviço Business Critical, considere estas limitações, que não se aplicam ao nível de serviço de Uso Geral.
  • Não é possível usar 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 oferece suporte ao acesso somente leitura a bancos de dados durante a migração.
  • Após a conclusão da migração, o processo de migração é final e não pode ser retomado com backups diferenciais adicionais.

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

SQL Server

Certifique-se de que cumpre os seguintes requisitos para o SQL Server:

  • Versões do SQL Server de 2008 a 2022.
  • A tua base de dados SQL Server está a usar o modelo de recuperação completo (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 (sem divisão para um ficheiro de log de transações).
  • Para SQL Server versões de 2008 a 2016, faça uma cópia de segurança localmente e carrega manualmente para a sua conta Armazenamento de Blobs do Azure.
  • Para SQL Server 2016 e posteriores, pode levar diretamente a sua cópia de segurança para a sua conta Armazenamento de Blobs do Azure.
  • Embora não seja necessário ter CHECKSUM habilitado para backups, é altamente recomendável evitar a migração involuntária de um banco de dados corrompido e para operações de restauração mais rápidas.
  • Qualquer versão do Windows Server é suportada com base na compatibilidade da versão SQL Server.
  • Para SQL Server 2019 e posteriores, a recuperação acelerada da base de dados deve estar ativada, com a memória de versões persistentes definida para PRIMARY. Para mais informações, consulte Problemas conhecidos após migração para SQL Managed Instance neste artigo.
  • Para usar o Service Broker numa base de dados migrada para Azure SQL Managed Instance, o Service Broker deve estar ativado na base de dados de origem antes da migração. Para mais informações, consulte Problemas conhecidos após migração para SQL Managed Instance neste artigo.

Azure

Certifique-se de que cumpre os seguintes requisitos para o Azure:

  • PowerShell Az.SQL módulo versão 4.0.0 ou posterior (instalado ou acedido através de Azure Cloud Shell).
  • CLI do Azure versão 2.42.0 ou posterior (instalado).
  • Um contentor de armazenamento Blob do Azure provisionado.
  • Um token de segurança de assinatura de acesso partilhado (SAS) com permissões Read e List geradas para o contentor Armazenamento de Blobs, ou uma identidade gerida que pode aceder ao contentor. 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 dentro de uma pasta separada em uma conta de armazenamento usando uma estrutura de arquivo simples (obrigatório). Não há suporte para aninhamento de pastas dentro de pastas de banco de dados.

Permissões Azure RBAC

Executar o LRS através dos clientes fornecidos requer um dos seguintes papéis de controlo de acesso baseado em papéis (RBAC) no Azure:

Melhores práticas

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

  • Divida backups completos e diferenciais em vários arquivos, em vez de usar um único arquivo.
  • Habilite a compactação de backup para ajudar na velocidade de transferência da rede.
  • Usa o Cloud Shell para correr scripts PowerShell ou CLI, porque estará sempre atualizado para usar 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 hora específicos fora da janela de migração para evitar atrasar ou interromper a migração.
  • Planeje concluir um único trabalho de migração LRS dentro de um máximo de 30 dias. Após a expiração deste período de tempo, o trabalho LRS é automaticamente cancelado.
  • Para evitar a migração involuntária de um banco de dados corrompido e para uma restauração mais rápida do banco de dados, habilite CHECKSUM quando estiver fazendo backups. Embora a SQL Managed Instance realize uma verificação básica de integridade em backups sem CHECKSUM, não é garantido a deteção de todas as formas de corrupção. Fazer backups com CHECKSUM é a única forma de garantir que o backup restaurado em SQL Managed Instance não está corrompido. A verificação de integridade básica em backups sem CHECKSUM aumenta o tempo de restauração de um banco de dados.
  • Ao migrar para a camada de serviço Business Critical, leve em conta 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 bases 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 Business Critical, ou usar o link Managed Instance para migrar os seus dados.
  • Carregar milhares de arquivos de banco de dados para restaurar 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.
  • Para minimizar o tempo de substituição e reduzir o risco de falha, certifique-se de que seu último backup seja o menor possível.

Configurar uma janela de manutenção

As atualizações do sistema para SQL Managed Instance têm prioridade sobre as migrações de bases de dados em andamento.

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

  • Na camada de serviço de uso geral, todas as migrações LRS pendentes são suspensas e retomadas somente após a aplicação da atualização. Esse comportamento do sistema pode prolongar o tempo de migração, especialmente para bancos de dados grandes.
  • Na camada de serviço Business Critical, todas as migrações LRS pendentes são canceladas e reiniciadas automaticamente após a aplicação da atualização. Esse comportamento do sistema pode prolongar o tempo de migração, especialmente para bancos de dados grandes.

Para obter um tempo previsível para migrações de banco de dados, considere configurar uma janela de manutenção 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 tempo da janela de manutenção designada. Por exemplo, para uma migração que começa na segunda-feira, configure sua janela de manutenção personalizada no domingo para permitir o máximo de tempo para concluir a migração.

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

Observação

Embora uma janela de manutenção controle a previsibilidade de atualizações de planeadas, não garante que falhas não planeadas ou atualizações de segurança não ocorram. Um failover não planejado ou um patch de segurança (que tem precedência sobre todas as outras atualizações) ainda podem interromper a migração.

Migrar vários bancos de dados

Se estiver a migrar várias bases de dados usando o mesmo contentor do Armazenamento de Blobs do Azure, deve colocar os ficheiros de backup de diferentes bases de dados em pastas separadas dentro do contentor. Todos os arquivos de backup de um único banco de dados devem 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 aninhamento de pastas dentro de pastas de banco de dados.

Aqui está um exemplo de uma estrutura de pastas dentro de um contentor Armazenamento de Blobs do Azure, uma estrutura que é necessária para migrar múltiplas bases 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

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. Para criar uma nova conta de armazenamento e um contêiner de blob dentro da conta de armazenamento:

  1. Crie uma conta de armazenamento.
  2. Crie um contêiner de blob dentro da conta de armazenamento.

Configurar o armazenamento do Azure atrás de um firewall

O uso de armazenamento Blob do Azure protegido por um firewall é suportado, mas requer configuração adicional. Para permitir o acesso de leitura/escrita ao Armazenamento do Azure com o Azure Firewall ativado, tens de adicionar a sub-rede da instância gerida SQL às regras de firewall da rede virtual para a conta de armazenamento, usando a delegação da sub-rede MI e o endpoint do serviço de armazenamento. A conta de armazenamento e a instância gerenciada devem estar na mesma região ou em duas regiões emparelhadas.

Se o seu armazenamento Azure estiver atrás de um firewall, poderá ver a seguinte mensagem no registo de erros da instância gerida SQL:

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

Isso gera um e-mail que te notifica de que a auditoria para a instância gerida do SQL está a falhar ao gravar os registos de auditoria na conta de armazenamento. Se vir este erro ou receber este e-mail, siga os passos nesta secção para configurar a firewall.

Para configurar o firewall, siga estas etapas:

  1. Aceda à sua instância gerida SQL no portal Azure e selecione a sub-rede para abrir a página de Sub-redes.

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

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

    Captura de ecrã da página da Instância Gerida SQL da Sub-rede do portal Azure, com a sub-rede selecionada.

  3. Em Delegação de sub-rede, escolha Microsoft.Sql/managedInstances da lista suspensa Delegar sub-rede a um serviço. Espere cerca de uma hora para que as permissões se propaguem e, depois, em Service endpoints, escolha Microsoft.Storage do menu suspenso Services.

    Captura de ecrã da página de configuração da subrede de instância gerida SQL do portal Azure.

  4. De seguida, vá à sua conta de armazenamento no portal Azure, selecione Redes em Segurança + redes e depois escolha o separador Firewalls e redes virtuais.

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

    Captura de ecrã da página Conta de Armazenamento de Rede do portal Azure, com Adicionar rede virtual existente selecionado.

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

Autentique na sua conta Armazenamento de Blobs

Use um token SAS ou uma identidade gerida para aceder à sua conta Armazenamento de Blobs do Azure.

Advertência

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

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

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

Pode usar uma conta Armazenamento de Blobs do Azure como armazenamento intermédio para ficheiros de backup entre a sua instância SQL Server e a implementação da SQL Managed Instance. Gere um token de autenticação SAS para LRS apenas com permissões de Leitura e Listagem. O token permite que o LRS aceda à sua conta Armazenamento de Blobs e utiliza os ficheiros de backup para os restaurar na sua instância gerida.

Siga estas etapas para gerar o token:

  1. Vá ao Centro de Armazenamento no portal do Azure e selecione a sua conta de armazenamento.

  2. Em Segurança + rede, selecione Assinatura de acesso Partilhada para abrir o painel de assinatura de Acesso Partilhado .

  3. No painel de assinatura de acesso partilhado , configure as definições para gerar um token SAS para LRS. Use as seguintes orientações para configurar as definições:

    1. Serviços permitidos: Blob e File.

    2. Tipos de recursos permitidos: Serviço.

    3. Permissões: Apenas Ler e Listar .

      Importante

      Não selecione outras permissões. Se o fizer, o LRS não será iniciado. Este requisito de segurança é intencional.

    4. Permissões de versionamento de blob: Opcional

    5. Permissões permitidas para o índice de blobs: Podem ser desativadas.

    6. Selecione o fuso horário para o token: UTC ou a sua hora local.

      Importante

      O fuso horário do token e sua instância gerenciada podem não corresponder. Certifique-se de que o token SAS tem a validade de tempo apropriada, levando em consideração os fusos horários. Para levar em conta as diferenças de fuso horário, defina o valor de validade De bem antes do início da janela de migração e o valor Para bem depois de esperar que a migração termine.

    7. Selecione Gerar SAS e cadeia de conexão para gerar o token:

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

    A autenticação SAS é gerada com a validade de tempo especificada.

  4. Copie o valor fornecido no campo Blob Service SAS URL, que é a versão URI do token que precisa para iniciar o serviço LRS.

Observação

O uso de tokens SAS criados com permissões que foram definidas definindo uma política de acesso armazenado não é suportado no momento. Siga as instruções neste procedimento para especificar manualmente permissões de leitura e de lista para o token SAS.

Copiar parâmetros do token SAS

Aceda à sua conta Armazenamento de Blobs do Azure usando um token SAS ou uma identidade gerida.

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

Captura de tela do URI de exemplo para um token SAS gerado para o Log Replay Service.

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

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

Copie os parâmetros da seguinte maneira:

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

  2. Copie a segunda parte do token, após o ponto de interrogação (?) até o final da cadeia de caracteres. Usa-o como parâmetro StorageContainerSasToken no PowerShell ou como CLI do Azure quando estiveres a iniciar o LRS.

Observação

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

Valide o acesso ao armazenamento da instância gerida

Valide que a sua instância gerida pode aceder à sua conta Armazenamento de Blobs.

Primeiro, carregue qualquer backup da base de dados, como full_0_0.bak, para o seu contentor de Armazenamento de Blobs do Azure.

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

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

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

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 pode aceder ao contentor, pode começar a carregar os seus backups para a sua conta Armazenamento de Blobs. Pode escolher entre:

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

Copie backups existentes para a sua conta Armazenamento de Blobs

Se estiver numa versão anterior do SQL Server, ou se o seu ambiente não suportar backups diretos para uma URL, faça os seus backups na sua instância do SQL Server como normalmente faria e depois copie-os para a sua conta do Armazenamento de Blobs.

Fazer backups numa instância do SQL Server

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

Para fazer manualmente backups completos, diferenciais e de log do seu banco 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 usando o LRS, pode usar 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.

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

Se estiver numa versão suportada do SQL Server (começando com SQL Server 2012 SP1 CU2 e SQL Server 2014), e as suas políticas corporativas e de rede o permitirem, pode fazer backups do SQL Server diretamente para a sua conta Armazenamento de Blobs usando o SQL Server nativo BACKUP TO URL. Se conseguires usar BACKUP TO URL, não precisas de levar backups para armazenamento local e carregá-los na tua conta Armazenamento de Blobs.

Quando fazes backups nativos diretamente para a tua conta de Armazenamento Blob, tens de autenticar-te na conta de armazenamento.

Use o seguinte comando para criar uma credencial que importe o token SAS para a sua 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 para trabalhar com tokens SAS, consulte o tutorial Use Armazenamento de Blobs do Azure com SQL Server.

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

O exemplo a seguir leva um backup de banco de dados completo para uma 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 uma 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 uma 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;

Inicie sessão no Azure e selecione uma subscrição

Use o seguinte cmdlet do PowerShell para iniciar sessão no Azure:

Login-AzAccount

Selecione a assinatura onde sua instância gerenciada reside usando o seguinte cmdlet do PowerShell:

Select-AzSubscription -SubscriptionId <subscription ID>

Iniciar a migração

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

Quando você usa o modo de preenchimento automático, a migração é concluída automaticamente quando o último dos arquivos de backup especificados tiver sido restaurado. Esta opção exige que toda a cadeia de backup esteja disponível antecipadamente e carregada na sua conta Armazenamento de Blobs. Ele não permite adicionar novos arquivos de backup enquanto a migração está em andamento. Esta opção requer o comando start para especificar o nome do arquivo do último arquivo de backup. Recomendamos este modo para cargas de trabalho passivas para as quais a recuperação de dados não é necessária.

Quando usas o modo contínuo, o serviço escaneia continuamente a pasta Armazenamento de Blobs do Azure e restaura quaisquer ficheiros de backup novos que sejam adicionados durante a migração. A migração só termina após a mudança manual ter sido solicitada. Você precisa usar a migração em modo contínuo quando não tiver toda a cadeia de backup com antecedência e quando planeja adicionar novos arquivos de backup depois que a migração estiver em andamento. Recomendamos esse modo para cargas de trabalho ativas para as quais a recuperação de dados é necessária.

Planeje concluir um único trabalho de migração LRS dentro de um máximo de 30 dias. Quando esse tempo expira, o trabalho LRS é automaticamente cancelado.

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 base de dados, apontando para o caminho completo do URI do contentor do Armazenamento de Blobs do Azure e para a pasta individual da base 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

Certifique-se de que toda a cadeia de backups foi carregada para a 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 em modo de autocompletamento, use comandos PowerShell ou CLI do Azure. Especifique o último nome do arquivo de backup usando o parâmetro -LastBackupName. Após concluir a restauração do último ficheiro de backup especificado, o serviço inicia automaticamente um corte.

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

Importante

  • Certifique-se de que toda a cadeia de backup foi carregada para a sua conta Armazenamento de Blobs do Azure antes de iniciar a migração em modo de autocompletamento. Esse modo não permite que novos arquivos de backup sejam adicionados enquanto a migração está em andamento.

  • Certifique-se de que especificou o último ficheiro de cópia de segurança corretamente e de que não carregou mais ficheiros depois dele. Se o sistema detetar mais arquivos de backup além do último arquivo de backup especificado, a migração falhará.

O exemplo do PowerShell a seguir 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 seguinte exemplo de CLI do Azure inicia o LRS em modo de autocompletar 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 em modo contínuo

Certifique-se de que carregou a sua cadeia de backup inicial para a sua conta Armazenamento de Blobs do Azure.

Importante

Depois de iniciar o LRS no modo contínuo, você poderá adicionar novos backups de log e diferenciais à sua conta de armazenamento até a transferência manual. Após a mudança manual ser iniciada, nenhum arquivo diferencial adicional poderá ser adicionado ou restaurado.

O exemplo do PowerShell a seguir 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 seguinte exemplo de CLI do Azure inicia o LRS em 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 para o trabalho de migração

Os clientes PowerShell e CLI do Azure que iniciam LRS em modo contínuo são síncronos. Neste modo, o PowerShell e a CLI do Azure aguardam que a resposta da API reporte sucesso ou falha antes de iniciarem o trabalho.

Durante essa espera, o comando não retornará o controle para o prompt de comando. Se você estiver criando scripts para a experiência de migração e precisar que o comando LRS start devolva o controle imediatamente para continuar com o restante do script, 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, um objeto de trabalho retorna imediatamente, mesmo que o trabalho demore muito tempo para ser concluído. Você pode continuar a trabalhar na sessão sem interrupção enquanto a tarefa está a ser executada. Para obter detalhes sobre como executar o PowerShell como um trabalho em segundo plano, consulte a documentação do PowerShell Start-Job.

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

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

Monitorar o progresso da migração

Az.SQL 4.0.0 e posteriores fornecem um relatório de progresso detalhado. Revise os detalhes da restauração do banco de dados gerido - Obtenha para uma saída de exemplo.

Para monitorar o progresso da migração contínua por meio do PowerShell, use o seguinte comando:

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

Para monitorizar o progresso da migração em curso através da CLI do Azure, utilize o seguinte comando:

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

Para rastrear detalhes adicionais sobre um pedido falhado, use o comando PowerShell Get-AzSqlInstanceOperation ou use o comando CLI do Azure az sql mi op show.

Interromper a migração (opcional)

Se precisares de parar a migração, usa o PowerShell ou o CLI do Azure. Interromper a migração exclui o banco de dados de restauração em sua instância gerenciada, portanto, não será possível retomar a migração.

Para interromper 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 através da 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 iniciar o LRS em modo contínuo, certifique-se de que a sua aplicação e a carga de trabalho do SQL Server foram paradas para evitar que novos ficheiros de backup sejam gerados. Certifique-se de que o último backup da sua instância do SQL Server foi carregado para a sua conta do Armazenamento de Blobs do Azure. Monitore o progresso da restauração em sua instância gerenciada e verifique se o último backup de log-tail foi restaurado.

Quando o último backup de log-tail tiver sido restaurado em sua instância gerenciada, inicie a substituição manual para concluir a migração. Após a conclusão da mudança, o banco de dados torna-se disponível para leitura e gravação na instância gerida.

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

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

Para completar o processo de migração em modo contínuo LRS através da 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:

  • Não é possível usar 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, as bases de dados que estão a ser migradas não podem ser usadas para acesso apenas de leitura na SQL Managed Instance.
  • Após a conclusão da migração, o processo de migração é final e não pode ser retomado com backups diferenciais adicionais.
  • Somente arquivos de .bak, .loge .diff de banco de dados são suportados pelo LRS. Os ficheiros Dacpac e bacpac não são suportados.
  • 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 migrações fora da janela de manutenção agendada.
  • Backups de banco de dados feitos sem CHECKSUM:
    • pode potencialmente migrar bancos de dados corrompidos.
    • demorar mais tempo a restaurar do que os backups de bases de dados com CHECKSUM habilitada.
  • O token de assinatura de acesso partilhado (SAS) que o LRS utiliza deve ser gerado para todo o contentor do Armazenamento de Blobs do Azure, e deve ter permissões Read e List. Por exemplo, se concederes permissões de Read, Liste Write, o LRS falha ao iniciar devido à permissão extra de Write.
  • Não há suporte para o uso de tokens SAS criados com permissões configuradas através de uma 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.
  • Deve colocar ficheiros de backup para diferentes bases de dados em pastas separadas na conta Armazenamento de Blobs, numa estrutura de ficheiros planos. Não há suporte para aninhamento de pastas dentro de pastas de banco de dados.
  • Se estiveres a usar o modo de autocompletar, toda a cadeia de backup tem de estar disponível antecipadamente na conta do 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 base de dados que aponta para o caminho URI completo que contém uma pasta de base de dados individual.
  • O caminho do URI de backup, o nome do contêiner ou os nomes das pastas não podem conter backup ou Backup , pois 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 oferece 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 de Propósito Geral e até 500 bancos de dados totais na camada de serviço de Finalidade Geral de Próxima Geração .
  • O LRS suporta 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 dentro da mesma assinatura.
  • Um único trabalho LRS pode ser executado por um máximo de 30 dias, após os quais será automaticamente cancelado.
  • Embora seja possível usar uma conta Armazenamento do Azure atrás de um firewall, é necessária uma configuração adicional, e a conta de armazenamento e a instância gerida devem estar na mesma região ou em duas regiões emparelhadas. Consulte Configuração do firewall para obter mais informações.
  • O número máximo de bancos de dados que você pode restaurar em paralelo é de 150 por assinatura única. Em alguns casos, é possível aumentar esse limite abrindo um ticket de suporte.
  • Carregar milhares de arquivos de banco de dados para restaurar 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.
  • Existem dois cenários, no início e no fim do processo de migração, em que uma migração é abortada se ocorrer um failover, e o trabalho de migração tem de ser reiniciado manualmente do início à medida que a base de dados é retirada do SQL Managed Instance:
    • Se ocorrer um failover quando o primeiro backup completo da base de dados estiver em processo de restauração para a SQL Managed Instance quando o trabalho de migração é iniciado, então o trabalho de migração deve ser reiniciado manualmente desde o início.
    • Se ocorrer um failover após o início da interrupção da migração, o processo de migração deverá ser reiniciado manualmente desde o início. Certifique-se de que o último arquivo de backup seja o menor possível para minimizar o tempo de substituição e reduzir o risco de failover durante o processo de substituição.
  • Se recuperação acelerada da base de dados estiver desativada no seu código-fonte SQL Server 2019 e instâncias posteriores, já não poderá ativá-la após migrar para Azure SQL Managed Instance. Além disso, 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.
  • Se o Service Broker estiver desativado na SQL Server de origem da instância, não pode usar o Service Broker na instância SQL gerida de destino após a migração.

Observação

Se precisar que uma base de dados seja acessível apenas leitura durante a migração, com um período de tempo muito mais longo para realizar a migração e com tempo de inatividade mínimo, considere usar a funcionalidade Overview of the Managed Instance link como solução recomendada de migração.

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 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 sincronizados com réplicas secundárias da camada de serviço Crítica para Negócios. As soluções alternativas estão listadas na secção de transição mais longa.
  • A migração é reiniciada automaticamente desde o início se a migração 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ó são aplicáveis ao migrar para a camada de serviço Business Critical e não para a camada de serviço de uso geral .

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. Isso é especialmente verdadeiro para bancos 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. Após a transição para o Azure ser concluída, as bases de dados ficam indisponíveis até serem inicializadas da réplica primária para as três réplicas secundárias, o que pode demorar bastante tempo dependendo do tamanho das bases 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 os bancos de dados estejam disponíveis assim que a substituição for concluída, considere as seguintes soluções alternativas:

  • Migre primeiro para a camada de serviço Geral e, em seguida, atualize para a camada de serviço Business Critical. 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.

Problemas conhecidos após a migração para SQL Managed Instance

Considere os seguintes problemas conhecidos após migrar para o Azure SQL Managed Instance:

Falhas nas operações de restauro após a migração para o SQL Managed Instance.

Se migrar uma base de dados para uma Azure SQL Managed Instance a partir de uma versão do SQL Server 2019 e posteriores com accelerated database recovery ativado, mas configurado com o armazenamento de versões persistente (PVS) definido para algo diferente do grupo de ficheiros PRIMARY, poderão ocorrer falhas nas operações de restauro na instância SQL gerida de destino.

Para contornar este problema, certifique-se de definir o armazenamento de versões persistente (PVS) para PRIMARY na base de dados SQL Server de origem antes de migrar para SQL Managed Instance. Se já migrou a base de dados sem definir o PVS para PRIMARY, pode defini-lo na base de dados SQL Server de origem e depois migrá-la novamente para uma Instância de SQL Gerida.

Não é possível usar a recuperação acelerada da base de dados após migrar para o SQL Managed Instance

A partir de SQL Server 2019, se migrar uma base de dados para Azure SQL Managed Instance e a base de dados de origem tiver recuperação acelerada da base de dados desativada, não pode usar a recuperação acelerada da base de dados na instância SQL gerida de destino.

Para contornar este problema, certifique-se de que ativa a recuperação acelerada da base de dados na base de dados de origem do SQL Server antes de a migrar para o SQL Managed Instance. Se já migrou a base de dados sem ativar a recuperação acelerada da base de dados, pode ativá-la na base de dados SQL Server de origem e depois remigrar a base de dados para uma instância gerida em SQL.

O SQL Server 2017 e versões anteriores não suportam recuperação acelerada de bases de dados, por isso este problema não se aplica a bases de dados migradas dessas versões do SQL Server.

Não é possível usar o Service Broker após migrar para a SQL Managed Instance

Se migrar uma base de dados para Azure SQL Managed Instance e o Service Broker estiver desativado na base de dados de origem, não pode usar o Service Broker na instância SQL gerida de destino.

Para contornar este problema, certifique-se de ativar o Service Broker na base de dados SQL Server de origem antes de o migrar para SQL Managed Instance. Se já migrou a base de dados sem ativar o Service Broker, pode ativá-la na base de dados SQL Server de origem e depois remigrar a base de dados para o SQL Managed Instance.

Solucionar problemas do LRS

Depois de iniciar o LRS, utilize um dos seguintes cmdlets de monitorização para verificar o estado da operação em curso:

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

Para verificar os detalhes sobre uma operação com falha:

Se o LRS não conseguir iniciar após algum tempo e você receber um erro, verifique os problemas mais comuns:

  • Uma base de dados existente na sua instância gerida tem o mesmo nome daquela que está a tentar migrar da sua instância do SQL Server? Resolva esse conflito renomeando um dos bancos de dados.
  • As permissões concedidas para o token SAS são apenas para Ler e Listar ? 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 que se parece com sv=2020-02-10...?
  • O tempo de validade do token SAS é apropriado para a janela de tempo de iniciar e concluir a migração? Podem haver descompassos devido aos diferentes fusos horários usados para a implementação do SQL Managed Instance e do token SAS. Tente regenerar o token SAS e estender a validade do token para o período de tempo antes e depois da data atual.
  • 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 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, foi especificado um nome de arquivo válido para o último arquivo de backup?
  • O caminho do URI de backup contém palavras-chave backup ou backups? Renomeie o contêiner ou pastas que estão usando backup ou backups pois são palavras-chave reservadas.

Conteúdo relacionado

  • Last updated on