Recuperação de banco de dados acelerada

Aplica-se a: SQL Server 2019 (15.x) e versões posteriores Banco de Dados SQL do Azure Banco de dados SQL da InstânciaGerenciada de SQL do Azure no Microsoft Fabric

A recuperação acelerada de banco de dados (ADR) melhora a disponibilidade do banco de dados, especialmente na presença de transações de execução prolongada, ao redesenhar o processo de recuperação do mecanismo de banco de dados.

O ADR foi introduzido no SQL Server 2019 (15.x) e aprimorado no SQL Server 2022 (16.x). A ADR também está disponível no Banco de Dados SQL do Azure, Instância Gerenciada de SQL do Azure, Azure Synapse Analytics (somente no pool de SQL dedicado) e banco de dados SQL no Microsoft Fabric.

Observação

A ADR está sempre habilitada no Banco de Dados SQL do Azure, Instância Gerenciada de SQL do Azure e banco de dados SQL no Fabric.

Este artigo fornece uma visão geral da ADR. Para trabalhar com ADR, examine Gerenciar recuperação acelerada de banco de dados.

Para obter mais informações sobre log de transações e recuperação de banco de dados, confira Guia de arquitetura e gerenciamento do log de transações do SQL Server e Visão geral de restauração e recuperação (SQL Server).

Visão geral

Os principais benefícios do ADR são:

• Recuperação de banco de dados rápida e consistente

  Transações de execução prolongada não afetam o tempo total de recuperação, permitindo uma recuperação rápida e consistente do banco de dados, independentemente do número de transações ativas no sistema ou do tamanho delas.

• Reversão de transação instantânea

  A reversão da transação é instantânea, independentemente do tempo em que a transação está ativa ou do número de atualizações feitas.

• Truncamento agressivo do log

  O log de transações é truncado agressivamente, mesmo na presença de transações ativas de execução prolongada, o que impede que ele cresça fora de controle.

O processo tradicional de recuperação de banco de dados

Sem a ADR, a recuperação do banco de dados segue o modelo de recuperação ARIES e consiste em três fases, que são ilustradas e explicadas em mais detalhes no diagrama a seguir:

• Fase de análise

  O mecanismo de banco de dados executa uma varredura progressiva do log de transações desde o início do último ponto de verificação bem-sucedido (ou o LSN [número de sequência de log] mais antigo da página suja) até o final para determinar o estado de cada transação exatamente no momento em que o mecanismo parou.

• Fase refazer

  O mecanismo de banco de dados executa uma varredura progressiva do log de transações, desde a transação não confirmada mais antiga até o final. Esse processo refaz todas as operações confirmadas para restaurar o banco de dados ao seu estado no momento da falha.

• Fase desfazer

  Para cada transação que estava ativa no momento da falha, o mecanismo do banco de dados percorre o log de trás para frente, desfazendo as operações executadas por essa transação.

• Com o processo tradicional de recuperação de banco de dados, a recuperação após uma falha pode demorar muito tempo se uma transação de execução prolongada estiver ativa.

  O tempo que o mecanismo de banco de dados leva para se recuperar de uma reinicialização inesperada é (aproximadamente) proporcional ao tamanho da transação ativa mais longa no sistema no momento da falha. A recuperação requer uma reversão de todas as transações incompletas. O período de tempo necessário é proporcional para o trabalho que a transação foi executado e o tempo ele esteve ativo.

• Cancelar ou reverter uma transação grande pode demorar, pois essa ação usa a mesma fase de recuperação de desfazer, conforme já descrito.

• O mecanismo de banco de dados não pode truncar o log de transações quando há transações de longa duração porque os registros de log correspondentes são necessários para os processos de recuperação e reversão. Como resultado, o log de transações pode crescer muito e consumir muito espaço de armazenamento.

O processo de recuperação acelerada de banco de dados

A ADR resolve problemas anteriores com o modelo de recuperação tradicional ao redesenhar completamente o processo de recuperação do mecanismo de banco de dados para:

• Faça com que o tempo de recuperação seja constante, pois não há mais necessidade de escanear o log de transações desde o início da transação ativa mais antiga. Com a ADR, o log de transações é processado apenas do último ponto de verificação bem-sucedido em diante (ou do LSN mais antigo da página suja). Como resultado, o tempo de recuperação não é afetado por transações de execução prolongada e é normalmente instantâneo.

• Minimizar o espaço de log de transações necessário, pois não há mais necessidade de reter o log para toda a transação. Como resultado, o log de transações pode ser truncado de forma agressiva à medida que os pontos de verificação e backups ocorrem.

De maneira geral, a ADR obtém uma recuperação rápida de banco de dados por meio do versionamento de todas as modificações físicas do banco de dados e apenas desfazendo as operações não versionadas, que são limitadas e podem ser desfeitas quase instantaneamente. Todas as transações que estavam ativas no momento de uma falha são marcadas como anuladas e, portanto, todas as versões geradas por essas transações podem ser ignoradas por consultas de usuário simultâneas.

O processo de recuperação da ADR tem as mesmas três fases do processo de recuperação tradicional. Como essas fases operam com a ADR é ilustrado no diagrama a seguir:

• Fase de análise

  O processo permanece o mesmo que o modelo de recuperação tradicional, com a adição da reconstrução do fluxo de log secundário (SLOG) e da cópia de registros de log para operações não versionadas.

• Fase refazer

  Dividida em duas subfases

  • Subfase 1

    Refazer do SLOG (da transação não confirmada mais antiga até o último ponto de verificação). Refazer é uma operação rápida, já que pode ser necessário processar apenas alguns registros do SLOG.

  • Subfase 2

    Refazer do log de transações começa no último ponto de verificação bem-sucedido (em vez da transação não confirmada mais antiga).

• Fase desfazer

  A fase de desfazer com a ADR é concluída quase instantaneamente usando SLOG para desfazer operações sem controle de versão e o PVS (repositório de versão persistente) empregando reversão lógica para executar a ação de desfazer com base na versão no nível de linha.

Para obter uma explicação sobre a recuperação acelerada de banco de dados, assista a este vídeo de oito minutos:

Componentes de recuperação ADR

Os quatro componentes principais da ADR são:

• Repositório de versão persistente (PVS)

  O PVS (repositório de versão persistente) é um mecanismo de banco de dados para manter versões de linha no próprio banco de dados, em vez de no repositório de versão tradicional no banco de dados tempdb. O PVS habilita o isolamento de recursos e melhora a disponibilidade de secundários legíveis.

  A PVS armazena versões de linha diretamente nas páginas de dados que estão sendo modificadas ou em uma tabela do sistema separada. Para obter mais informações, consulte Espaço usado pelo PVS (Repositório de versão persistente).

• Reversão lógica

  A reversão lógica é o processo assíncrono responsável por executar a operação desfazer baseada em versão de linha, fornecendo reversão de transação instantânea e desfazer para todas as operações com controle de versão.

  • Mantém o controle de todas as transações anuladas
  • Executa a reversão usando PVS para todas as transações de usuário
  • Libera todos os bloqueios imediatamente após a anulação da transação

• SLOG

  O SLOG é um fluxo de log na memória secundário que armazena registros de log para operações sem controle de versão (tais como invalidação de cache de metadados, aquisições de bloqueio e assim por diante). O SLOG é:

  • de baixo volume e na memória;
  • Mantido no disco durante o processo de ponto de verificação
  • truncado periodicamente conforme as transações são confirmadas;
  • Acelera as ações de refazer e desfazer processando apenas operações sem controle de versão
  • habilita o truncamento agressivo de log de transações ao preservar apenas os registros de log necessários.

• Limpador

  O limpador é o processo assíncrono ativado periodicamente e que limpa as versões de linha obsoletas do PVS.

Cargas de trabalho que se beneficiam da ADR

A ADR é particularmente benéfica para cargas de trabalho que têm:

• Transações de execução prolongada.
• Transações ativas que fazem o log de transações crescer significativamente.
• Longos períodos de indisponibilidade do banco de dados devido à recuperação demorada (como por reinicialização inesperada do serviço ou rollback manual de transações).

Não há suporte para ADR em bancos de dados que usam espelhamento de banco de dados, um recurso de alta disponibilidade mais antigo e preterido.

Práticas recomendadas para ADR

• Evite transações de execução prolongada desnecessárias. Embora a ADR acelere a recuperação de banco de dados mesmo com transações de longa duração, essas transações podem atrasar a limpeza de versões e aumentar o tamanho do PVS.

• Evite transações grandes que incluam operações DDL. A ADR usa o mecanismo de fluxo de log secundário (SLOG) para rastrear as operações DDL usadas na recuperação. O SLOG só é usado enquanto a transação está ativa. O SLOG é um ponto de verificação, portanto, evitar transações grandes que usam o SLOG pode contribuir para o desempenho geral. Esses cenários podem fazer com que o SLOG ocupe mais espaço:

  • Muitos DDLs são executados em uma transação. Por exemplo, em uma transação, criar e remover rapidamente tabelas temporárias.
  • Uma tabela tem um número muito grande de partições/índices que são modificados. Por exemplo, uma operação DROP TABLE nessa tabela exigiria uma grande reserva de memória SLOG, o que atrasaria a truncação do log de transações e atrasaria as operações de desfazer/refazer. Como solução alternativa, remova os índices individual e gradualmente e, em seguida, remova a tabela.

  Para obter mais informações sobre o SLOG, confira componentes de recuperação da ADR.

• Evite ou reduza transações anuladas desnecessárias. Uma alta taxa de anulação de transações pressiona o limpador de PVS e reduz o desempenho da ADR. As anulações podem vir de uma alta taxa de bloqueios, chaves duplicadas, violações de restrição ou tempos limite de consulta. A DMV sys.dm_tran_aborted_transactions mostra todas as transações anuladas na instância do mecanismo de banco de dados. A coluna nested_abort indica que a transação foi concluída, embora haja partes anuladas (pontos de salvamento ou transações aninhadas) que também podem atrasar o processo de limpeza de PVS.

• Verifique se há espaço suficiente no banco de dados para considerar o uso do PVS. Se o banco de dados não tiver espaço suficiente para o crescimento do PVS, a ADR poderá falhar ao gerar versões, fazendo com que as instruções DML falhem.

• Quando a ADR está habilitado com cargas de trabalho intensivas em gravação, a taxa de geração do log de transações pode aumentar substancialmente, pois as versões de linha gravadas no PVS são registradas. Isso pode aumentar o tamanho dos backups de log de transações.

• Ao usar replicação transacional, replicação de instantâneo ou captura de dados de alterações (CDC), o comportamento agressivo de truncamento de log da ADR é desabilitado para permitir que o leitor de log recolha alterações do log de transações. Verifique se o log de transações é suficientemente grande.

  Se estiver usando CDC ou feed de alterações no Banco de Dados SQL do Azure, talvez seja necessário aumentar sua camada de serviço ou tamanho da computação para garantir que haja espaço suficiente no log de transações para as necessidades de todas as suas cargas de trabalho. Da mesma forma, na Instância Gerenciada de SQL do Azure, talvez seja necessário aumentar o tamanho máximo de armazenamento da instância.

• Para o SQL Server, isole o repositório de versões PVS em um grupo de arquivos em um armazenamento de nível superior, como SSD de alto desempenho, SSD avançado ou Memória Persistente (PMEM), também conhecido como Memória de Classe de Armazenamento (SCM). Para obter mais informações, confira Alterar a localização do PVS para um grupo de arquivos diferente.

• Para o SQL Server, monitore entradas com PreallocatePVS no log de erros. Se houver entradas PreallocatePVS, talvez seja necessário aumentar a capacidade de pré-alocação de páginas pela ADR usando uma tarefa em segundo plano. A pré-alocação de páginas PVS em segundo plano melhora o desempenho da ADR ao reduzir as alocações de PVS no primeiro plano, que são mais dispendiosas. Você pode usar a configuração do servidor ADR Preallocation Factor para aumentar essa quantidade. Para mais informações, confira Configuração do servidor: fator de pré-alocação de ADR.

• Para o SQL Server 2022 (16.x) e versões posteriores, considere habilitar a limpeza de PVS com múltiplas threads caso o desempenho do limpador de thread único seja insuficiente. Para obter mais informações, confira Configuração do servidor: quantidade de threads do limpador de ADR.

• Se você observar problemas, como alto uso de espaço no banco de dados pelo PVS ou limpeza lenta do PVS, confira Monitorar e solucionar problemas de recuperação acelerada do banco de dados.

Melhorias da ADR no SQL Server 2022

Há vários aprimoramentos para lidar com o armazenamento de PVS (repositório de versão persistente) e melhorar a escalabilidade geral. Para obter mais informações sobre os novos recursos do SQL Server 2022 (16.x), confira Novidades no SQL Server 2022.

As mesmas melhorias também estão disponíveis no Banco de Dados SQL do Azure, na Instância Gerenciada de SQL do Azure, no Azure Synapse Analytics (apenas no pool de SQL dedicado) e no Banco de Dados SQL no Microsoft Fabric.

• Limpeza de transações do usuário

  Limpe as páginas que não podem ser limpas pelo processo regular devido à falha na aquisição de bloqueio.

  Esse recurso permite que as transações do usuário executem a limpeza em páginas que não puderam ser resolvidas pelo processo de limpeza regular devido a conflitos de bloqueio no nível da tabela. Esse aprimoramento ajuda a garantir que o processo de limpeza da ADR não falhe indefinidamente devido a cargas de trabalho do usuário que não podem adquirir bloqueios no nível da tabela.

• Reduzir o uso de memória para o rastreador de página PVS

  Essa melhoria rastreia as páginas do PVS no nível de extensão, a fim de reduzir o volume de memória necessário para manter as páginas com controle de versão.

• Melhorias no limpador PVS

  O limpador de PVS melhorou a eficiência da limpeza de versões, aprimorando a forma como o mecanismo de banco de dados acompanha e registra as versões de linha para transações anuladas. Isso leva a melhorias no uso de memória e armazenamento.

• Repositório de Versão Persistente (PVS) no nível de transação

  Essa melhoria permite que a ADR limpe versões que pertencem a transações confirmadas, independentemente de haver transações anuladas no sistema. Com essa melhoria, as páginas PVS podem ser desalocadas, mesmo que a limpeza não consiga concluir uma varredura bem-sucedida para reduzir o mapa de transações anuladas.

  O resultado dessa melhoria é a redução do crescimento do PVS, mesmo que a limpeza do PVS seja lenta ou falhe.

• Limpeza de versão com vários threads

  No SQL Server 2019 (15.x), o processo de limpeza é de thread único em uma instância do mecanismo de banco de dados.

  A partir do SQL Server 2022 (16.x), é suportada a limpeza de versões com múltiplos threads. Isso permite que vários bancos de dados na mesma instância do mecanismo de banco de dados sejam limpos em paralelo ou que um único banco de dados seja limpo mais rapidamente. Para obter mais informações, confira Configuração do servidor: quantidade de threads do limpador de ADR.

  Um novo evento estendido, tx_mtvc2_sweep_stats, foi adicionado para o monitoramento do limpador de versão multi-threaded do PVS da ADR.

Conteúdo relacionado

• Gerenciar Recuperação Acelerada de Banco de Dados
• Monitorar e solucionar problemas de recuperação acelerada de banco de dados