Recuperação acelerada do banco de dados

Aplica-se a: SQL Server 2019 (15.x) e versões posteriores Banco de Dados SQL do AzureInstância Gerenciada SQL do Azurebanco de dados SQL no Microsoft Fabric

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

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

Este artigo fornece uma visão geral da Resolução Alternativa de Litígios (RAL). Para trabalhar com ADR, revise Gerir a recuperação acelerada da base de dados.

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

Visão geral

Os principais benefícios da RAL são:

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

  As transações de longa duração não afetam o tempo de recuperação geral, permitindo uma recuperação rápida e consistente do banco de dados, independentemente do número de transações ativas no sistema ou do seu tamanho.

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

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

• Truncamento de log agressivo

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

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

Sem 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 com mais detalhes no diagrama a seguir:

• Fase de análise

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

• Refazer fase

  O mecanismo de banco de dados executa uma varredura direta do log de transações da 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.

• Desfazer fase

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

• Com o processo tradicional de recuperação de banco de dados, 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 ao trabalho que a transação executou e ao tempo em que esteve ativa.

• Cancelar ou reverter uma transação grande pode levar muito tempo, porque usa a mesma fase de recuperação de desfazer descrita anteriormente.

• O mecanismo de base de dados não pode truncar o log de transações quando existem transações de longa duração, porque os seus registos 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 acelerado de recuperação do banco de dados

O 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:

• Torne o tempo de recuperação constante, pois não há mais necessidade de verificar o log de transações desde o início da transação ativa mais antiga. No caso de usar ADR, o registo de transações só é processado a partir do último ponto de verificação bem-sucedido (ou do LSN da página suja mais antiga). Como resultado, o tempo de recuperação não é afetado por transações de longa duração e normalmente é instantâneo.

• Minimize o espaço necessário no log de transações, 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.

A um nível elevado, o ADR alcança a recuperação rápida do banco de dados versionando todas as modificações físicas do banco de dados e desfazendo apenas 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 abortadas e, portanto, quaisquer versões geradas por essas transações podem ser ignoradas por consultas simultâneas do usuário.

O processo de recuperação de ADR tem as mesmas três fases que o processo de recuperação tradicional. A forma como estas fases funcionam com ADR é ilustrada no diagrama seguinte:

• Fase de análise

  O processo permanece o mesmo que o modelo de recuperação tradicional, com a adição de reconstruir o fluxo de log secundário (SLOG) e copiar registros de log para operações sem versão.

• Refazer fase

  Dividido em duas subfases

  • Subfase 1

    Refazer a partir do SLOG (transação não confirmada mais antiga até o último ponto de verificação). Refazer é uma operação rápida, pois pode precisar apenas processar alguns registos do SLOG.

  • Subfase 2

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

• Desfazer fase

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

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

Componentes de recuperação ADR

As quatro componentes principais da RAL são:

• Armazenamento de versão persistente (PVS)

  O armazenamento de versão persistente (PVS) é um mecanismo de banco de dados para persistir as versões das linhas no próprio banco de dados em vez de no armazenamento de versão tradicional do banco de dados tempdb. O PVS permite o isolamento de recursos e melhora a disponibilidade de secundários legíveis.

• Reverso lógico

  A reversão lógica é o processo assíncrono responsável por executar o desfazer baseado em versões em nível de linha - fornecendo reversão e desfazer instantâneo de transações para todas as operações versionadas.

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

• SLOG

  O SLOG é um fluxo de log secundário na memória que armazena registos de log para operações não versionadas (como invalidação de cache de metadados, aquisições de bloqueio, etc.). O SLOG é:

  • Baixo volume e na memória
  • Persistiu no disco durante o processo de ponto de verificação
  • Periodicamente reduzido à medida que as transações são confirmadas
  • Acelera as ações de refazer e desfazer processando apenas operações não-versionadas
  • Permite o truncamento agressivo do log de transações preservando apenas os registros de log necessários

• Limpeza

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

Cargas de trabalho que beneficiam de ADR

A ADR é particularmente benéfica para cargas de trabalho que tenham:

• Transações de longa duração.
• Transações ativas que fazem com que o log de transações cresça significativamente.
• Longos períodos de indisponibilidade da base de dados devido a uma recuperação prolongada, como reinício inesperado do serviço ou reversão manual de transações.

Melhores práticas para a Resolução Alternativa de Litígios (RAL)

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

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

  • Muitas DDLs são executadas numa única transação. Por exemplo, em uma transação, criando e descartando 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 o truncamento do log de transações e retardaria 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 SLOG, consulte componentes ADR de recuperação.

• Evite ou reduza transações abortadas desnecessárias. Uma alta taxa de interrupção de transações pressiona o limpador PVS e reduz o desempenho ADR. Os abortamentos podem vir de uma alta taxa de deadlocks, chaves duplicadas, violações de restrição ou tempos limite de consulta. O sys.dm_tran_aborted_transactions DMV mostra todas as transações abortadas na instância do sistema de gerenciamento de banco de dados. A coluna nested_abort indica que a transação foi concluída, mas há partes que falharam (savepoints ou transações aninhadas), o que pode também atrasar o processo de limpeza do PVS.

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

• Quando o ADR é ativado com cargas de trabalho de gravação intensiva, a taxa de geração de logs de transações pode aumentar substancialmente porque as versões de linha gravadas no PVS são registadas. Isso pode aumentar o tamanho dos backups de log de transações.

• Quando você usa replicação transacional, replicação de instantâneoou de captura de dados de alteração (CDC), o comportamento agressivo de truncamento de log do ADR é desabilitado para permitir que o leitor de logs colete alterações do log de transações. Certifique-se de que o log de transações é suficientemente grande.

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

• Para o SQL Server, isole o armazenamento de versão PVS num grupo de arquivos em armazenamento de nível superior, como SSD de alta gama, 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 do PVS para um grupo de arquivos diferente.

• Para o SQL Server, monitorize o log de erros em busca de entradas PreallocatePVS. Caso haja entradas PreallocatePVS presentes, poderá ser necessário aumentar a capacidade do ADR para pré-alocar páginas usando uma tarefa em segundo plano. A pré-alocação de páginas PVS em segundo plano melhora o desempenho do ADR, reduzindo alocações PVS de primeiro plano mais caras. Você pode usar a configuração do servidor ADR Preallocation Factor para aumentar esse montante. Para obter mais informações, consulte a Configuração do Servidor : Fator de Pré-Alocação ADR.

• Para o SQL Server 2022 (16.x) e versões posteriores, considere ativar a limpeza PVS multithreaded se o desempenho da limpeza de thread única for insuficiente. Para obter mais informações, consulte Configuração do servidor : Contagem de threads do Limpador ADR.

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

Melhorias do ADR no SQL Server 2022

Há várias melhorias para abordar o armazenamento de versão persistente (PVS) 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.

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

• Limpeza de transações do usuário

  Páginas limpas que não podem ser limpas pelo processo normal devido a 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. Essa melhoria ajuda a garantir que o processo de limpeza do ADR não falhe indefinidamente porque as cargas de trabalho do usuário não podem adquirir bloqueios ao nível da tabela.

• Reduza o espaço ocupado pela memória do rastreador de páginas PVS

  Essa melhoria rastreia páginas PVS no nível de extensão, a fim de reduzir o espaço de memória necessário para manter páginas versionadas.

• melhorias no limpador PVS

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

• Armazenamento de versão persistente (PVS) no nível de transação

  Essa melhoria permite que o ADR limpe versões que pertencem a transações comprometidas, independentemente de haver transações abortadas no sistema. Com essa melhoria, as páginas PVS podem ser deslocalizadas, mesmo que a limpeza não possa concluir uma varredura bem-sucedida para cortar o mapa de transações abortado.

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

• Limpeza de versão multiencadeada

  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 multithread. 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, consulte Configuração do servidor : Contagem de threads do Limpador ADR.

  Um novo evento estendido, tx_mtvc2_sweep_stats, foi adicionado para a monitorização do limpador de versões multi-threaded ADR PVS.

Conteúdo relacionado

• Gerencie a recuperação acelerada do banco de dados
• Solucionar problemas de recuperação acelerada de banco de dados