A pasta "Log" SIZE no diretório raiz do servidor SQL (X:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Log) fica muito grande , ~80 GB.
Quando verifiquei, vejo que há muitos arquivos SQLDumpxxxx.mdmp /SQLDumpxxxx.txt nessa pasta.
- O que fazer com eles ?
- posso excluí-los e se é uma boa coisa a fazer?
10X
Em primeiro lugar, tudo o que Shanky disse em sua resposta está 100% correto. Eu gostaria de adicionar:
A idade dos arquivos - Se sua pasta de log tiver vários despejos de dois anos atrás, nenhum despejo por vários meses e, em seguida, alguns despejos recentes, você poderá excluir com segurança os despejos de dois anos.
Duplicar dumps - Quando ocorrem dumps, três arquivos são criados: .txt, .log e .mdmp. Abra o arquivo .txt para vários despejos. Se forem diferentes, mantenha as lixeiras. Se forem iguais, exclua os antigos.
Seu espaço em disco disponível - Se o disco onde seus dumps estão se acumulando também é o mesmo disco onde seus arquivos de banco de dados ou arquivos de log de transações também residem, e você vai ficar sem espaço em disco se você não fizer algo, e você tiver não para onde mover os arquivos de despejo e, em seguida, exclua-os.
Tipos de dumps - Se o arquivo .log indicar "Agendador sem rendimento", "Escuta IOCP sem rendimento" ou "Monitor de recursos sem rendimento", estes são relacionados ao desempenho específico da CPU. Você pode solucionar esses problemas seguindo as etapas deste blog: https://blogs.msdn.microsoft.com/karthick_pk/2012/08/21/non-yielding-iocp-listener-non-yielding-scheduler-and-non-yielding -resource-monitor-known-issues-and-fixes/
Se o arquivo .log indicar "Deadlocked Schedulers", isso também é relacionado ao desempenho específico da CPU. Você pode solucionar esses problemas seguindo as etapas deste blog: https://blogs.msdn.microsoft.com/karthick_pk/2010/06/22/how-to-analyze-deadlocked-schedulers-dumps/
Despejos de corrupção - Assim como a primeira resposta afirma, execute DBCC CHECKDB. Se a saída de DBCC CHECKDB indicar corrupção em seus índices, reconstrua-os. Se ele indicar que "reparar permitir perda de dados é o mínimo" necessário para reparar o banco de dados, restaure a partir do último backup válido conhecido.
Despejos AV - Você pode tentar resolver isso sozinho: https://blogs.msdn.microsoft.com/sqlcat/2009/09/11/looking-deeper-into-sql-server-using-minidumps/
Se você tiver dificuldade , abra um caso com a Microsoft, mas, assim como Shanky disse, verifique se você está em uma versão compatível e tem as atualizações mais recentes.
Você deve analisar e determinar a causa dos dumps de pilha, se você tem suporte da microsoft, pode consultá-los e claro que sempre pode excluí-los, eles não passam de dumps de memória, podem ser gerados por problema de memória, violações de acesso, Corrupção de banco de dados, etc. Você também pode verificar o log de erros do SQL Server para obter informações ou erros registrados ao mesmo tempo em que o despejo foi gerado. Às vezes, os despejos também são gerados devido à corrupção do banco de dados, então também sugiro executar o DBCC CHECKDB.
Espero que isso irá ajudá-lo, obrigado.
Para mim, foi o serviço polybase com o SQL Server 2019 Developer Edition, que não pôde ser iniciado porque o protocolo TCP/IP estava desabilitado (por padrão) e estava criando grandes despejos de memória várias vezes ao dia.
Aqui está um artigo muito bom com instruções passo a passo para resolver esse problema.
https://nielsberglund.com/2019/11/20/fix-polybase-in-sql-server-2019-developers-edition/
O principal extrato do artigo acima é
taskkill /PID {process id} /FCenário 1
Perguntei sobre a versão do SQL Server e você não respondeu, o motivo pelo qual perguntei porque se você estiver executando a versão RTM do SQL Server ou seu SQL Server não estiver corrigido para o Service Pack mais recente e a atualização cumulativa, não há sentido em abrir o caso com a Microsoft. Se você fizer isso, o Engenheiro da Microsoft ou o pessoal de suporte solicitará primeiro que você aplique o SP mais recente.
Outro cenário é se você não atualizou seu SQL Server para o SP mais recente, por exemplo, para o SQL Server 2012 você tem o SP3 lançado e ainda está no SP1 e você registra um caso com a Microsoft para esse problema, você seria cobrado e é bem possível que o o cara do suporte diria que isso é um problema conhecido e foi corrigido no Sp3. Assim, você acabaria desperdiçando dinheiro. Portanto, sugiro fortemente que você verifique se o SQL Server está no SP mais recente.
Eu também queria verificar se você está realmente executando a versão suportada do SQL Server ou não. Do jeito que está criando despejo, tenho um palpite de que você está executando o SQL Server, que não está corrigido para o SP mais recente
Cenário 2
Se o SQL Server for corrigido para o SP mais recente e ainda estiver travando produzindo despejos de pilha, sugiro que você abra o caso com a Microsoft, eles são os melhores em termos de análise do arquivo de despejo de pilha e certamente lhe diria o motivo. A menos que você seja realmente bom em analisar despejos, eu não sugiro que você perca tempo fazendo isso.
Posso compartilhar com vocês alguns blogs que dariam algumas dicas sobre como analisar os despejos
Cenário 3
Nem todos os despejos de memória são devido a bugs no SQL Server, muitos ocorrem devido ao SQL Server mal configurado ou a algumas consultas rouge em execução. Mas como você não compartilhou o log de erros detalhado, é difícil dizer neste momento. Verifique se o SQL Server está configurado corretamente. Novamente, se for esse o caso, o suporte da MS apontará isso.
Moral:
Se o SQL Server não for atualizado com o SP mais recente, primeiro atualize-o, procure as atualizações cumulativas lançadas após o SP (você pode obter isso no primeiro link que compartilhei) e verifique se o bug que você está enfrentando não foi corrigido SOMENTE nas versões CU e abra caso com a Microsoft.
Se você planeja abrir um caso com a Microsoft, sugiro que você os mova para outro local apenas por precaução. Se você tiver esses despejos, poderá fornecer mais informações para apoiar o pessoal que estaria analisando seu caso. Observe também que é bastante provável que o despejo produzido não capture todas as informações relacionadas ao problema e o pessoal de suporte solicitará que você ative o sinalizador de rastreamento e aguarde a ocorrência do próximo despejo, que capturará todas as informações relacionadas.
Se você realmente gosta de excluí-lo, exclua os antigos e deixe os novos.