Nesse artigo Kimberly L. Tripp\u00a0(Blog<\/a>|Twitter<\/a>) da uma s\u00e9rie de dicas para serem aplicadas nos arquivos de log do SQL Server.\u00a0 Uma dessas dicas (a de n\u00famero oito) \u00e9 para checar e corrigir a fragmenta\u00e7\u00e3o interna desses arquivos. Ela ainda disse que essa dica resolveu um problema de um cliente na Turquia.<\/p>\n Caso o seu arquivo de log tenha sofrido muitos autogrowths, ele pode ficar internamente fragmentado. O arquivo de log do SQL Server \u00e9 dividido em pequenos peda\u00e7os chamados VLF(Virtual Log Files) que crescem a medida que seu arquivo de log cresce. Segundo Kimberly, geralmente, a maioria dos arquivos de logs devem ter somente entre 20\u00a0e 30 VLF. 50 ainda \u00e9 aceit\u00e1vel dependendo do tamanho do seu arquivo de log.<\/p>\n Um n\u00famero excessivo de\u00a0VLF pode causar um impacto negativo em todas as atividades do transaction log e al\u00e9m disso, ainda\u00a0pode ocorrer uma degrada\u00e7\u00e3o da performance enquanto um backup do log est\u00e1 sendo executado. Para conferir quantos VLF voc\u00ea tem\u00a0em uma database, basta verificar o n\u00famero de linhas retornadas pelo comando DBCC LOGINFO conforme a figura abaixo:<\/p>\n Nesse caso, o arquivo de log dessa database\u00a0possui 4 VLFs.<\/p>\n Seguindo o procedimento do artigo, realizei os seguintes passos para desfragmentar o arquivo de log:<\/p>\n 1 – Esperei por um per\u00edodo de pouco movimento e limpei o transaction log realizando um backup do mesmo. Caso voc\u00ea\u00a0utilize o recovery model SIMPLE, voc\u00ea n\u00e3o precisa realizar um backup do log, ao inv\u00e9s disso, voc\u00ea limpar\u00e1 o transaction log rodando um CHECKPOINT.<\/p>\n BACKUP LOG databasename TO devicename<\/p>\n 2 – Realizei um Shrink no log para que ele ficasse com o menor tamanho poss\u00edvel (por isso que ele \u00e9 limpo no passo 1).<\/p>\n DBCC SHRINKFILE(transactionloglogicalfilename, TRUNCATEONLY)<\/p>\n 3 – Alterei o arquivo de log da database para um tamanho apropriado onde ele necessite crescer apenas em alguns casos raros.<\/p>\n ALTER DATABASE databasename No meu ambiente eu possu\u00eda uma database com 275 VLF e as maiores estavam todas com mais de 150 VLF. Ap\u00f3s realizar os passos acima, todas as databases est\u00e3o com menos de 20 VLF, sendo que dentre elas, mantenho arquivos de log com 4 GB devido a algumas opera\u00e7\u00f5es e manuten\u00e7\u00f5es que ocorrem durante a madrugada.<\/p>\n Com rela\u00e7\u00e3o a performance, em um dos meus servidores, fa\u00e7o um backup do log a cada 7 minutos para minhas 5 principais databases, com isso, possuo um grande n\u00famero de backups do log. Como eu monitoro toda query que demora mais de 3 segundos<\/a>, constantemente a query que fazia backup do log demorava para ser executada e era armazenada no meu log. Ap\u00f3s a realiza\u00e7\u00e3o dos passos descritos\u00a0acima, \u00e9 muito raro um backup do log\u00a0 entrar nesse trace. Essa melhora foi bem percept\u00edvel no meu ambiente.<\/p>\n Ent\u00e3o, cabe a\u00a0voc\u00eas verificarem a quantidade de VLF de suas databases pois \u00e9 um procedimento bem simples.<\/p>\n Gostou dessa dica?<\/b><\/p>\n Cadastre seu e-mail para receber novos Posts e curta minha P\u00e1gina no Facebook<\/a> para receber Dicas de Leituras e Eventos sobre SQL Server.<\/p>\n![\"\"](\"https:\/\/www.fabriciolima.net\/blog\/wp-content\/uploads\/2010\/12\/dbcc-loginfo.jpg?w=300\" "\\"DBCC")
<\/a><\/p>\n
\nMODIFY FILE
\n( NAME = transactionloglogicalfilename,
\nSIZE = newtotalsize )<\/p>\n