At\u00e9 a\u00ed, nada de mais. Seria um atendimento de rotina onde provavelmente o Log n\u00e3o era limpo devido a algum problema no Backup de Log ou alguma transa\u00e7\u00e3o que estaria segurando o arquivo de Log e n\u00e3o deixando ele ser limpo pelo backup.<\/p>\n
O Log da base estava com 800 MB e com 80% de utiliza\u00e7\u00e3o.<\/p>\n
A primeira coisa que fiz foi validar o backup de log que era executado a cada 10 minutos. O job de backup do log estava executando com sucesso para essa database, mas o log n\u00e3o estava sendo limpo.<\/p>\n
O segundo passo foi analisar se tinha algum processo segurando o log desse banco de dados. No momento que estava atuando, o servidor estava praticamente parado. N\u00e3o tinha nenhuma transa\u00e7\u00e3o ativa na base, nenhum lock no banco, nenhum processo em execu\u00e7\u00e3o e as conex\u00f5es que existiam na base estavam todas como sleeping.<\/p>\n
Matei algumas conex\u00f5es que pareciam suspeitas, mas em seguida eu rodava o backup de log e nada do log limpar.<\/p>\n
Usei a fun\u00e7\u00e3o fn_dblog para ler o Transaction Log dessa base e s\u00f3 eram retornadas 12 linhas. Como \u00e9 poss\u00edvel um log ter mais de 500 MB de utiliza\u00e7\u00e3o e s\u00f3 ter 12 linhas???<\/p>\n
Como eu disse no t\u00edtulo desse post, esse problema no Log era N\u00edvel Hard!<\/p>\n
Coloquei meu Networking de SQL Server para funcionar e, ap\u00f3s algumas sugest\u00f5es de amigos, o Dem\u00e9trio (Blog<\/a>) me passou um artigo do Sr. Paul Randal que quando l\u00ed, matou a charada na hora!!!<\/p>\n Paul Randal \u00e9 o cara!!! Meu Networking tamb\u00e9m \u00e9 o cara!!!<\/p>\n Segue o artigo: Seguem as partes do artigo que mataram a charada:<\/p>\n If you have a transaction log that is not growing, and you\u2019re taking regular log backups, but thelog_reuse_wait_desc\u00a0remains\u00a0LOG_BACKUP,\u00a0this is because zero VLFs were cleared when the previous log backup was performed.<\/em><\/p>\n How can that happen?<\/em> Olhando os VLFs do arquivo de log dessa base com o comando DBCC LOGINFO, verifiquei que um dos VLFs estava muito grande. Como o ambiente tinha pouca atualiza\u00e7\u00e3o e esse VLF era grande, o SQL n\u00e3o estava utilizando outros VLFs e por isso que o backup do Log n\u00e3o estava conseguindo limpar nenhum VLF, como o Paul Randal explicou no artigo dele.<\/p>\n O que fazer ent\u00e3o?<\/p>\n Agora o problema mudou para o modo Easy.<\/p>\n Para resolver o problema, criei uma tabela nessa base e fiz um loop de insert para crescer o log.<\/p>\n Isso mesmo, gerei registros de log para poder limpar esse log depois. Estranho n\u00e9!??<\/p>\n Ap\u00f3s os inserts, o status de mais 2 VLFs foram alterados para o valor 2 conforme figura abaixo (A \u2013 como estava antes do insert | D \u2013 Os status alterados depois do insert).<\/p>\n Status VLF:<\/p>\n Feito isso, rodei novamente o job de backup do log e a utiliza\u00e7\u00e3o do log baixou para 1%. O SQL Server manteve o log ativo em outro VLF e conseguiu limpar o log do VLF gigante liberando o espa\u00e7o utilizado no transaction log.<\/p>\n Eu estava na linha de que tinha algum processo perdido que n\u00e3o estava encontrando e estava segurando o log. Mas a solu\u00e7\u00e3o estava na dire\u00e7\u00e3o contr\u00e1ria.<\/p>\n Para evitar que esse problema volte a acontecer, tive que balancear os VLFs desse Transaction Log.<\/p>\n Segue abaixo um artigo excelente para te ajuda a balancear os VLFs. Nele tamb\u00e9m tem links para outros artigos para que voc\u00ea possa entender tudo sobre VLF:<\/p>\n http:\/\/edvaldocastro.com\/vlf_control\/<\/a><\/p>\n Como eu sempre digo, vivendo e aprendendo.<\/p>\n Fica de aprendizado para mim e agora tamb\u00e9m para voc\u00eas por meio desse Blog.<\/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
\nhttp:\/\/www.sqlskills.com\/blogs\/paul\/why-is-log_reuse_wait_desc-saying-log_backup-after-doing-a-log-backup\/<\/a><\/p>\n
\n Imagine a database where there\u2019s very little insert\/update\/delete\/DDL activity, so in between your regular log backups there are only a few log records generated, and they\u2019re all in the same VLF. The next log backup runs, backing up those few log records, but it can\u2019t clear the current VLF, so can\u2019t clear\u00a0log_reuse_wait_desc. As soon as there are enough changes in the database that the current VLF fills up and the next VLF is activated, the next log backup should be able to clear the previous VLF and then thelog_reuse_wait_desc\u00a0will revert to\u00a0NOTHING. Until the next log backup occurs and isn\u2019t able to clear the current VLF, in which case it will go back to\u00a0LOG_BACKUP\u00a0again.<\/em><\/p>\n![\"\"](\"https:\/\/www.fabriciolima.net\/blog\/wp-content\/uploads\/2015\/01\/ArtigoVLF.png\" "\\"ArtigoVLF\\"")
<\/a><\/p>\n