none
LOG comendo todo espaço em disco RRS feed

  • Pergunta

  • Hoje vi que o servidor estava sem espaço em disco. Quando fui ver o tamanho das bases, o LOG de uma das bases estava em 38 GB, coloquei a base para simple fiz um shrink para 5 MB e voltei a base para full. Duas horas depois o LOG estava novamente em 38 GB fiz shrink de novo, e agora ela está 38 GB de novo.

       Alguem pode me dar uma luz do que pode estar acontecendo, e que procedimento eu deveria tomar?

     

    Obrigado

    • Movido Gustavo Maia Aguiar terça-feira, 10 de janeiro de 2012 12:42 (De:Programação avançada com o SQL Server)
    segunda-feira, 9 de janeiro de 2012 18:11

Respostas

  • Bom Dia,

    Se o RECOVERY MODEL está em SIMPLE e mesmo assim você tem 38GB é porque há alguma transação aberta que não está sendo fechada. Embora processos (KILLED / ROLLED BACK) não sejam desejáveis, não creio que esse seja o culpado. Se ele realmente tivesse problemas, você não conseguiria ter reduzido o log de transações. Você pode reiniciar o serviço para que o processo KILLED / ROLLED BACK suma, mas acho que ele pode não ser o culpado desse log estar tão grande.

    Veja na sys.dm_tran_active_transactions para verificar se há alguma transação aberta há muito tempo. Se estiver, capture seu ID e veja na sys.dm_tran_session_transactions e mate a sessão

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    • Sugerido como Resposta Gustavo Maia Aguiar terça-feira, 10 de janeiro de 2012 12:41
    • Marcado como Resposta Igor Auler terça-feira, 10 de janeiro de 2012 16:28
    terça-feira, 10 de janeiro de 2012 12:41

Todas as Respostas

  • Estou vendo aqui, tem um processo KILELD/ROLLBACK rodando a VARIOS dias e acredito q isto esteja lotando rapidamente o LOG

    segunda-feira, 9 de janeiro de 2012 18:58
  • Sim é isso mesmo. É uma transação muito antiga inchando o log. Faça um kill nessa sessão, mas recomendo examinar o que está causando isso (pode ser uma aplicação mal escrita).
    SQL SERVER sempre
    segunda-feira, 9 de janeiro de 2012 23:26
  • Bom Dia,

    Se o RECOVERY MODEL está em SIMPLE e mesmo assim você tem 38GB é porque há alguma transação aberta que não está sendo fechada. Embora processos (KILLED / ROLLED BACK) não sejam desejáveis, não creio que esse seja o culpado. Se ele realmente tivesse problemas, você não conseguiria ter reduzido o log de transações. Você pode reiniciar o serviço para que o processo KILLED / ROLLED BACK suma, mas acho que ele pode não ser o culpado desse log estar tão grande.

    Veja na sys.dm_tran_active_transactions para verificar se há alguma transação aberta há muito tempo. Se estiver, capture seu ID e veja na sys.dm_tran_session_transactions e mate a sessão

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    • Sugerido como Resposta Gustavo Maia Aguiar terça-feira, 10 de janeiro de 2012 12:41
    • Marcado como Resposta Igor Auler terça-feira, 10 de janeiro de 2012 16:28
    terça-feira, 10 de janeiro de 2012 12:41
  • Gustavo,

             obrigado pela dica, mas n pude testar este procedimento, pois como era uma situação urgente eu tive que fazer algo para resolver. Deletei o banco, criei ele de novo e subi um backup que tinha de mais cedo. Mas deixarei isto anotado para uma situação futura.

     

     

    Obrigado.

    terça-feira, 10 de janeiro de 2012 16:30