locked
SQL Server gerando SQLDumpXXX até o HD Ficar sem espaço! RRS feed

  • Pergunta

  • Pessoal, boa tarde.

    Estou tendo um problema muito chato de arrumar!


    Tenho uma instância no servidor que, de ontem para hoje, começou a gerar VÁRIOS ARQUIVOS de log no caminho: ''C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log\"


    Parece que o SQL está gerando vários arquivos  até o hd ficar sem espaço! ex.:

    SQLDumpXXX.log

    SQLDumpXXX.txt

    SQLDumpXXX.mdmp

    Alguém saberia me ajudar neste problema, ou pelo menos, como desabilitar essa funcionalidade para não ficar lotando meu HD a cada 10 min ?


    quinta-feira, 9 de março de 2017 20:28

Respostas

  • Valida se o SQL Server está na última versão de update. Se não tiver atualize para evitar a possibilidade de ser um bug.

    Se mesmo assim não resolver, ai terá que tentar analisar as mensagens no DUMP para identificar o motivo.

    DUMP são erros bem complexos de se analisar.

    Fabricio Lima - MVP SQL Server Data Platform | Trabalho com SQL Server desde 2006 Treinamento DBA ONLINE: http://www.fabriciolima.net/blog/cursos-online/treinamento-tarefas-do-dia-a-dia-de-um-dba-online/

    sexta-feira, 10 de março de 2017 17:07
  • Apenas para comentar, o servidor onde estava localizado a base estava com problemas graves hardware, falhas de disco e memória, enfim, chegou num um nível em que corrompeu paginas internas das bases.

    Resolvemos o problema corrigindo os problemas de hardware do servidor e migramos os dados para uma outra base nova!

    Att


    **** SER A RESPOSTA FOR UTIL, NÃO ESQUEÇA DE MARCA-LÁ =P ****

    quinta-feira, 6 de julho de 2017 14:55

Todas as Respostas

  • Boa Noite Rafael,

    Da uma olhada nessa thread do StackExchange, é a mesma situação que a sua e o pessoal colocou várias dicas de como tratar.

    http://dba.stackexchange.com/questions/87112/the-sql-server-log-folder-is-expanding-because-of-the-sql-dump-files-what-to-do


    Att, Bruno Silva.

    sexta-feira, 10 de março de 2017 02:17
  • Obrigado Bruno! Vou dar uma olhada no post e depois comento aqui se deu certo ou não! Abraços !


    **** SER A RESPOSTA FOR UTIL, NÃO ESQUEÇA DE MARCA-LÁ =P ****

    sexta-feira, 10 de março de 2017 12:19
  • Valida se o SQL Server está na última versão de update. Se não tiver atualize para evitar a possibilidade de ser um bug.

    Se mesmo assim não resolver, ai terá que tentar analisar as mensagens no DUMP para identificar o motivo.

    DUMP são erros bem complexos de se analisar.

    Fabricio Lima - MVP SQL Server Data Platform | Trabalho com SQL Server desde 2006 Treinamento DBA ONLINE: http://www.fabriciolima.net/blog/cursos-online/treinamento-tarefas-do-dia-a-dia-de-um-dba-online/

    sexta-feira, 10 de março de 2017 17:07
  • Olá Rafael, tudo bem? 

    Leia atentamente esse post também: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/b979a07c-2934-4ccc-9e6b-3be0a6913665/large-number-of-logcrash-dump-files-generated?forum=sqldisasterrecovery

    Fique a vontade para perguntar caso tenha dúvida em realizar algum procedimento. Seguindo o que o Fabricio explicou sobre a dificuldade de analisar um arquivo de dump, sugiro que você procure o suporte da Microsoft.

    []'s

    Paulo Daniel Nobre
    https://www.linkedin.com/in/paulodanielnobre



    sexta-feira, 10 de março de 2017 20:03
  • Rafael S.S,   

    Uma das causas desse problema pode ser configuração de memória.  No Microsoft SQL Server, existe a opção de configurar a memória máxima e a memória mínima que um software poderá utilizar funcionando em conjunto com o Microsoft SQL Server.  

    Verifica quanto tem de memória RAM configurado no Microsoft SQL Server e quanto tem de disco rígido ocupado e livre.  

    Nessa configuração quanto menor for a quantidade de memória RAM configurada como memória RAM máxima, maior é a quantidade do espaço livre em disco que o Microsoft SQL Server irá capturar para trabalhar criando os arquivos temporários em uso no banco de dados. 

    Lembrete: Após 12 meses de uso alimentando dados diariamente no banco de dados Microsoft SQL Server, o DBA tem que utilizar o comando REINDEX para reorganizar todos os índices das tabelas e recriar os arquivos de índice do Microsoft SQL Server.  Isso feito, depois de concluído, costuma reduzir o tamanho físico dos arquivos do Microsoft SQL Server.  Isso é prevenção para melhorar a eficiência de funcionando do Microsoft SQL Server.    

    http://anagaunatech.blogspot.com.br/2015/10/big-data-sql-manutencao-anual.html

    Boa noite,


    Ana Mercedes Gauna | MCSE: 098-02070 | Microsoft Partner: 4935985 | Cisco CCNA2 | CRA-RJ: 03-03161 | ABRAWEB: 66132 | ABRACEM: Q27795 | Twitter: @amgauna | Skype: amgauna@outlook.com | www.amgauna.eti.br | anagaunatech.blogspot.com | anagauna.wordpress.com


    • Editado Ana Gauna terça-feira, 14 de março de 2017 22:15
    sábado, 11 de março de 2017 01:00
  • Rafael,

    Por acaso, você já tentou para o serviço do SQL Server e verificar após a inicialização se este cenário continua acontecendo?

    Seria interessante tentar identificar se não existe alguma query que possa estar forçando esta situação, como já destacado anteriormente a leitura do Dump não é nada simples, bem como, a geração deste tipo de arquivo é somente em casos ou cenários em que o SQL Server esta sofrendo com alguma falha de Hardware.


    Pedro Antonio Galvao Junior [MVP | MCC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    terça-feira, 14 de março de 2017 18:59
    Moderador
  • Apenas para comentar, o servidor onde estava localizado a base estava com problemas graves hardware, falhas de disco e memória, enfim, chegou num um nível em que corrompeu paginas internas das bases.

    Resolvemos o problema corrigindo os problemas de hardware do servidor e migramos os dados para uma outra base nova!

    Att


    **** SER A RESPOSTA FOR UTIL, NÃO ESQUEÇA DE MARCA-LÁ =P ****

    quinta-feira, 6 de julho de 2017 14:55