Arquitetura do Transaction Log

Published on 30 de maio de 2012 by Luiz Mercante in Artigos

Muitas bases so criadas por desenvolvedores que no conhecem a fundo o SQL Server. Esta prtica pode ocasionar uma srie de problemas, dentre eles, um Transaction Log com baixa performance e que no pode ser compactado para liberar espao em disco. Vamos entender como funciona o Transaction Log e quais as melhores prticas para termos melhor performance, eliminando alguns problemas que podem at parar a base como falta de espao em disco. Uma base pode ter um ou mais arquivos de TLog, que possuem uma estrutura interna dividida em Virtual Log Files (VLF):

Quando a base criada, o TLog utilizado no incio do arquivo e enquanto no existe o primeiro backup full, o recovery mode utilizado o SIMPLE mesmo que esteja configurado como FULL. Neste exemplo, possui 6 VLFs e todo o seu contedo est concentrado no VL1 e VL2 enquanto os demais esto vazios, portanto, marcados como inativos. Estes VLFs so criados automaticamente pela Engine do SQL Server e no h como o Administrador do servidor interferir em seu tamanho, quantidade ou posio diretamente, mas podemos fazer isso indiretamente. Para entendermos melhor como funciona vamos utilizar um exemplo: Se criarmos uma base e definirmos o TLog com tamanho inicial de 10MB e autogrow de 1MB (mais comum do que se imagina), teremos VLFs de 1MB. Se esta base entrar em produo e o TLog atingir 1GB, por exemplo, teremos ento 1024 VLFs neste arquivo, quando poderamos ter apenas 4 ou 5. O tamanho mnimo do VLF de 256KB, imaginem um TLog de 10GB com VLFs deste tamanho. Vamos entender um pouco mais sobre o Transaction Log utilizando a mesma estrutura do TLog mostrado acima, mas j utilizado durante algum tempo. Suponhamos que seja um TLog de 6GB, dividido em 6 VLFs de 1GB cada:

Start of logical log: onde est o incio do bloco de informaes de transaes. Neste caso no coincide com o incio do arquivo de TLog por vrios possveis motivos e o VL1 e VL2 est marcado como inativo pelo SQL. End of logical log: local do arquivo onde terminam os registros de transaes, no exemplo acima bem no final do arquivo. Se novas transaes fossem realizadas, um Virtual log 7 de 1GB seria criado por estar configurado como autogrow de 1024MB. MinLSN: Minimum recovery log sequence number - nmero da ltima transao registrada no log, indispensvel em caso de rollback e portanto no pode ser apagado. Ao truncar o TLog, todos os registros entre End of logical log e MinLSN so removidos. Os dados antes deste ponto permanecem.

Vamos ver como ficaria nosso TLog depois de um backup do Log. Como sabemos, o backup de Transaction Log realiza um truncate no arquivo, ou seja, apaga todos os dados que esto entre o MinLSN e o final das transaes:

Notamos que agora temos 4 VLFs vazios VL1, VL2, VL5 e VL6. Levando em conta que cada VLF ocupa 1GB do disco, poderamos liberar 4GB de espao. Se executarmos um DBCC SHRINKFILE(TesteDBLog, 2048) para tentarmos devolver os 4GB ao sistema operacional e deixarmos o arquivo de TLog com 2GB, teremos o seguinte resultado:

Apesar de termos determinado que o TLog deveria ficar com 2GB, ele liberou somente o espao do VL5 e VL6. Isto acontece pois no possvel remover os VLFs que ficam antes dos dados, ou seja, antes dos VLFs marcados como ativos. Outra observao interessante, que o shrink feito por VLF e no por espao como MB e GB. Veja que a parte vazia do VL4 continua l. Para resolver esta situao, se desabilitarmos o autogrow, rodarmos o DBCC SHRINK novamente e o SQL preenche o espao vazio do VL4 com dados fictcios sem qualquer importncia, apenas para completar o espao vazio do VL4.

Como ele no pode mais crescer, automaticamente as transaes passam a ser registradas no comeo do arquivo de TLog que est em branco e em breve teremos um novo comeo, um novo MinLSN e um novo fim. Vamos executar um novo backup dos logs e ver como ficou nosso TLog:

Percebemos que os dados anteriores foram salvos no backup e os novos dados j esto sendo registrados no VL1. Agora se rodarmos um DBCC SHRINKFILE novamente com o parmetro de 1024MB, conseguiremos liberar 3GB de espao, atravs do VL2, VL3 e VL4 que sero excludos pois esto inativos. Com esta explicao, espero ter ficado claro que muito melhor termos um arquivo de TLog com tamanho fixo, devidamente calculado, monitorando sua utilizao para evitar que se encha at a base cair. Em breve farei outro artigo sobre como obter as informaes que aprendemos aqui e outro sobre como monitorar o espao do TLog.

Acompanhando a utilizao do TLog

Published on 5 de junho de 2012 by Luiz Mercante in Artigos

Complementando o artigo sobre a estrutura do Transaction Log, vamos ver como obter informaes importantes sobre o TLog para acompanharmos sua utilizao e assim conhecermos esta informao dentro do nosso ambiente. Iremos criar duas Stored Procedures (SP), a uspLogSpace para obtermos as informaes atravs do DBCC SQLPERF e a uspRegisterLogSpace para inserirmos estas informaes em uma tabela e assim mantermos um histrico. Antes de comearmos, vamos dar uma olhada no retorno do DBCC SQLPERF(logspace):

Log Size (MB): espao disponvel para o arquivo de TLog. o que o arquivo tlog.ldf ocupa em disco. Log Space Used (%): porcentagem utilizada do arquivo de TLog. Status: sempre zero, vamos excluir esta informao desnecessria na nossa tabela. Ficou mais claro o que vamos armazenar em nossa tabela? Tirando a coluna Status que sempre zero, tudo muito til. Teremos tambm a coluna logDate portanto vamos criar a tabela para armazenar estes registros:
CREATE TABLE dbo.TlogUtilization ( id INT IDENTITY (1,1), logDate datetime DEFAULT GETDATE(), databaseName sysname, logSize decimal(18,5),

logUsed decimal(18,5) ) GO

Agora com a tabela criada, podemos criar as SPs e utiliz-las. Primeiro, vamos criar a uspLogSpace que obtm os dados atravs do DBCC SQLPERF(logspace):
-- cria a procedure upsLogSpace CREATE PROC dbo.uspLogSpace AS DBCC SQLPERF(logspace) GO

Com a SP uspLogSpace criada, vamos criar a SP uspRegisterLogSpace

-- cria a procedure upsRegisterLogSpace CREATE PROC dbo.uspRegisterLogSpace AS SET NOCOUNT ON -- cria uma tabela temporria para armazenar -- o resultado do DBCC SQLPERF CREATE TABLE #tempResult ( databaseName sysname, logSize decimal(18,5), logUsed decimal(18,5), status INT ) -- insere os dados do DBCC SQLPERF usando a procedure criada anteriormente INSERT INTO #tempResult EXEC uspLogSpace -- transfere os dados para a tabela fixa INSERT INTO TlogUtilization (databaseName, logSize, logUsed) SELECT databasename, logSize, logUsed FROM #tempResult -- exclui a tabela temporria DROP TABLE #tempResult GO

Agora temos a tabela populada com as primeiras informaes sobre o TLog. Sempre que quiser coletar estas informaes, basta executar a SP uspRegisterLogSpace:
EXEC uspRegisterLogSpace

Sugiro que coloque a execuo da SP uspRegisterLogSpace em seu Maintenance Plan para coletar os dados todas as noites. Assim quando quiser saber a mdia de crescimento da utilizao do arquivo ou quanto ele cresceu na semana passada fica fcil. Se voc utiliza tamanho fixo no TLog (recomendado), esta semana teremos um script que envia email caso a utilizao do TLog ultrapasse 70%.