Recuperação acelerada de banco de dados

Aplica-se a: SQL Server 2019 (15.x) e versões posteriores Banco de Dados SQL do AzureInstância Gerenciada de SQL do AzureAzure Synapse Analytics

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, remodelando o processo de recuperação do mecanismo de banco de dados do SQL.

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 para bancos de dados no Banco de Dados SQL do Azure, na Instância Gerenciada de SQL do Azure e no SQL do Azure Synapse. O ADR está habilitado por padrão no Banco de Dados SQL e na Instância Gerenciada de SQL e não pode ser desabilitado. Para obter mais informações sobre ADR no SQL do Azure, confira Recuperação Acelerada de Banco de Dados no SQL do Azure.

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

Visão geral

Os principais benefícios do ADR são:

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

  Com ADR, as transações de execução prolongada 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 do tamanho delas.

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

  Com ADR, a reversão de transação é instantânea, independentemente do tempo em que a transação esteve ativa ou do número de atualizações que ela realizou.

• Truncamento agressivo do log

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

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

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

• Fase de análise

  O SQL Server realiza uma verificação antecipada do log de transações desde o início do último ponto de verificação bem-sucedido (ou o LSN de página suja mais antigo) até o fim, para determinar o estado de cada transação no momento da interrupção do SQL Server.

• Fase refazer

  O SQL Server executa a verificação antecipada do log de transações da transação não confirmada mais antiga até o final, para colocar o banco de dados no estado em que estava no momento da falha, refazendo todas as operações confirmadas.

• Fase desfazer

  Para cada transação que estava ativa no momento da falha, o SQL Server percorre o log em sentido reverso, desfazendo as operações realizadas por essa transação.

Com base nesse design, o tempo necessário para que o mecanismo de banco de dados se recupere 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. Portanto, o processo de recuperação do SQL Server pode levar muito tempo na presença de transações de longa duração (como grandes operações de inserção em massa ou operações de criação de índice em uma tabela grande).

Além disso, cancelar ou reverter uma transação grande baseada nesse design também pode levar muito tempo, pois esse processo usa a mesma fase de desfazer recuperação descrita acima.

Além disso, o mecanismo de banco de dados não pode truncar o log de transações quando há transações de longa execução porque seus registros de log correspondentes são necessários para os processos de recuperação e reversão. Como resultado, alguns logs de transações tornam-se muito grandes e consomem grandes quantidades de espaço na unidade.

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

A ADR aborda os problemas anteriores remodelando completamente o processo de recuperação do mecanismo de banco de dados para:

• Torne constante o tempo / instantâneo, evitando ter que escanear o log de / para o início da transação ativa mais antiga. Com a ADR, o log de transações só é processado desde o último ponto de verificação bem-sucedido ou do LSN (número de sequência de log) de página suja mais antigo. Como resultado, o tempo de recuperação não é afetado por longa execução de transações.
• Minimize o espaço de log de transações necessário, pois não há mais necessidade de processar 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.

Em um nível alto, o ADR obtém uma rápida recuperação do banco de dados, modificando todas as modificações físicas do banco de dados e apenas desfazendo as operações lógicas, 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 ADR tem as mesmas três fases que o processo de recuperação atual. A forma como essas fases operam com ADR é ilustrada no diagrama a seguir.

• Fase de análise

  O processo permanece o mesmo de hoje, com a adição da reconstrução do SLOG (fluxo de log do sistema) e da cópia de registros de log para operações sem versão.

• Fase refazer

  Dividida em duas subfases

  • Subfase 1

    Refazer de SLOG (transação não confirmada mais antiga até o último ponto de verificação). O Redo é uma operação rápida, pois precisa apenas processar alguns registros do SLOG.

  • Subfase 2

    Refazer do log de transações começa do último ponto de verificação (e não da transação não confirmada mais antiga).

• Fase desfazer

  A fase de desfazer com ADR é concluída quase instantaneamente usando SLOG para desfazer operações sem controle de versão e armazenamento de versão persistente (PVS) com reversão lógica para executar desfazer baseado em versão em nível de linha.

Também é possível assistir a este vídeo de oito minutos que explica sobre a Recuperação Acelerada de Banco de Dados:

Componentes de recuperação ADR

Os quatro componentes principais da ADR são:

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

  O repositório de versão persistente é um mecanismo de banco de dados para persistir as versões de linha geradas no banco de dados propriamente dito, em vez do repositório de versão tempdb tradicional. O PVS habilita o isolamento de recursos e melhora a disponibilidade de secundários legíveis. Há um thread de PVS por instância no SQL Server 2019 (15.x). A partir do SQL Server 2022 (16.x), o SQL Server tem um thread de limpeza PVS por banco de dados.

• 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;
  • persistido no disco ao ser serializado durante o processo de ponto de verificação;
  • truncado periodicamente conforme as transações são confirmadas;
  • Acelera as operações refazer e desfazer ao processar apenas as 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.

Aprimoramentos da ADR no SQL Server 2022 (16.x)

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

• Limpeza de transações do usuário

  Limpe páginas que não puderam ser limpas pelo processo regular devido a uma falha 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.

• Redução no volume de memória do rastreador de páginas do PVS

  Esse aprimoramento rastreia páginas do PVS (repositório de versões persistentes) no nível da extensão, a fim de reduzir o volume de memória necessário para manter páginas com controle de versão.

• Aprimoramentos da ADR (recuperação acelerada de dados)

  O limpador da ADR (recuperação acelerada de dados) tem melhor eficiência de limpeza de versão para aprimorar a forma como o SQL Server rastreia e registra versões anuladas de uma página, levando a melhorias na memória e na capacidade.

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

  Esse aprimoramento permite que a ADR limpe versões pertencentes a transações confirmadas independentemente de haver transações anuladas no sistema. Com esse aprimoramento, as páginas do PVS (repositório de versão persistente) podem ser desalocadas, mesmo que a limpeza não possa concluir uma varredura bem-sucedida para cortar o mapa de transações anuladas.

  O resultado dessa melhoria é um crescimento reduzido do PVS (repositório de versão persistente), mesmo que a limpeza da ADR 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 SQL Server.

  A partir do SQL Server 2022 (16.x), esse processo usa limpeza de versão multithread. Isso permite que vários bancos de dados na mesma instância do SQL Server sejam limpos em paralelo. Essa melhoria é valiosa quando você tem vários bancos de dados grandes.

  Para ajustar o número de threads para escalabilidade de limpeza de versão, defina ADR Cleaner Thread Count com sp_configure. A contagem de threads é limitada ao número de núcleos da instância.

  Como prática recomendada, recomendamos usar o mesmo número de threads de limpeza de ADR que o número dos bancos de dados. Por exemplo, se você configurar o ADR Cleaner Thread Count para ser 4 em uma instância do SQL Server com dois bancos de dados, o limpador ADR ainda alocará apenas um thread por banco de dados, deixando os dois threads restantes ociosos.

  O exemplo abaixo altera a contagem de threads para 4:

  EXEC sp_configure 'ADR Cleaner Thread Count', '4';
  RECONFIGURE WITH OVERRIDE; 
  

• Novo evento estendido

  Um novo evento estendido, tx_mtvc2_sweep_stats, foi adicionado para telemetria no limpador de versão multithread ADR PVS.

Melhores práticas e diretrizes

Para obter orientação sobre cargas de trabalho que são e não são recomendadas para ADR, confira Gerenciar recuperação acelerada de banco de dados.

Importante

No Banco de Dados SQL do Azure, as transações ociosas (transações que não foram gravadas no log de transações por seis horas) são encerradas automaticamente para liberar recursos.

Conteúdo relacionado

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