none
Arquivo de log - crescimento RRS feed

  • Pergunta

  • Pessoal,

    Atualmente tenho percebido que meu arquivo de log está crescendo bastante... hoje uma das minhas bases é: 54GB e o arquivo de log está com 27GB. O motivo desse tamanho pode ser devido ao plano de manutenção (reindex, update statistics, e outros)?

    quinta-feira, 1 de março de 2012 11:22

Todas as Respostas

  • Bom dia JustSQL,

    Qual é o modelo de recuperação (recovery model) que vc está usando no seu banco de dados? É o full? Pq se for, todas as transações são logadas, inclusive os reindex, o que pode provocar um crescimento considerável em seu arquivo de log.

    at.
    Rafael Melo

    quinta-feira, 1 de março de 2012 11:42
  • Qual é o modelo de recuperação (recovery model) que vc está usando no seu banco de dados? FULL

    Qual seria a melhor opção para evitar esse crescimento GIGANTESCO?

    Atualmente eu utilizo db_shrink, mas apenas com isso não está resolvendo..

    quinta-feira, 1 de março de 2012 11:47
  • JustSQL,

    O modelo de recuperação depende do seu cenário. Quando é um banco de dados de produção o modelo recomendado é o FULL, pq assim sendo, vc implementa o backup de log. Caso haja um desastre em sua base de dados vc conseguirá recuperar até as ultimas transações (*ou quase).

    Quando temos o modelo de recuperação full, é comum implementar o backup de log, que trunca e limpa automaticamente nosso arquivo de log. 

    Mais detalhes sobre modo de recuperação.

    http://gustavomaiaaguiar.wordpress.com/2009/08/01/piores-praticas-%E2%80%93-utilizar-o-comando-backup-log-com-a-opcao-with-truncate_only-%E2%80%93-parte-i/

    O shirink também não é considerado uma boa prática pelos DBA's. Nesse link acima também descreve sobre esse assunto.

    At.
    Rafael

    quinta-feira, 1 de março de 2012 12:09
  • Concordo que não é viável o uso do shrink em arquivos de dados (mdf), agora arquivos de log (ldf) não sei se há problemas no uso de shrink, estou ciente que pode causar fragmentação nos meus índices, mas de qualquer forma, não sei se há problema eu utilizar o shrink para arquivos de log. Se caso há, o que me sugerem?
    quinta-feira, 1 de março de 2012 12:21
  • JustSQL,

    DBA's experientes sempre pedem para evitar o uso do Shrink: 
    http://www.mssqltips.com/sqlservertip/2055/issues-with-running-dbcc-shrinkfile-on-your-sql-server-data-files/

    E
    u sugiro a voce o backup de log de tempo em tempo. Ele, após o backup trunca automaticamente o arquivo
    http://technet.microsoft.com/en-us/library/ms189085.aspx

    O shrink, conforme vc disse, além de gerar a fragmentação e ira gerar um overhead quando o arquivo necessitar crescer novamente. Porém se vc estiver com problemas de espaço em disco, a unica solução (que conheço) é shrink após o backup de log.

    At.
    Rafael


    quinta-feira, 1 de março de 2012 14:51
  • Rafael,

    Antigamente era, 30 em 30min - backup log. Definir para 15min e ainda continua com o mesmo tamanho, o que me sugere?

    sexta-feira, 2 de março de 2012 14:58
  • JustSQL,

    Você rodou o shrink no seu arquivo de log? Pq o backup de log trunca o arquivo, mas não encolhe (shrink) ele.

    At.
    Rafael


    sexta-feira, 2 de março de 2012 17:32
  • Rafael,

    Rodei sim, só que a tarefa é executada apenas 1 vez no dia. Há alguma se ela for executada juntamente com um comando backup log?


    O que pode está acontecendo com o arquivo de log p/ crescer tanto assim?
    • Editado JustSQL sexta-feira, 2 de março de 2012 17:47
    sexta-feira, 2 de março de 2012 17:45
  • JustSQL, 

    Sim, o shrink no arquivo de log pode ser rodado logo em seguida do backup de log. Olha, é "normal" o arquivo de log crescer quando marcamos o modelo de recuperação completo (FULL). Nesse modelo, todas (todas mesmo) transações são retidas no arquivo de log até serem "backupeadas". Caso voce tenha muita inserção, update, delete...., ou qualquer operação do tipo reindex/reorganize, é normal o log crescer.

    at.
    Rafael 

    sexta-feira, 2 de março de 2012 18:56