ga('create', 'UA-28806596-1', 'auto'); ga('send', 'pageview');

    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