Archivos de base: capacidad antes del crecimiento automático

Una base puede quedarse sin espacio con un archivo pequeño, o generar una alarma de disco mientras conserva espacio reutilizable dentro de un archivo grande. Asignación, uso interno y capacidad del sistema de archivos son medidas diferentes. La planificación necesita las tres.

Interpretar la asignación

La consulta muestra tamaño y páginas usadas en la base actual. FILEPROPERTY SpaceUsed representa páginas asignadas dentro del archivo, no espacio libre del sistema ni tamaño lógico de filas. El log requiere medición y análisis de reutilización independientes.

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;

Un crecimiento porcentual depende del tamaño actual. Diez por ciento de un archivo pequeño y de varios terabytes son eventos distintos. Un incremento fijo hace predecible la siguiente solicitud, pero no existe un número universal de megabytes apropiado para toda carga.

Compruebe capacidad física por separado. La consulta puede repetir el mismo volumen para varios archivos; no sume espacio libre repetidamente. Otras bases y aplicaciones pueden compartirlo. En almacenamiento virtualizado, el espacio del sistema de archivos solo representa una capa.

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;

Utilizar crecimiento automático como reserva

Preasigne demanda cercana y conserve autogrowth como protección contra errores de previsión. Muchos incrementos pequeños añaden trabajo y pueden interrumpir solicitudes. Incrementos enormes pueden tardar más o consumir reserva necesaria para otros archivos. Decida según crecimiento observado, duración y capacidad.

Datos y log se comportan de manera distinta. Espacio interno reutilizable evita ampliar un archivo de datos. El log puede no reutilizarse por transacciones largas, respaldos pendientes u otras esperas. Añadir capacidad permite respirar sin corregir la causa.

La inicialización instantánea puede reducir tiempo de inicialización de datos cuando corresponde. No crea capacidad ni elimina todo el trabajo. No extrapole automáticamente al crecimiento del log sin considerar versión y tamaño. Mida una operación comparable.

Alertar antes del siguiente fallo

Monitorice espacio interno, reserva física, ritmo, tamaño máximo y fallos de crecimiento. Calcule tiempo restante con demanda habitual y máxima. Un porcentaje pequeño en un volumen enorme puede bastar; uno grande en un volumen diminuto puede agotarse enseguida.

Incluya operaciones programadas. Crear o reconstruir índices, importar y usar staging puede exigir espacio adicional. Datos, log y tempdb pueden crecer simultáneamente. Revisar únicamente el archivo objetivo omite esa demanda conjunta.

Evite reducir y volver a crecer rutinariamente. El espacio devuelto después de mantenimiento suele necesitarse otra vez, generando trabajo y deshaciendo una asignación estable. Evalúe shrink solo ante una reducción duradera justificada.

Compare previsiones y asignación real a lo largo del tiempo. Registre duración e impacto de cada crecimiento, no solo éxito. Una alerta útil identifica archivo o volumen, siguiente incremento y tiempo para responder. Revise MAXSIZE, que puede impedir crecimiento aun con disco disponible. Compruebe además si varias bases tienen mantenimiento simultáneo: sus previsiones individuales no garantizan que la reserva compartida alcance para todas. El objetivo es actuar antes del agotamiento, con capacidad y responsables claramente identificados.

Referencias técnicas: Microsoft Learn: Database files · Microsoft Learn: Volume statistics.