Servidor SQL: mejores prácticas para el crecimiento de archivos de base de datos

He estado monitoreando el crecimiento de archivos a través del recopilador de datos en SQL Server 2008 R2 durante dos semanas. La base de datos está creciendo constantemente a alrededor de 35 (MB) / día. El DB aún no ha alcanzado el tamaño inicial de 2 GB.

El crecimiento automático de los archivos DB está configurado en 5 MB y me gustaría probar un enfoque diferente, por lo que estoy buscando sugerencias y / o comentarios.

Hay una tarea de ajuste que se ejecuta todas las semanas el domingo por la noche a la 1:30 a.m. La tarea:

• Comprobar la integridad de la base de datos
• Reducir el archivo de registro - (Esto está bien porque el modo de registro es simple)
• Reducir base de datos
• Reorganizar índice
• Reconstruir índice
• Actualizar estadísticas
• Limpiar la historia

Me gustaría agregar dos pasos más al plan de ajuste semanal:

1. Aumente el archivo de la base de datos en 500 MB si el espacio utilizado alcanza un cierto umbral o tamaño total.
2. Aumente el archivo de registro en 250 MB (después de la reducción) si el espacio utilizado alcanza un cierto umbral de tamaño total.

Al colocar la carga de crecimiento en horas fuera de línea, espero ganar rendimiento al reducir la cantidad de eventos de crecimiento automático durante cargas pesadas.

Tengo dos preguntas relacionadas con el crecimiento automático de archivos.

• ¿El mejor lugar para colocar los pasos de crecimiento del archivo sería antes de los pasos actuales o después?
• Si uso el ALTER DATABASE|MODIFY FILEpara hacer crecer el archivo, ¿cómo puedo determinar si SpaceUsedInFile >= (TotalFileSpace-@AllowanceThreshold)?

Debes apuntar a crecer automáticamente lo menos posible. Siete veces al día es insoportable, incluso con la inicialización instantánea de archivos.

No hagas una base de datos Shrink. Nunca. Archivo retráctil, tal vez, pero solo después de un evento extraordinario. Reducirlo solo para crecer nuevamente es un ejercicio inútil y en realidad debería llamarse autofragmento.

Si el modelo de recuperación es simple, no hay forma de que necesite aumentar su archivo de registro en 250 GB. El espacio utilizado en el archivo se limpiará automáticamente con el tiempo, a menos que haya iniciado una transacción hace un mes y no tenga la intención de comprometerla o revertirla.

Entonces mi consejo sería:

Haga crecer automáticamente el archivo de datos manualmente durante un período de silencio a un tamaño que permita varios meses de crecimiento. ¿Para qué lo estás guardando mientras tanto?

Establezca el incremento de crecimiento automático para el archivo de datos en algo relativamente pequeño (para que no interrumpa a los usuarios cuando ocurra), y alerta sobre este evento (puede atraparlo en el rastreo predeterminado, por ejemplo, o mediante eventos). Esto puede decirle que está alcanzando el punto más alto que calculó y que es hora de volver a crecer manualmente. En este punto, querrá conservar este manual en caso de que desee agregar un nuevo archivo / grupo de archivos en una unidad diferente para acomodar el espacio, ya que eventualmente llenará la unidad actual.

Haga crecer automáticamente el archivo de registro hasta, digamos, el doble del más grande que haya sido. No debería crecer automáticamente a menos que haya alguna transacción anormal que frene las cosas. También debe monitorear este evento, para saber sobre ellos.

El crecimiento automático es algo que debe tratar de evitar si es posible. El problema es que no tiene control sobre cuándo puede ocurrir el crecimiento y su sistema puede recibir un golpe grave mientras lo hace.

Establezca el tamaño de su archivo en algo razonable durante un mes más o menos y controle su tasa de crecimiento desde allí, calcule cuánto espacio estima para X cantidad de tiempo y establezca su tamaño en ese + un margen de error.

He configurado un trabajo de monitoreo simple que me alertará cuando el tamaño del archivo alcance un máximo predefinido antes del crecimiento automático. Podrías usar algo como esto:

SELECT instance_name,
       [Data File(s) Size (KB)],
       [LOG File(s) Size (KB)],
       [Log File(s) Used Size (KB)],
       [Percent Log Used]
       into ##Logsize
FROM
(
   SELECT *
   FROM sys.dm_os_performance_counters
   WHERE counter_name IN
   (
       'Data File(s) Size (KB)',
       'Log File(s) Size (KB)',
       'Log File(s) Used Size (KB)',
       'Percent Log Used'
   )
     AND instance_name = 'database your interested in' 
) AS Src
PIVOT
(
   MAX(cntr_value)
   FOR counter_name IN
   (
       [Data File(s) Size (KB)],
       [LOG File(s) Size (KB)],
       [Log File(s) Used Size (KB)],
       [Percent Log Used]
   )
) AS pvt 
go
declare @logsize int
Select @logsize = [Percent Log Used] from ##Logsize

If @logsize > the maximum percent you want the log to fill too i.e 90
    BEGIN
        --Do your thing here
    END

Drop table ##Logsize

Por supuesto, esto podría programarse como un trabajo.