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

16

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)?
Ross Bush
fuente
2
Su base de datos debe tener el tamaño suficiente para que nunca crezca. Sin embargo, asegúrese de que la Inicialización instantánea de archivos esté habilitada.
Remus Rusanu
3
@Remus, aunque es ideal, ¿estás diciendo que has dimensionado previamente todas las bases de datos a lo largo de tu carrera? Siempre habrá algunas conjeturas y ajustes a realizar. Estoy de acuerdo en que el crecimiento debe ser controlado y no solo dejarlo 7 veces al día.
Aaron Bertrand
3
@ AaronBertrand: Estoy a favor de consejos simplistas e hipérboles . Con el tiempo aprendí que se pega mejor. La mayoría de los usuarios no pueden manejar el 'depende' y aquellos que lo hacen pueden darse cuenta por sí mismos de que hay tonos de gris entre blanco y negro ...
Remus Rusanu
3
@DanAndrews: la sobreasignación puede tener efectos 'aguas abajo'. Piense en un desarrollador que intenta restaurar la base de datos en su máquina solo para descubrir que necesita dos nuevas unidades de 1TB para 1Gb de datos ...
Remus Rusanu
2
Solo estoy jugando al abogado del diablo. Sin embargo, los HD son baratos. El tiempo perdido en producción para la reconfiguración y la pérdida de rendimiento es costoso.
Dan Andrews

Respuestas:

24

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.

Aaron Bertrand
fuente
Gracias por el aporte ... Seguiré sus consejos para hacer crecer el archivo de registro y monitorearlo por un tiempo. Utilicé incorrectamente GB para MB en el tamaño de crecimiento automático. Estoy de acuerdo y no creo que la base de datos Shrink esté haciendo lo que estaba destinado a hacer. Al final del año, el DB alcanza los 15 GB, en el momento en que se creó el trabajo, nos estábamos quedando sin espacio para copias de seguridad.
+1 para debería llamarse auto-fragment :-) ¿Ya ha lanzado un problema de Connect para eso? :-)
marc_s
10

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.

Nick Winstanley
fuente
Elimino la base de datos "AND instance_name = 'que le interesa" para que devuelva todas las bases de datos. Luego use un recuento donde el tamaño del registro esté por encima de un umbral en la instrucción IF Si el recuento es superior a 1, hago un sp_send_dbmail con una declaración de nombre de selección de la tabla temporal para enviar por correo electrónico los nombres de los registros por encima del límite.
Nick Winstanley