Para isso, serão abordadas
técnicas de movimentação de dados que ajudam a minimizar o consumo excessivo de
espaço no transaction log. O transaction log é um componente existente em todos
os bancos de dados SQL Server, tendo um papel de alta criticidade no controle
de consistência do banco de dados em caso de falhas inesperadas como falta de
energia ou falha de hardware.
Em muitas organizações não existe o papel do administrador de banco de dados, ficando o administrador de sistemas ou mesmo o programador a cargo desta tarefa. Isto faz com que as atividades de administração do banco de dados e todo o cuidado na manutenção dos dados seja posto, por vezes, em segundo plano.
Em outros casos as funções de DBA são executadas por um profissional pouco experiente ou que desconhece o funcionamento e a importância do transaction log. Esta falta de conhecimento no funcionamento do transaction log faz com que o profissional adote medidas que podem prejudicar a performance ou mesmo causar indisponibilidade do banco de dados.
O transaction log é um componente existente em todos os bancos de dados SQL Server, tendo um papel de alta criticidade no controle de consistência do banco de dados em caso de falhas inesperadas como, por exemplo, falta de energia ou uma falha de hardware.
Como forma de garantir a consistência, todas as transações que efetuem modificações no banco de dados são registradas no transaction log. Entende-se por modificação qualquer adição, alteração e/ou eliminação em qualquer objeto ou dados do banco de dados.
A manipulação dos dados pode levar o SQL Server a alocar ou remover páginas de dados do buffer e dos arquivos de dados, mas antes esta movimentação será registrada no transaction log. Resumindo, tudo que modifique o banco de dados fica registrado.
Um caso típico de problema com o transaction log é o controle do seu crescimento, que normalmente está relacionado a: blocos transacionais envolvendo uma grande quantidade de registros, transações com duração temporal muito longa ou por falta de backup do transaction log, quando aplicável. Estas situações podem fazer com que o log transacional cresça muito, ao ponto de que, em alguns casos, preencha todo o espaço livre em disco ou mesmo chegue ao seu limite de crescimento.
É muito comum, em especial, em processos de migração de dados de uma tabela para outra ou mesmo de banco de dados para outro, movimentar todo o conteúdo da tabela numa única transação. Nestes casos, quanto maior for a tabela, maior será o impacto no transaction log. Em substituição a esta prática, o melhor seria a criação de uma estrutura que permita a movimentação dos dados em blocos transacionais menores e de pouco impacto.
A arquitetura do transaction log, bem como compreender o seu funcionamento, são pontos importantes para um melhor entendimento do caso prático que será apresentado ao longo deste artigo. Desta forma, o próximo tópico abordará alguns aspectos importantes sobre esta arquitetura.
Arquitetura do transaction log
O SQL Server utiliza o conceito ACID, acrônimo para as propriedades Atomicidade, Consistência, Isolamento e Durabilidade, analisadas a seguir:
· Atomicidade: toda a transação deve ser atômica, ou seja, tratada de forma única. Se uma parte da transação não for confirmada, toda a transação será revertida;
· Consistência: garante que os dados estão íntegros de acordo com as restrições lógicas aplicadas através das foreign keys, primary keys, contrains, entre outras;
· Isolamento: esta propriedade garante que as transações sejam tratadas de forma separada, consoante o isolamento escolhido, que podem ser: read uncommitted, read committed, repeatable read, snapshot e serializable;
· Durabilidade: garante que os dados persistam no banco de dados e não sejam perdidos após o restart do servidor.
O transaction log aplica duas destas propriedades: atomicidade e durabilidade. Em outras palavras, podemos dizer que o SQL Server, através do log de transação, garante que as transações sejam atômicas, ou seja, no momento do commit todo o conteúdo da transação deverá ser confirmado, caso contrário todo o conteúdo será revertido.
Com a aplicação da durabilidade é garantido que todas as transações confirmadas no banco de dados continuarão a existir, mesmo após o reinício do servidor ou após algum crash de sistema.
O transaction log funciona com uma espécie de sniffer, capturando todas as modificações efetuadas sobre o banco de dados. Estas modificações vão desde alocações de páginas até a manipulação dos dados propriamente dita, por exemplo: ao inserir um cliente em uma tabela, o SQL Server deverá aprovisionar novas páginas de dados e/ou índices para armazenar este novo cliente.
O aprovisionamento das páginas será registrado no transaction log como pertencente à transação que iniciou a inserção do cliente, tal como este novo cliente também ficará registrado no log de transação.
É muito importante que todas as modificações fiquem registradas, porque caso seja necessário reverter a transação, tudo terá que ser revertido, incluindo as páginas alocadas.
Internamente o transaction log
é um arqui ...
