Eu tenho uma instalação do SQL 2005 e meu arquivo templog.ldf continua crescendo para consumir todo o espaço livre na unidade em que está. Às vezes, ele pára com alguns mb livres, mas às vezes ele vai além, sendo esse o drive c que eu acho que esse comportamento pode estar implicado em alguns outros problemas que tenho visto.
A minha pergunta é, o que devo fazer, posso mover o log para outra unidade, mas tenho motivos para supor que não vai fazer a mesma coisa lá. Eu estou supondo que esse comportamento é provavelmente como resultado de algo que eu possa mudar e que 45GB é um tamanho incomum para o log de tempdb para chegar. Nós usamos muitas tabelas temporárias e funções com valor de tabela em nosso código, então há muito espaço para usar o tempdb, eu posso entender o crescimento do banco de dados tempdb, mas não entendo o motivo do crescimento do templog.
Até agora, eu corri DBCC OPENTRAN ('tempdb') para ver se alguma transação antiga está por aí, elas não estão. Eu li sobre como encolher o tempdb e fiz isso algumas vezes, mas eu realmente estou me perguntando o que se eu puder fazer algo para impedir que isso aconteça em primeiro lugar ou mais detalhes sobre por que ele pode estar crescendo tanto em o primeiro lugar.
== EDITOS ==
1) O tempdb está usando um modelo de recuperação simples
2) O crescimento do templog ocorre ao longo de algumas horas da manhã quando temos algumas consultas agendadas em execução, basicamente uma carga de relatórios que fica fora do horário comercial do dia seguinte. O tamanho do arquivo cresce constantemente ao longo do tempo. Controlamos quantos relatórios simultâneos estão sendo executados ao mesmo tempo, aumentando o número de relatórios simultâneos para aumentar a taxa de crescimento do log.
Verifique suas consultas de relatórios. Você tem algum que tenha DISTINCT neles? Algum deles tem uma união cartesiana?
Alguma das consultas de relatórios acessa servidores vinculados como membros de uma associação? Nesse caso, isso pode fazer com que o log e o banco de dados tempdb cresçam.
Quando os relatórios estão sendo executados pela manhã, algum deles falha?
Tivemos um problema semelhante, depois de termos levantado a chamada do PSS com a Microsoft e investigado em profundidade a questão que definimos na seguinte possível causa e resolução.
Causa:
A causa provável dos sintomas deve-se a discos / lun nos quais os bancos de dados do usuário são colocados com problemas graves de resposta de E / S; isso faz com que o ponto de verificação automático nos bancos de dados do usuário demore muito para ser concluído.
Agora, o ponto de verificação no tempdb ocorre apenas quando o log do tempdb fica 70% cheio e também tem uma prioridade mais baixa do que os pontos de verificação do banco de dados do usuário. Portanto, efetivamente quando o ponto de verificação automático no banco de dados do usuário é emitido e está tentando concluir, devido ao uso intenso do tempdb, o arquivo de log do tempdb é preenchido rapidamente; com 70% de uso de log, o ponto de verificação tempdb ocorre, mas é enfileirado atrás do ponto de verificação do banco de dados do usuário.
No tempo que leva para o ponto de verificação do banco de dados do usuário concluir o arquivo de log do tempdb sendo preenchido e, se o crescimento automático estiver definido, o arquivo de log aumentará quando ele exigir mais espaço. Essa é a razão pela qual o arquivo de log continua crescendo.
Em resumo, a causa raiz mais provável para os sintomas que você descreve é devido à fraca resposta de I / O dos discos / lun para o seu usuário e / ou banco de dados tempdb / arquivos de log.
Solução:
Trabalhamos em torno do problema enquanto resolvemos o subsistema de E / S configurando um alerta que disparou quando o arquivo de log tempdb ficou cheio em 75% e em resposta executou um trabalho que forçou um manual "CHECKPOINT" (que tem precedência sobre pontos de verificação automáticos do sistema), limpando o log do tempdb evitando que ele cresça indefinidamente. Ainda é uma boa idéia deixar o arquivo de log em crescimento automático para qualquer outra eventualidade. Além disso, eu recomendo strongmente que você considere reduzir o tamanho do arquivo de log do tempdb para algo significativo de acordo com o seu ambiente depois de colocar a correção.
Espero que isso ajude.
O que é o modelo de recuperação definido no temp db? Se não estiver definido como Simples, defina-o como Simples. Isso deve impedi-lo de crescer. Se já estiver definido como Simples, então diria que há um problema subjacente que precisa ser resolvido e qualquer tentativa de reduzir o arquivo é apenas tratar os sintomas do problema e não a causa raiz.
Passei as últimas horas lendo e fazendo anotações sobre isso
Há muitos detalhes e sugestões para solucionar problemas. Parece que, a menos que seu tempdb esteja em expansão e nunca pare de crescer, provavelmente está ocupando apenas o espaço necessário e deveria ter sido configurado inicialmente para esse tamanho. Há uma seção sobre como estimar o espaço necessário para o tempdb, além de rastrear o que pode estar ocupando espaço no tempdb. Como resultado disso, a primeira coisa que vou fazer é mover o tempdb para uma unidade maior e ver o que acontece a partir daí.
Existe uma seção intitulada 'Espaço requerido para o registro em tempdb' que indica quais recursos usam o log, há outra seção anterior que detalha o superconjunto de recursos que usam tempdb.
A seção intitulada 'Monitorando E / S' tem algumas idéias sobre contadores de desempenho a serem observados, uma rápida olhada no meu servidor coloca essas informações em você, provavelmente, tem um território gargalo. Vou monitorá-los por um tempo e ver como as coisas funcionam. O arquivo de log tempdb também tinha, na verdade, menos de 50% de utilização, o que se encaixa com a ideia que ele expandiu sob carga nesta manhã e manteve esse espaço desde então.
Estou indo na base de que o tamanho para o qual ele é cultivado é o tamanho que ele precisa ser, monitore esse tamanho no futuro e garanta que haja espaço para crescimento em qualquer unidade em que ele esteja. Como sugerido por alguns aqui, vou examinar o que está sendo executado à medida que o log de temp expande e ver se algo pode ser ajustado lá. Também vou ficar de olho nesses contadores de desempenho do io para ver se algo precisa ser tratado.
Havia mais uma seção interessante adicional intitulada 'Atualizando para o SQL Server 2005' , que indica que o tempdb é usado para mais coisas em 2005 do que 2000 (novos recursos e recursos existentes que anteriormente não existiam) t use tempdb). Eu só atualizei recentemente para 2005, então isso pode ser parte da razão pela qual isso se tornou um problema. Não me lembro de ver isso em qualquer outro lugar com referência à atualização para 2005, o que é um pouco doloroso.
Isso é provavelmente causado por uma consulta de junção cruzada fora de controle. Sua melhor aposta é usar o Profiler para encontrá-lo e corrigi-lo.
A outra maneira de encontrá-lo é restringir o tamanho do arquivo de log do TempDB e, em seguida, aguardar para ver qual consulta falha. No entanto, eu apostaria que já está falhando e ninguém está lhe dizendo.
Se você reiniciar o mecanismo SQL, o arquivo será definido para o tamanho inicial. Você deve colocar um tamanho máximo em todos os seus arquivos de crescimento automático.
Algumas consultas SQL ou proc armazenadas estão fazendo coisas ruins - a única coisa que você pode fazer é criar o perfil do tempdb para capturar o evento "Database: Log File Auto Grow" e, quando isso acontecer, usar o profiler e consultas em tabelas como sysprocesses para descobrir qual é o processo ruim.
Infelizmente, cabe ao trabalho de detetive antiquado rastrear o processo desonesto.
Já tentou redimensionar o (s) ficheiro (s) de registo tempdb com o DBCC SHRINKFILE ()? Em caso afirmativo, quanto tempo leva para passar de [valor muito pequeno] para 45 GB ou mais?