Arquivos de banco: capacidade antes do autogrowth

Um banco pode ficar sem espaço com um arquivo pequeno, ou gerar alerta de disco enquanto há espaço reutilizável dentro de um arquivo grande. Alocação, uso interno e capacidade do sistema de arquivos são medidas diferentes. O planejamento precisa das três.

Interpretar a alocação

A consulta mostra tamanho e páginas usadas no banco atual. FILEPROPERTY SpaceUsed representa páginas alocadas dentro do arquivo, não espaço livre do sistema nem tamanho lógico das linhas. Log exige medição e análise de reutilização separadas.

SELECT name,type_desc,size/128.0 AS AllocatedMB,
 CASE WHEN type=0 THEN FILEPROPERTY(name,'SpaceUsed')/128.0 END AS UsedMB,
 CASE WHEN type=0 THEN (size-FILEPROPERTY(name,'SpaceUsed'))/128.0 END AS InternalFreeMB,
 is_percent_growth,growth,
 CASE WHEN is_percent_growth=0 THEN growth/128.0 END AS FixedGrowthMB,
 max_size
FROM sys.database_files;

Crescimento percentual depende do tamanho atual. Dez por cento de um arquivo pequeno e de vários terabytes são eventos diferentes. Um incremento fixo torna a próxima solicitação previsível, mas não existe quantidade universal de megabytes adequada para toda carga.

Confira capacidade física separadamente. A consulta pode repetir o mesmo volume para vários arquivos; não some seu espaço livre várias vezes. Outros bancos e aplicações podem compartilhá-lo. Em armazenamento virtualizado, o sistema de arquivos representa apenas uma camada.

SELECT f.name,v.volume_mount_point,
 v.total_bytes/1073741824.0 AS VolumeGB,
 v.available_bytes/1073741824.0 AS AvailableGB
FROM sys.database_files AS f
CROSS APPLY sys.dm_os_volume_stats(DB_ID(),f.file_id) AS v;

Tratar autogrowth como reserva

Pré-aloque demanda próxima e mantenha crescimento automático como proteção contra erros de previsão. Muitos incrementos pequenos adicionam trabalho e podem interromper solicitações. Incrementos enormes podem demorar ou consumir a reserva de outros arquivos. Decida conforme crescimento observado, duração e capacidade.

Dados e log comportam-se de forma distinta. Espaço interno reutilizável pode evitar expansão de arquivos de dados. O log pode ficar preso por transações longas, backups pendentes ou outras esperas. Adicionar capacidade dá tempo sem corrigir a causa.

Inicialização instantânea pode reduzir o tempo dos dados quando aplicável. Não cria capacidade nem elimina todo o trabalho. Não extrapole para crescimento do log sem considerar versão e tamanho. Meça uma operação comparável.

Alertar antes da próxima falha

Monitore espaço interno, reserva física, ritmo de crescimento, tamanho máximo e falhas. Calcule tempo restante para demanda normal e de pico. Uma porcentagem pequena em volume enorme pode bastar; uma grande em volume pequeno pode desaparecer rapidamente.

Inclua operações programadas. Criação ou rebuild de índices, importação e staging podem precisar de espaço adicional. Dados, log e tempdb podem crescer juntos. Conferir somente o arquivo alvo ignora essa demanda combinada.

Evite reduzir e crescer novamente de forma rotineira. Espaço devolvido após manutenção costuma ser necessário de novo, criando trabalho e desfazendo uma alocação estável. Avalie shrink apenas quando houver redução duradoura justificada.

Compare previsão e alocação real ao longo do tempo. Registre duração e impacto de cada crescimento, não apenas sucesso. Um alerta útil identifica arquivo ou volume, próximo incremento e prazo para agir. Confira MAXSIZE, que pode impedir crescimento mesmo com disco livre. Verifique também manutenção simultânea em vários bancos: previsões individuais não provam que a reserva compartilhada atende a todos. Documente responsáveis e procedimento para ampliar capacidade antes do esgotamento, evitando decisões improvisadas durante a indisponibilidade.

Crescimento zero significa que a expansão automática está desabilitada; confira essa configuração.

Referências técnicas: Microsoft Learn: Database files · Microsoft Learn: Volume statistics.