Boa dia meus amigos hoje, trouxe algumas informações sobre o log de  do SQL que é de fundamental importância para um banco SQL.

. O Transaction Log é um conceito de banco de dados muito importante e conhecer o seu funcionamento é valioso para qualquer DBA ou desenvolvedor que deseje trabalhar com o SQL Server , seja tirando um Backup ou mesmo efetuando somente um SELECT.

Relembrando que um banco de dados no SQL Server é constituído de um arquivo principal, (geralmente, mas nem sempre, com extensão .mdf) nenhum, um ou vários arquivos secundários, com extensão .ndf e um ou mais arquivos do Transaction Log, geralmente com extensão .ldf. É importante notar que as extensões dos arquivos não precisam ser necessariamente .mdf, .ndf e .ldf. Ou seja, nem sempre o Transaction Log possui a extensão .log.

É uma boa idéia colocar estes arquivos em controladores de disco rígidos diferentes para aumentar o desempenho. É importante dizer que devemos colocar em HD’s diferentes e não em partições diferentes de uma mesma HD, onde não há ganho de performance.

Os arquivos primários e secundários armazenam a definição dos objetos do banco e dos dados e o arquivo de Transaction Log armazenas instruções Transact-SQL. A figura abaixo foi traduzida do Books OnLine e mostra como estes arquivos se encaixam no contexto de banco de dados do SQL Server:

 

Antes de começar a entender o Transaction Log do SQL Server, é bom recordarmos um pouco sobre o conceito de transação, o conceito de transação completa (a transação que foi completada com COMMIT) e o conceito de transação incompleta (a transação que foi terminada por um ROLLBACK) 

Estes conceitos são extremamente importantes para entender como o Transacion Log do SQL Server funciona e para que ele serve. O que devemos adicionar aqui é que todo o comando enviado para o SQL Server faz parte de uma transação, seja ela explícita por um BEGIN TRANSACTION, ou seja ela implícita.

No início da transação o SQL Server obtém os dados com que o usuário deseja trabalhar dos arquivos físicos e os coloca na memória em um lugar chamado de buffer cache. Enquanto o usuário está trabalhando com os dados na transação nenhuma alteração é feita nos arquivos físicos do banco de dados: somente os dados que estão na memória são alterados e, dependendo do nível de isolação da transação, outros usuários podem ou não enxergar as mudanças feitas enquanto a transação não foi completada.

O local onde os dados ficam na memória é chamado de buffer cache e eles ficam no buffer cache antes de serem escritos fisicamente no disco rígido.

Uma vez que a transação seja completada com sucesso, através de um COMMIT ou internamente, todas as instruções Transact-SQL que esta transação efetuou são armazenadas no Transaction Log, fisicamente dentro do arquivo .ldf.

Com isso o Transaction Log do banco de dados vai ficando cheio. De tempos em tempos o SQL Server faz o que chamamos de checkpoint. Um checkpoint é o processo de escrever as dirty pages que estão no buffer cache para o(s) arquivo(s) de banco de dados físico primário(s) e/ou secundário(s). Ao final do processo de checkpoint, a porção inativa do Transaction Log que contém os comandos correspondentes ao que foi escrito no(s) arquivo(s) é liberada e o tamanho do Transaction Log diminui. Este processo de escrever dirty pages que estão no buffer cache para o disco rígido é chamado de flushing the page.

Esta técnica de primeiro escrever as modificações em um arquivo de log e periodicamente ‘limpar’ este arquivo de log depois de se escrever o que está na memória para um arquivo físico do banco de dados é chamada write-ahead log. Esta técnica permite um grande ganho de desempenho e outros bancos de dados como o Oracle e o DB2 também utilizam um conceito parecido. No SQL Server todo banco de dados obrigatoriamente deve possuir ao menos um arquivo de Transaction Log, ou seja, esta técnica é obrigatória e é feita automaticamente.

Vamos ver um exemplo deste processo passo-a-passo:

1. A aplicação do usuário envia um comando para alterações de dados, como um UPDATE em várias linhas de uma tabela, por exemplo.

2. Internamente o SQL Server retira um certa quantidade de linhas desta tabela, incluindo as linhas que se deseja alterar, do arquivo físico do banco de dados e as coloca no buffer cache (memória). Se estas linhas já estão na memória o SQL Server não faz nada neste passo.

3. O comando é executado, afetando as linhas que estão no buffer cache , gerando dirty pages.

4. Caso o comando UPDATE tenha conseguido alterar as linhas desejadas com sucesso no buffer cache, o SQL Server escreve o comando UPDATE no Transaction Log da mesma maneira que ele foi executado pela aplicação do usuário. No caso de falha do UPDATE em alguma linha, todas as linhas que já tiveram sido alteradas são voltadas para o seu estado inicial, nada é escrito no Transaction Log e uma mensagem de erro é devolvida para a aplicação do usuário que enviou o comando UPDATE.

5. Por enquanto as linhas alteradas já estão modificadas na memória. Qualquer outro usuário que tente visualizar estas linhas irá obtê-las do buffer cache e já as encontrará modificadas.

6. No próximo processo de checkpoint as linhas que foram modificadas e estão na memória são escritas nos arquivos físicos de banco de dados no disco rígido. Feito isso, a instrução UPDATE que estava escrita no Transaction Log é retirada, diminuindo o tamanho do Transaction Log.

Leia Também:   Como transformar um formulário no Access em janela

Espero que tenham gostado.

Abraço.