Como prever quando o banco SQL Server ficará sem espaço

O banco SQL Server ficará sem espaço quando a taxa de crescimento dos arquivos superar a capacidade livre do volume. A forma confiável de prever isso é registrar o tamanho dos arquivos e o espaço disponível ao longo do tempo, não esperar o alerta de disco cheio. Esse histórico também ajuda a distinguir crescimento normal de uma query que passou a bloquear as outras e elevou a carga do ambiente.

O incidente raramente começa no momento em que o volume chega a 0%. Ele começa antes: um arquivo de dados cresce a cada carga, o log não é truncado como deveria, um tempdb aumenta durante um período de manutenção ou os backups acumulam no mesmo volume da produção. Quando o alerta aparece, a janela para decidir com segurança já ficou pequena.

O que precisa ser medido

Há três medidas diferentes, e misturá-las produz previsões erradas:

• espaço livre no volume do sistema operacional;
• espaço livre dentro de cada arquivo de dados;
• crescimento do log de transações e dos arquivos temporários.

Um volume pode ter espaço livre enquanto um arquivo de dados já está perto do limite configurado. O inverso também acontece: o arquivo ainda tem espaço interno, mas o volume não consegue atender ao próximo autogrowth. A capacidade precisa ser acompanhada nos dois níveis.

Uma consulta inicial para mapear os arquivos é:

SELECT    DB_NAME(database_id) AS database_name,    type_desc,    name AS logical_name,    physical_name,    size * 8.0 / 1024 AS size_mb,    max_size,    growth,    is_percent_growthFROM sys.master_filesORDER BY database_name, type_desc, logical_name;

max_size = -1 não significa que existe capacidade infinita. Significa que o arquivo pode crescer até o limite do volume ou do sistema de arquivos. Já o crescimento percentual torna o comportamento difícil de prever: à medida que o arquivo aumenta, o próximo incremento fica maior.

Autogrowth não é planejamento de capacidade

O autogrowth é um mecanismo de proteção. Ele permite que o SQL Server aumente um arquivo quando a alocação atual não basta. Não é uma estratégia para decidir quando comprar armazenamento, porque o crescimento acontece durante a operação e pode bloquear sessões enquanto o novo espaço é inicializado.

Em arquivos de dados, incrementos muito pequenos geram muitos eventos de crescimento e fragmentação interna. Incrementos muito grandes podem provocar uma pausa longa e consumir o espaço que deveria sustentar outras bases. O tamanho adequado depende do ritmo de escrita e da janela disponível, por isso copiar um número de outra instância é uma simplificação perigosa.

O mais importante é evitar crescimento percentual e definir incrementos absolutos revisados a partir do histórico. O arquivo deve crescer antes de ficar cheio, em uma mudança planejada, não no meio da transação que já está aguardando espaço.

Como transformar histórico em prazo

Uma fotografia informa o estado. Uma série temporal informa o prazo. Para cada arquivo, guarde pelo menos o tamanho total, o espaço usado, o espaço livre no volume e a data da coleta. Com uma semana de dados já é possível observar uma direção; com ciclos completos de fechamento, carga e retenção, a previsão fica mais representativa.

Uma aproximação simples é:

dias até o limite = espaço disponível / crescimento médio diário

Esse cálculo só é útil se o crescimento médio for calculado para o mesmo padrão de carga. Um mês com fechamento contábil não deve ser tratado como uma semana normal. Também vale calcular cenários: média, maior crescimento observado e crescimento do último período.

Se há 300 GB livres e o crescimento recente varia entre 8 e 12 GB por dia, o prazo não é simplesmente 37 dias. O cenário conservador usa o ritmo maior e ainda reserva espaço para backups, arquivos temporários, operações de manutenção e margem de segurança. A decisão precisa considerar o que mais usa o volume.

O log cheio tem outra causa

O arquivo de log não deve ser reduzido como rotina. Se ele cresce continuamente, a primeira pergunta é por que o truncamento não está ocorrendo. Em recovery model FULL, o banco precisa de backups de log regulares; sem eles, uma transação longa, uma réplica atrasada ou uma operação de manutenção pode manter o log ativo.

Para observar o motivo do log reutilizável estar bloqueado:

SELECT    name,    recovery_model_desc,    log_reuse_wait_descFROM sys.databasesWHERE state_desc = 'ONLINE';

LOG_BACKUP aponta para a cadeia de backups. ACTIVE_TRANSACTION pede investigação de uma transação aberta. AVAILABILITY_REPLICA ou causas ligadas à replicação indicam que reduzir o arquivo não corrige o mecanismo que está segurando o log. Liberar espaço sem tratar a causa apenas adia a próxima ocorrência.

O tempdb exige outra leitura

O tempdb é compartilhado por sessões, consultas, version store e operações internas. Um crescimento pontual pode ser legítimo; crescimento recorrente no mesmo horário pode indicar uma consulta que ordena ou faz hash além do esperado, uma transação longa mantendo versões ou uma configuração que não acompanha a carga.

O diagnóstico deve registrar qual arquivo cresceu, quando cresceu e quais sessões estavam ativas. A pergunta não é apenas “quanto o tempdb ocupa?”, mas “qual mecanismo fez essa ocupação aumentar e ele se repete?”. Aumentar o arquivo pode ser necessário para estabilizar a operação, mas não substitui encontrar a origem.

Um alerta que ajuda a decidir

Um alerta de capacidade precisa carregar contexto suficiente para permitir uma ação. Em vez de avisar apenas “disco em 80%”, ele deveria informar o volume, os bancos afetados, o crescimento dos últimos dias, a estimativa de prazo e a ação prevista.

O alerta também precisa diferenciar níveis. Um aviso de planejamento pode chegar durante o horário comercial; um alerta de risco imediato pode exigir intervenção. Se todos usam o mesmo canal e a mesma severidade, o time aprende a ignorar ambos.

Próximo passo

Prever espaço não é adivinhar o futuro. É manter histórico suficiente para enxergar a tendência, relacionar crescimento ao mecanismo que o produz e reservar capacidade antes da operação depender dela.

Se o ambiente já apresenta autogrowth frequente, log crescendo sem explicação ou alertas de disco sem prazo, um diagnóstico gratuito do SQL Server ajuda a separar risco de armazenamento, configuração e carga de trabalho.