SQL Server 2014 – New Feature – Delayed Transaction Durability

SQL Server 2014 – New Feature – Delayed Transaction Durability
Rate this post


 

    Uma das principais características de um SGBD (Sistema Gerenciador de Banco de Dados) é a capacidade de manter e garantir os princípios do ACID (Atomicidade, Consistência, Isolamento e Durabilidade). O escopo deste artigo é tratar basicamente da última das propriedades de bancos de dados relacionais que é a Durabilidade.

    De acordo com a enciplopédia livre WikiPédia, Durabilidade define-se:

“Os efeitos de uma transação em caso de sucesso (commit) devem persistir no banco de dados mesmo em presença de falhas. Garante que os dados estarão disponíveis em definitivo.”

Fonte: http://pt.wikipedia.org/wiki/ACID

De acordo com a definição acima, a Durabilidade garante que uma transação poderá ser recuperada, mesmo após uma falha ou desligamento total do sistema, desde que esta tenha passado por um “commit” com sucesso.

O processo normal de uma transação, baseia-se no protocolo WAL (Write Ahead Logging), ou traduzindo: “Escreva primeiro no log”, que mantém e garante as propriedades ACID da transação. A transação (UPDATE, INSERT, DELETE) é submetida à engine do SQL Server, e somente recebe um “acknowledge” após ter literalmente sido escrita de forma SÍNCRONA no arquivo do Log de Transações.

Com o Delayed Durability, é possível atrasar a escrita no Log, fazendo com que as transações com esta característica recebam o “acknowledge” antes mesmo de ter sido escrita no arquivo do Log de Transações, o que acontecesse neste caso, de forma ASSÍNCRONA.

Basicamente existem dois tipos de transações:

  • Fully Durable Transactions:
    • O “Commit” acontece de forma síncrona, e a aplicação que submeteu a transação recebe o retorno após o processo de escrita no log de transações.
    • Qualquer transação deste tipo, força um “flush” do log buffer, fazendo com todas as transações sejam persistidas.
  • Delayed Durable Transaction
    • O “Commit” acontece de forma assíncrona, antes do registro da transação ser escrito em disco.

Benefícios:

“A performance do seu banco de dados é diretamente proporcional à capacidade de escrita de seu disco do Transaction Log”

    Fonte: (Autor desconhecido)

    O principal benefício na utilização de Delayed Durable Transactions é o aumento no throughput no disco de Log de Transações, visto que como o tempo de commit é reduzido, os locks são liberados mais rapidamente reduzindo a contenção e este tipo de espera. Quando há alta latência neste disco, também percebe-se um ganho, visto que a escrita passa a ser assíncrona, não necessitando mais o cliente esperar por esta escrita em disco, antes da confirmação de seu commit.

C.U.I.D.A.D.O

    Esta Nova Feature apenas deve ser utilizada em ambientes que tolerem alguma perda de dados. Caso o ambiente não tolere “data loss”, esta feature NÃO DEVE SER IMPLEMENTADA , pois em caso de “Server Crash”, Dirty Shutdown” ou “Restart”, as transações que ainda permanecerem como “DELAYED DURABLE” serão perdidas e não poderão ser recuperadas.

Implementação:

    Basicamente existem duas configurações que afetam a propriedade “DURABILIDADE” das transações. A nível de Banco de dados, e a nível de Transação.

Configuração a nível de banco de dados:

  • DISABLED: Todas as transações são Fully Durable Transactions, não há perda de dados e independe da configuração a nível de transação.
    • ALTER DATABASE [DBNAME] SET DELAYED_DURABILITY DISABLED
  • ALLOWED: A durabilidade das transações deste banco é determinada pela configuração a nível de transação.
    • ALTER DATABASE [DBNAME] SET DELAYED_DURABILITY = ALLOWED
  • FORCED: Todas as transações são Delayed Durable Transaction independente da configuração a nível de transação. Neste caso, há possibilidade de perda de dados.
    • ALTER DATABASE [DBNAME] SET DELAYED_DURABILITY FORCED

 

Configuração a nível de transação:

 É possível definir a durabilidade da transação na cláusula “commit” da transação, e também dentro do bloco atômico das “Natively Compiled Stored Procedures” que é uma outra novidade do SQL Server 2014, e tema para um futuro artigo.

    Para ambos os casos, a configuração a ser feita é [DELAYED_DURABILITY = ON] ou [DELAYED_DURABILITY = OFF].

    Exemplo de configuração a nível de transação na cláusula “commit”

  • COMMIT TRAN transaction_name WITH ( DELAYED_DURABILITY OFF)
  • COMMIT TRAN transaction_name WITH ( DELAYED_DURABILITY ON)

Uma transação é Delayed Durable até que uma algum evento aconteça e faça o Flush dos dados do log buffer para o disco, uma vez persistida em disco, a transação passa a ser Fully Durable e como as demais que já iniciaram desta maneira.

Os eventos que forçam o “flush” do log buffer são:

  • Execução da procedure execsys.sp_flush_log
  • Log buffer estiver cheio
  • Qualquer Fully Durable Transaction que executar na base.

Este foi um overview desta nova feature presente no SQL Server 2014, e que apesar de poder ser bastante útil, deve ser usada com cuidado e moderação, pois seu uso indevido pode gerar problemas como perda dados em ambientes que não tem este tipo de tolerância.

Uma vez que você chegou até este ponto, peço que use o espaço dos comentários para deixar uma crítica, elogio, sugestão, correção ou qualquer outra mensagem…

Grande Abraço,

Edvaldo Castro

Referências:

CONTROL TRANSACTION DURABILITY – http://msdn.microsoft.com/en-us/library/dn449490(v=sql.120).aspx

WAL – http://technet.microsoft.com/pt-br/library/ms186259(v=sql.105).aspx

 

 

 

15 thoughts on “SQL Server 2014 – New Feature – Delayed Transaction Durability

    1. Obrigado pela visita Iorranalves,

      Sinceramente, não conheço Oracle, mas realmente muitas features em diversos SGBDs tem características praticamente idênticas, com nomes diferentes…

      Obrigado pelo comentário…

      []’s

      Edvaldo Castro

        1. “Infelizmente, Não sei dizer…”

          Desculpe, acho que acabei me confundindo …

          Não sei dizer com relação ao Oracle, mas no SQL Server, o Delayed Transaction Durability tem como habilitar por transação, basta deixar o database como “ALLOWED” e habilitar ou não no “COMMIT WITH (DELAYED_DURABILITY = ON)…

          Desculpe-me o equívoco…

          Abraços

    1. Olá Noraldino,
      Obrigado pelo comentário, certamente é perigosa para ambiente que não toleram perda de dados… é preciso usá-la com moderação…

      Abraços

      1. Sim, isso mesmo, mas o que você define como perda de dados? Porque ao meu ver qual ambiente toleraria perda de dados? Ao meu ver um ambiente que tolera essa perda não tem pessoal com capacidade intelectual para usar features como essa.

        Abraço.

        1. Olá Noraldino,
          Existem alguns ambientes que o negócio permite que se perca alguns dados, que podem ser facilmente reconstruídos ou descartados, sem maiores prejuízos para o negócio. Nestes cenários, um throuput maior é mais benéfico do que garantir que você terá 100% das suas informações.

          Por exemplo, uma máquina de Stage, utilizada para Cargas em BI, você “tolera” perda de dados, uma vez que se esta instância cair ou der um crash, basta reprocessar a carga. Para este cenário específico, é mais interessante que a carga processe mais rápido, e paga-se o risco de ter que reprocessar esta carga em caso de falha da instância.

          Obrigado pela visita e pelo comentário,

          Abraços…

Deixe uma resposta

%d blogueiros gostam disto: