SQL Server 2005/2008 - múltiples archivos / grupos de archivos - ¿cuántos? ¿Por qué?

Soy un desarrollador en el fondo, pero de vez en cuando, un cliente no tiene un DBA decente para tratar estos problemas, por lo que me llaman para decidir ...

¿Cuáles son sus estrategias / mejores prácticas cuando se trata de tratar con una base de datos SQL Server de tamaño razonable (algo más grande que Northwind o AdventureWorks; aproximadamente 2-4 GB de datos más índices, etc.): ¿utiliza múltiples archivos / grupos de archivos?

Si es así, ¿cuántos? ¿Y por qué?

¿Cuáles son sus criterios para decidir cuándo alejarse del enfoque de "un grupo de archivos para todo"?

* database size?
* database complexity?
* availability / reliability requirements?
* what else?

Si usa varios grupos de archivos, ¿cuántos usa? ¿Uno para datos, uno para índice, uno para registro? ¿Varios (cuántos) para datos? ¿Cuáles son los motivos de su elección? ¿Por qué utiliza ese número exacto de grupos de archivos :-)

Gracias por cualquier pista, puntero, pensamiento!

Saludos, Marc

La regla básica es separar los archivos en diferentes volúmenes para evitar conflictos, sin embargo, la cantidad de ganancia de rendimiento que obtienes varía enormemente según el subsistema de E / S y la carga de trabajo. Por ejemplo, varios archivos en un solo eje físico van a succionar en lo que respecta al rendimiento, pero la misma disposición con el volumen en un SAN LUN con varios cientos de unidades de matrices RAID 10 puede estar bien. Los contadores de longitud de la cola de disco son su amigo como la forma más sencilla de saber si tiene un cuello de botella de E / S.

Está viendo los patrones de E / S en las bases de datos (solo lectura, lectura mayoritariamente, lectura-escritura, escritura mayoritariamente, solo escritura) y basando las cosas en eso. También debe elegir el nivel RAID correcto y asegurarse de que las compensaciones de la partición del disco, el tamaño de la banda RAID y el tamaño de la unidad de asignación NTFS estén configurados correctamente. A algunas personas les gusta separar los índices no agrupados en un grupo de archivos separado, pero las ganancias de rendimiento aquí varían tal como lo expliqué anteriormente.

Además del rendimiento, debe considerar la capacidad de administración y la capacidad de recuperación. Tener un único archivo de datos monolíticos para una base de datos de 100 GB significa que su unidad de restauración es ese archivo. Tenerlo dividido en 4 grupos de archivos de 25 GB significa que puede usar la disponibilidad parcial de la base de datos y la restauración gradual para tener que restaurar un solo grupo de archivos en caso de que se dañe. Al particionar tablas e índices en múltiples grupos de archivos, también puede limitar qué partes de la base de datos se ven afectadas por las operaciones de mantenimiento (por ejemplo, eliminación de fragmentación de índice).

Tempdb es un caso completamente especial, y lo señalaré en una publicación de blog mía que explica todo acerca de por qué y cómo dividir tempdb: hay muchas ideas falsas por ahí.

Sin darle una recomendación de 'generalización general' aquí, le señalaré un montón de libros blancos y publicaciones de blog para que lea:

• Libro blanco: diseño de almacenamiento de base de datos física
• Informe : Mejores prácticas de E / S previas a la implementación
• Documento técnico: Tablas e índices particionados en SQL Server 2005

• Libro blanco: disponibilidad parcial de la base de datos

• Publicación en blog: Conceptos erróneos sobre TF 1118 (diseño tempdb)

• Publicación de blog: ¿Están configuradas correctamente las compensaciones de partición de disco, los tamaños de banda RAID y las unidades de asignación NTFS? (con enlace al documento de partición de disco)

¡Espero que esto te ayude!

La decisión de dividir una base de datos en diferentes grupos de archivos debe tomarse después de haber analizado el tamaño actual y el crecimiento futuro de sus tablas. En mi opinión, a menos que tenga una gran base de datos o tablas con millones de filas, debe considerar cuidadosamente los pros y los contras, ya que puede terminar creando más problemas de rendimiento de los que arregla.

Hay algunos escenarios que podrían ser interesantes bajo ciertas premisas:

• 2 grupos de archivos: datos e índice
• 3 grupos de archivos: tablas de solo lectura, tablas de lectura-escritura, índice
• múltiples grupos de archivos: solo lectura, lectura-escritura, índice, tabla de claves 1, tabla de claves 2, ...

Debe analizar su entorno para decidir si los grupos de archivos le ayudarán con sus necesidades de crecimiento, uso y rendimiento de SQL Server.

Algunos indicadores clave para pasar a varios grupos de archivos (de este artículo ):

• Cuando la cola de disco está causando problemas con la aplicación y la experiencia del usuario
  • Si este es el caso, considere aprovechar unidades de disco adicionales con nuevos grupos de archivos que alojan tablas intensivas de E / S
• Cuando tablas particulares son 10% o más de la base de datos
  • Si este es el caso, considere mover estas tablas particularmente grandes para separar grupos de archivos en unidades de disco subyacentes separadas
  • Dependiendo del tamaño de la tabla en proporción al resto de las tablas, considere crear un grupo de archivos para tablas individuales
• Cuando el índice no agrupado y el espacio de datos son iguales en tablas grandes
  • Si este es el caso, considere dividir los datos y el índice agrupado de los índices no agrupados
• Cuando existe un porcentaje casi igual de datos de solo lectura y lectura-escritura en la base de datos
  • Si este es el caso, considere dividir los datos de solo lectura en un grupo de archivos separado como los datos de lectura-escritura
• Cuando no hay suficiente tiempo disponible para realizar el mantenimiento de la base de datos
  • Si este es el caso, considere dividir las tablas grandes en grupos de archivos separados en diferentes discos subyacentes y realice el mantenimiento en paralelo
• Cuando el negocio o la aplicación cambiarán significativamente y los datos crecerán a un ritmo mucho mayor
  • Si este es el caso, considere trabajar con los usuarios para comprender el crecimiento potencial.
• Cuando los datos archivados residen en la misma base de datos que los datos de producción
  • Si este es el caso, considere grupos de archivos separados o una o más de las técnicas en este consejo: Archivar datos en SQL Server

Si encuentra que los grupos de archivos podrían mejorar el rendimiento de su base de datos, escriba el código y pruebe el proceso en un entorno intermedio antes de implementar los cambios en sus servidores de producción. Prepare algunas medidas antes de implementar los cambios y compárelos antes / después. Dado que estos procesos pueden requerir muchos recursos y mucho tiempo, realice estos procedimientos durante un período de mantenimiento.

No olvide que, al crear nuevos objetos (tablas e índices), asegúrese de que los objetos se creen en el grupo de archivos correcto para garantizar el rendimiento esperado y valide periódicamente que los objetos de la base de datos estén en los grupos de archivos correctos y corrija según sea necesario.