Compartilhar via

Recuperação Acelerada de Banco de Dados no SQL do Azure

  • Artigo

Aplica-se a: Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure

ADR (Accelerated Database Recovery - Recuperação Acelerada de Banco de Dados) é um novo recurso de mecanismo de banco de dados SQL Server que melhora bastante a disponibilidade do banco de dados, especialmente na presença de transações de execução prolongada, reprojetando o processo de recuperação do mecanismo de banco de dados SQL Server.

O ADR está disponível no momento para o Banco de Dados SQL do Azure, Instância Gerenciada de SQL do Azure, bancos de dados no Azure Synapse Analytics e SQL Server em VMs do Azure a partir do SQL Server 2019. Para obter informações sobre ADR no SQL Server, consulte Gerenciar a recuperação acelerada de banco de dados.

Observação

A ADR é habilitado por padrão no Banco de Dados SQL do Azure e no Instância Gerenciada de SQL do Azure. Não há suporte para desabilitar ADR no Banco de Dados SQL do Azure e na Instância Gerenciada de SQL do Azure.

Visão geral

Os principais benefícios do ADR são:

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

    Com a 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 o ADR, 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.

Processo de recuperação de banco de dados padrão

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

processo de recuperação atual

  • Fase de análise

    Encaminhar a verificação do log de transações desde o início do último ponto de verificação bem-sucedido (ou o LSN da página suja mais antiga) até o final, para determinar o estado de cada transação no momento em que o banco de dados foi interrompido.

  • Fase refazer

    Encaminhar verificação do log de transação da transação mais antiga não confirmada até o fim, para trazer o banco de dados para o estado em que estava no momento da falha ao refazer todas as operações.

  • Fase desfazer

    Para cada transação que estava ativa no momento da falha, o registro é revertido, desfazendo as operações executadas por essa transação.

Com base nesse design, o tempo que o mecanismo do banco de dados SQL Server leva para recuperar-se 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 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, o cancelamento / reversão de uma transação grande com base nesse design também pode levar um longo tempo, já que está usando a mesma fase de recuperação Desfazer, conforme descrito acima.

Além disso, o mecanismo de banco de dados SQL Server não pode truncar o log de transações quando há transações de execução longa, porque seus registros de log correspondentes são necessários para os processos de recuperação e reversão. Como resultado desse design do mecanismo de banco de dados SQL Server, alguns clientes enfrentam o problema de que o tamanho do log de transação cresce muito e consome grandes quantidades de espaço na unidade.

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

O ADR soluciona os problemas acima, redesenhando completamente o processo de recuperação do mecanismo de banco de dados SQL Server 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 o 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 antiga). 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. Qualquer transação que estava ativa no momento de uma falha é marcada como abortada e, portanto, qualquer versão gerada por essas transações pode ser ignorada por consultas de usuários simultâneas.

O processo de recuperação ADR tem as mesmas três fases que o processo de recuperação atual. Como essas fases operam com ADR é ilustrado no diagrama a seguir e explicado com mais detalhes seguindo o diagrama.

Processo de recuperação ADR

  • Fase de análise

    O processo permanece o mesmo que antes, com a adição da recriação de SLOG e a cópia de registros de log para operações sem controle de versão.

  • Fase refazer

    Dividido em duas fases (P)

    • Fase 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.

    • Fase 2

      Refazer a partir do Log de transações inicia a partir do último ponto de verificação (em vez da transação não confirmada mais antiga)

  • Fase desfazer

    A fase Desfazer com a ADR é concluída quase instantaneamente usando o SLOG para desfazer operações sem controle de versão e o PVS (Repositório de Versão Persistente) com a Reversão Lógica para executar Desfazer baseado em versão de nível de linha.

Componentes de recuperação ADR

Os quatro componentes principais da ADR são:

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

    O armazenamento de versão persistente é um novo mecanismo de mecanismo de banco de dados SQL Server para persistir as versões de linha geradas no próprio banco de dados, em vez do tradicional tempdb armazenamento de versão. PVS habilita o isolamento de recursos, bem como 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 no nível de linha, fornecendo reversão de transação instantânea e operação de desfazer para todas as operações com controle de versão. A reversão lógica é realizada por:

    • Manter o controle de todas as transações anuladas e marcá-las invisíveis para outras transações.
    • Executar a reversão usando PVS para todas as transações de usuário, em vez de verificar fisicamente o log de transações e desfazer as alterações uma de cada vez.
    • Liberar todos os bloqueios imediatamente após a anulação da transação. Como a anulação envolve simplesmente marcar alterações na memória, o processo é muito eficiente e, portanto, os bloqueios não precisam ser mantidos por muito tempo.

  • 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 que é ativado periodicamente e limpa as versões de página que não são necessárias.

Padrões de ADR (Recuperação Acelerada de Banco de Dados)

Os seguintes tipos de cargas de trabalho se beneficiam do ADR:

  • A ADR é recomendado para cargas de trabalho com transações de execução prolongada.
  • A ADR é recomendado para cargas de trabalho com casos em que as transações ativas estão causando aumento significativo do log de transações.
  • A ADR é recomendado para cargas de trabalho que tiveram longos períodos de indisponibilidade de banco de dados devido a recuperação de execução prolongada (assim como reinicialização inesperada do serviço ou reversão de transação manual).

Melhores Práticas para recuperação de banco de dados acelerada

  • Evite transações de longa execução no banco de dados. Embora um objetivo de ADR seja acelerar a recuperação do banco de dados devido à refazer transações ativas longas, as transações de longa execução podem atrasar a limpeza da versão e aumentar o tamanho do PVS.

  • Evite transações grandes com alterações de definição de dados ou operações DDL. A ADR usa um mecanismo de SLOG (fluxo de log do sistema) para rastrear as operações DDL usadas na recuperação. O SLOG é usado apenas enquanto a transação está ativa. O SLOG é um ponto de verificação, portanto, evitar transações grandes que usam o SLOG pode ajudar no desempenho geral. Esses cenários podem fazer com que o SLOG retenha 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 de SOLTAR TABELA nessa tabela exigiria uma grande reserva de memória SLOG, o que atrasaria o truncamento do log de transações e atrasará as operações de desfazer/refazer. A solução alternativa pode descartar os índices individualmente e gradualmente e, em seguida, remover a tabela. Para obter mais informações sobre o SLOG, consulte Componentes de recuperação ADR.

  • Impedir ou reduzir situações anuladas desnecessárias. Uma taxa de anulação alta colocará pressão sobre o desempenho PVS e inferior de ADR. As anulações podem vir de uma alta taxa de deadlocks, chaves duplicadas ou outras violações de restrição.

    • A DMV sys.dm_tran_aborted_transactions mostra todas as transações anuladas na instância do SQL Server. A coluna nested_abort indica que a transação foi confirmada, mas há partes que foram anuladas (pontos de salvamento ou transações aninhadas) que podem bloquear o processo de limpeza de PVS. Para obter mais informações, veja sys.dm_tran_aborted_transactions (Transact-SQL).

    • Para ativar o processo de limpeza do PVS manualmente entre as cargas de trabalho ou durante as janelas de manutenção, use sys.sp_persistent_version_cleanup. Para obter mais informações, consulte Sys.sp_persistent_version_cleanup.

  • Se você observar problemas com o uso de armazenamento, alta transação de anulação e outros fatores, consulte Solução de problemas de ADR (Recuperação Acelerada de Banco de Dados) no SQL Server.

Próximas etapas