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 ADR (recuperação acelerada de banco de dados) melhora a disponibilidade do banco de dados, especialmente na presença de transações de execução prolongada, redesenhando 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, na Instância Gerenciada de SQL do Azure, no Azure Synapse Analytics (somente no pool de SQL dedicado) e no Banco de Dados SQL no Microsoft Fabric.

Nota

A ADR está sempre habilitada no Banco de Dados SQL do Azure, na Instância Gerenciada de SQL do Azure e no 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 o log de transações e a recuperação de banco de dados, consulte guia de arquitetura e gerenciamento de 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 longa não afetam o tempo de recuperação geral, permitindo uma recuperação de banco de dados rápida e consistente, independentemente do número de transações ativas no sistema ou seu tamanho.

• 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 que foram 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 de recuperação de banco de dados tradicional

Sem a ADR, a recuperação de banco de dados segue o modelo de recuperação do ARIES e consiste em três fases, que são ilustradas e explicadas com 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 refazerá todas as operações confirmadas para restaurar o banco de dados para 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 de recuperação de banco de dados tradicional, a recuperação após uma falha pode levar muito tempo se uma transação de longa execução estiver ativa.

  O tempo para o mecanismo de banco de dados 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 execução prolongada, pois os registros de log correspondentes dessas transações 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 redesenhando 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 longa e normalmente é instantâneo.

• Minimize o espaço de log de transações necessário, pois não há mais a necessidade de manter o log de 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 de ADR tem as mesmas três fases que o processo de recuperação tradicional. A forma como essas fases operam com a ADR é ilustrada 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 do ú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 da recuperação acelerada do banco de dados, assista a este vídeo de oito minutos:

Componentes de recuperação ADR

Os quatro componentes principais da ADR são:

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

  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.

• 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 com que o log de transações aumente 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).

Práticas recomendadas para a 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 SLOG (fluxo de log secundário) para acompanhar as operações de 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 assuma 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 modificados. Por exemplo, uma operação de DROP TABLE nessa tabela exigiria uma grande reserva de memória SLOG, o que atrasaria o truncamento do log de transações e também as operações de desfazer/refazer. Como solução alternativa, solte os índices individualmente e gradualmente e, em seguida, solte a tabela.

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

• Impedir ou reduzir 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 de PVS. Se o banco de dados não tiver espaço suficiente para o PVS crescer, a ADR poderá não conseguir gerar versões, causando a falha das instruções DML.

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

• Quando você usa replicação transacional, replicação de instantâneo ou CDA (captura de dados de alterações), o comportamento agressivo de truncamento de log da ADR é desabilitado para permitir que o leitor de log colete alterações do log de transações. Verifique se o log de transações é suficientemente grande.

  No Banco de Dados SQL do Azure, talvez seja necessário aumentar a camada de serviço ou o tamanho da computação para garantir que o espaço de log de transações suficiente esteja disponível 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, consulte Alterar o local da 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 por PVS ou limpeza lenta de PVS, confira Solucionar problemas de recuperação acelerada de banco de dados.

Melhorias de 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 novos recursos do SQL Server 2022 (16.x), consulte Novidades no SQL Server 2022.

Os mesmos aprimoramentos 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 (somente 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 a uma falha de 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 acompanha as páginas de PVS no nível de extensão para reduzir o volume de memória necessário para manter páginas com controle de versão.

• Melhorias no limpador de 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.

• PVS (repositório de versão persistente) no nível da transação

  Esse aprimoramento 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 de PVS mesmo que a limpeza de PVS seja lenta ou falhe.

• Limpeza de versão com vários threads

  No SQL Server 2019 (15.x), o processo de limpeza é encadeado individualmente 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 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 monitoramento do limpador de versão multi-threaded de PVS da ADR.

Conteúdo relacionado

• Gerenciar Recuperação Acelerada de Banco de Dados
• Solucionar problemas de recuperação acelerada de banco de dados