none
Log gigantesco RRS feed

 > 

  • Pergunta

  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Saudações,

    Estou com problemas no log no meu banco de dados.
    Ví que existem algumas threads que falam sobre o assunto, mas em nenhuma encontrei uma resposta de como mudar essa situação.

    Todo mês ela fica gigantesca mesmo, dá ultima vez tava com 34Gb, indecente né...também estou achando!!!

    O que preciso é configurar o arquivo de log fique certo. Um amigo me disse que isso pode ser porque o nível de detalhe do log está alto.

    Gostaria de ajuda para tornar isso possível. Maiores esclarecimentos estou às ordens.
    quinta-feira, 30 de julho de 2009 21:07
    |

Todas as Respostas

  • Question
    Entrar para Votar
    2
    Entrar para Votar
    Boa Tarde,

    Existem soluções mas você deve analisar antes de simplesmente limpar. Provavelmente alguém em algum lugar irá mandar você truncar o log e fazer o SHRINK, mas antes de fazer algo tão impensado, sugiro o seguinte:

    Se o log não for importante
    Se você não irá utilizar backups de log e nem terá que restaurar o banco em um momento específico e portanto apenas o backup full e no máximo o diferencial são suficientes, então mude o RECOVERY MODEL do banco para SIMPLE (isso pode ser feito via interface gráfica em Options do Banco). Após fazer isso o seu log nunca mais irá crescer dessa forma descomunal, mas você perde a possibilidade de trabalhar e restaurar backups de log.

    Se o log for importante
    Se o log for importante e no caso de uma queda você necessita voltar o banco em momentos específicos como 30/07/2009 às 10:21:23.998ms então eu sugiro que você faça backups de log regulares para evitar que o log cresca tanto.

    Para qualquer uma das situações, após adotar a resposta correta, rode o comando de SHRINK sobre o arquivo de log para devolvê-lo a um tamanho administrável. Lembre-se que ter o log lhe gera mais overhead administrativo mas possibilita estratégias de backup diferenciadas. Abrir mão do log lhe tira essas dores de cabeça mas torna seu restore mais limitado. Analise o que mais vale a pena e implementa a solução adequada.

    Em hipótese nenhum rode o BACKUP LOG WITH TRUNCATE ONLY e o SHRINK (independente de quem lhe recomendar) sem antes refletir a respeito. E a propóstio não existe nível de detalhe do log. Ele sempre existirá no mesmo nível. O que muda é a forma com a qual ele é expurgado.

    [ ]s,
     
    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Mitos do SQL Server – Será que COUNT(1) ou COUNT('X') são mais performáticos que COUNT(*) ?
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!658.entry

    Classifique as respostas. O seu feedback é imprescindível
    quinta-feira, 30 de julho de 2009 22:16
    |
  • Question
    Entrar para Votar
    0
    Entrar para Votar
    Gustavo, saudações.

    Quando sei que o meu log é importante ou não? Desculpe esse tipo de pergunta é que algumas coisas são novidades mesmo.

    Alterando para SIMPLE, quando eu precisar restaurar um backup, o que acontece soh quando atualizo a base teste isso pode me trazer problemas com meus dados?

    Qual a função do LOG?
    sexta-feira, 31 de julho de 2009 11:36
    |
  • Question
    Entrar para Votar
    1
    Entrar para Votar
    Olá Gustavo,

    O log de transação é onde ficam armazenadas todas as instruções de alteração em sua base de dados INSERT,UPDATE,DELETE.Com o log de transações é possível manter um registro das atividades do seu banco de dados em sequencia.

    O seu log é importante em situações onde não é admitido a perda de dados.
    Exemplo: Você realiza um backup FULL da sua base todos os dias às 12:00,e são feitas alterações na base às 13h,14h,15h,etc.
    E é feito um backup do log de transação de hora em hora.

    Com isso todas as alterações no periodo de 12 às 15h serão mantidas no log de transação e caso aconteça uma falha, por exemplo às 15:30.Podemos restaurar o backup do log das 15h para recuperar o erro ou realizando o método de fazer um backup minutos após a falha (15:40) e restaurar as alterações até o ponto às 15:25 diminuindo assim a perda de dados.

    Para manter o tamanho do log gerenciável programe rotinas de backup regularmente.
    Basicamente todas essas características são oferecidas utilizando o mode de recuperação FULL.

    Mas se a "parcial" perda de dados  não for um problema,você pode optar por alterar o modo de recuperação para SIMPLE,com isso como o Gustavo Maia disse acima,não será possível realizar backups do seu log e ele não continuará crescendo para um tamanho absurdo.

    Espero ter ajudado.
    Até a próxima.
    MCP 2003
    • Sugerido como Resposta Cleyton Esteves quarta-feira, 5 de agosto de 2009 01:51
    sexta-feira, 31 de julho de 2009 16:01
    |
  • Question
    Entrar para Votar
    1
    Entrar para Votar
    Olá,

    Sugiro uma leitura no BOL sobre o funcionamento do transaction log.

    http://msdn.microsoft.com/en-us/library/ms345583.aspx

    Abraços
    Demétrio Silva
    sexta-feira, 31 de julho de 2009 16:07
    |
  • Question
    Entrar para Votar
    2
    Entrar para Votar
    Olá Gustavo,

    Se você não souber se o Log é importante é porque provavelmente ele não é. Ele é necessário para restauração do banco em momentos específicos, mas se ainda assim há dúvida sobre sua importância então é pouco provável que você utilize o log para restaurações o que torna dispensável. Em todo caso fiz dois artigos que explicam em detalhes como lidar com esse problema:

    Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE_ONLY - Parte I
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!670.entry

    Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE_ONLY - Parte II
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!671.entry

    [ ]s,
     
    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE_ONLY
    Parte 01 - http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!670.entry
    Parte 02 - http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!671.entry

    Classifique as respostas. O seu feedback é imprescindível
    domingo, 2 de agosto de 2009 03:16
    |