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