Recuperação acelerada de banco de dados no SQL do Azure

  • Artigo

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

A Recuperação Acelerada de Banco de Dados (ADR) é um recurso do mecanismo de banco de dados do SQL Server que melhora muito 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 do SQL Server.

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

Nota

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

Descrição geral

Os principais benefícios da RAL são:

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

    Com o ADR, 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 de seus tamanhos.

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

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

  • Truncamento agressivo de log

    Com o ADR, o log de transações é agressivamente truncado, mesmo na presença de transações ativas de longa duração, o que impede que ele fique 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 seguindo o diagrama.

current recovery process

  • Fase de análise

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

  • Fase de refazer

    Varredura direta do log de transações da transação não confirmada mais antiga até o final, para trazer o banco de dados para o estado em que estava no momento da falha, refazendo todas as operações confirmadas.

  • Fase de desfazer

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

Com base nesse design, o tempo que o mecanismo de banco de dados do SQL Server 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 ao trabalho que a transação executou e ao tempo em que esteve ativa. Portanto, o processo de recuperação pode levar muito tempo na presença de transações de longa execução (como grandes operações de inserção em massa ou operações de compilação de índice em uma tabela grande).

Além disso, cancelar/reverter uma transação grande com base nesse design também pode levar muito tempo, pois está usando a mesma fase de recuperação Desfazer, conforme descrito acima.

Além disso, o mecanismo de banco de dados do SQL Server 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 desse design do mecanismo de banco de dados do SQL Server, alguns clientes costumavam enfrentar o problema de que o tamanho do log de transações cresce muito e consome grandes quantidades de espaço em disco.

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

O ADR resolve os problemas acima redesenhando completamente o processo de recuperação do mecanismo de banco de dados do SQL Server para:

  • Torne-o constante, tempo/instante, evitando ter que verificar o log de/para o início da transação ativa mais antiga. Com o ADR, o log de transações só é processado a partir do último ponto de verificação bem-sucedido (ou do número de sequência de log (LSN) da página suja mais antiga). Como resultado, o tempo de recuperação não é afetado por transações de longa duração.
  • 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 agressivamente à medida que pontos de verificação e backups ocorrem.

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

O processo de recuperação de RAL tem as mesmas três fases que o processo de recuperação atual. A forma como estas fases funcionam com ADR é ilustrada no diagrama seguinte e explicada mais detalhadamente seguindo o diagrama.

ADR recovery process

  • Fase de análise

    O processo permanece o mesmo de antes com a adição de reconstruir SLOG e copiar registros de log para operações sem versão.

  • Fase de refazer

    Dividido em duas fases (P)

    • Fase 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 só precisa processar alguns registros do SLOG.

    • Fase 2

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

  • Fase de desfazer

    A fase Desfazer com ADR é concluída quase instantaneamente usando SLOG para desfazer operações sem 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.

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

    • Manter o controle de todas as transações abortadas e marcá-las invisíveis para outras transações.
    • Executar a reversão usando PVS para todas as transações do 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 transação ser abortada. Como abortar 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

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

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

  • Mais limpo

    O limpador é o processo assíncrono que é ativado periodicamente e limpa versões de página que não são necessárias.

Padrões de recuperação acelerada de banco de dados (ADR)

Os seguintes tipos de cargas de trabalho são os que mais beneficiam da resolução alternativa de litígios:

  • O ADR é recomendado para cargas de trabalho com transações de longa duração.
  • O ADR é recomendado para cargas de trabalho que viram casos em que as transações ativas estão fazendo com que o log de transações cresça significativamente.
  • O ADR é recomendado para cargas de trabalho que sofreram longos períodos de indisponibilidade do banco de dados devido à recuperação de longa duração (como reinicialização inesperada do serviço ou reversão manual de transações).

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

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

  • Evite grandes transações com alterações de definição de dados ou operações DDL. O ADR usa um mecanismo SLOG (fluxo de log do sistema) para rastrear operações DDL usadas na recuperação. O SLOG só é usado enquanto a transação estiver 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 em uma 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 atrasaria as operações de desfazer/refazer. A solução alternativa pode ser soltar os índices individualmente e gradualmente, em seguida, soltar a tabela. Para obter mais informações sobre o SLOG, consulte Componentes de recuperação ADR.

  • Previna ou reduza situações abortadas desnecessárias. Uma alta taxa de abortamento pressionará o limpador PVS e reduzirá o desempenho ADR. Os abortamentos podem vir de uma alta taxa de bloqueios, chaves duplicadas ou outras violações de restrição.

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

    • Para ativar o processo de limpeza PVS manualmente entre 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 do armazenamento, alta transação abortada e outros fatores, consulte Solução de problemas de recuperação acelerada de banco de dados (ADR) no SQL Server.

Próximos passos