TempDB cheio: o que fazer e como prevenir

TempDB é o banco de dados de trabalho do SQL Server: usado para tabelas temporárias explícitas (#temp), spools internos de execução de query, worktables de ordenação/agrupamento (ORDER BY, GROUP BY, DISTINCT), row versioning (isolamento snapshot) e reconstrução de índice online. Quando ele enche, o servidor inteiro para — não só quem usa tabela temporária.

O que costuma encher o TempDB

• Query com ORDER BY/GROUP BY numa tabela grande sem índice adequado, forçando ordenação em disco.
• Transação longa aberta com isolamento snapshot/RCSI — o row versioning acumula até a transação fechar.
• Índice sendo reconstruído com REBUILD ONLINE numa tabela grande.
• Cursor mal escrito iterando milhões de linhas com uma tabela temporária dentro do loop.
• Plano de execução ruim fazendo spill de hash join/sort pra tempdb por estimativa de linhas errada.

Diagnóstico imediato: quem está usando o quê

SELECT TOP 10
  s.session_id, r.command,
  (t.internal_objects_alloc_page_count + t.user_objects_alloc_page_count) * 8 / 1024 AS mb_alocados,
  t2.text AS query_atual
FROM sys.dm_db_task_space_usage t
JOIN sys.dm_exec_sessions s ON s.session_id = t.session_id
LEFT JOIN sys.dm_exec_requests r ON r.session_id = t.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) t2
ORDER BY mb_alocados DESC;

Isso mostra exatamente qual sessão está segurando o espaço agora. Na maioria dos casos, matar (KILL) a sessão ofensora libera o espaço em segundos — mas isso derruba o que ela estava fazendo, então confirme antes que não é uma transação importante em andamento.

Prevenção

• Configure múltiplos arquivos de dados do TempDB (regra geral: 1 arquivo por até 4 vCPUs, todos do mesmo tamanho) — reduz contenção de página em PFS/GAM/SGAM.
• Deixe o TempDB num disco rápido e separado dos bancos de usuário, com autogrowth em MB fixo (não percentual) pra evitar crescimento explosivo.
• Revise transações longas com isolamento snapshot — são a causa mais comum de TempDB crescendo sem parar mesmo com pouca atividade aparente.
• Monitore o tamanho antes de virar incidente: alertar em 80% de uso dá tempo de agir antes do banco parar.

O codeDB monitora o crescimento do TempDB e os principais consumidores automaticamente, avisando antes de bater no limite — em vez de você descobrir quando o banco já travou.