it-swarm-es.com

En SQL Server, ¿cuándo debería dividir su grupo de archivos de datos PRIMARIO en archivos de datos secundarios?

Nuestra base de datos actualmente solo tiene un grupo de archivos, PRIMARIO, que contiene aproximadamente 8 GB de datos (filas de tablas, índices, catálogo de texto completo).

¿Cuándo es un buen momento para dividir esto en archivos de datos secundarios? ¿Cuáles son algunos criterios que debo tener en cuenta?

11
Jarrod Dixon

Hay dos partes en esta pregunta: cuándo agregar un nuevo GRUPO DE ARCHIVOS y cuándo agregar un nuevo ARCHIVO en un grupo de archivos. Primero hablemos de teoría:

Mark tiene razón acerca de que la razón principal es el rendimiento.

La razón secundaria es la recuperación ante desastres. Con SQL Server 2005 y versiones posteriores, puede realizar restauraciones de grupos de archivos. Cuando ocurre un desastre, puede restaurar solo su grupo de archivos principal primero y poner la base de datos parcialmente en línea para consultas. Los usuarios pueden ejecutar consultas mientras restaura otros grupos de archivos. Esto es útil para bases de datos con una gran cantidad de datos históricos que pueden no ser necesarios de inmediato o almacenes de datos que necesitan cargar datos en tablas actuales sin necesidad de acceder a datos históricos.

Otra razón es el perfil de lectura/escritura de grupos de datos. Si tiene algunos datos en los que se escribe constantemente y otros datos que generan una gran actividad de lectura, puede crear diferentes tipos de almacenamiento para satisfacer esas necesidades. Puede poner las cosas de escritura pesada en la incursión 10 y dejar las cosas con sesgo de lectura en la incursión 5 más barata.

Ahora, hablemos de archivos versus grupos de archivos. Cuando coloca objetos en SQL Server, debe colocarlos en el nivel del grupo de archivos. Puede colocar una tabla o un índice en un grupo de archivos, pero no puede elegir un archivo específico. Entonces, todo lo que hemos discutido hasta ahora ha sido acerca de cuándo agregar un grupo de archivos, pero ¿cuándo agregar un archivo?

Si está diseñando almacenamiento y tiene 80 discos duros, hay algunas formas de dividirlo:

  • Un grupo de 80 unidades
  • Dos grupos de 40 unidades
  • Cuatro piscinas de 20 unidades, etc ...

Los diferentes subsistemas de almacenamiento tienen diferentes perfiles de rendimiento. He trabajado con algunas SAN que funcionaron mejor con matrices de 12-16 unidades, y cualquier cosa más grande que eso no tuvo una mejora de rendimiento. Otro ejemplo son las SAN con múltiples rutas: si tiene varios HBA que conectan su servidor a su almacenamiento, y si su software de múltiples rutas no está realmente activo/activo, es posible que necesite una matriz por ruta para distribuir la carga. Cuatro rutas, cuatro grupos de unidades obtendrán un mejor rendimiento en ese tipo de unidades.

En esos casos, terminará con cuatro matrices diferentes, cuatro unidades diferentes en Windows (a menos que use puntos de montaje, e incluso entonces sean carpetas diferentes) y necesitará cuatro archivos separados en SQL Server. Esos archivos separados pueden estar en el mismo grupo de archivos.

20
Brent Ozar

La razón principal es el rendimiento. Cuando se agote la capacidad de IOPS en la unidad de disco del grupo de archivos principal, deberá expandirse a un segundo grupo de archivos para dividir IOPS en varios discos/LUN según la configuración de almacenamiento.

EDITAR: Brad Wilson hizo un buen comentario sobre los SSD. Si está utilizando un sistema de almacenamiento compuesto SSD/SATA/FC, es posible que desee tener diferentes grupos de archivos en diferentes tipos de almacenamiento. Luego, puede colocar sus tablas de requisitos de IOPS extremas en SSD filegropus, mientras que las tablas de historial/estadísticas pueden almacenarse en grupos de archivos SATA económicos.

6
Mark S. Rasmussen

También me gustaría señalar que esta pregunta también tiene un aspecto de recuperación/disponibilidad de datos. Al utilizar varios grupos de archivos y no colocar ningún objeto definido por el usuario en el grupo de archivos principal, tiene más flexibilidad para habilitar las restauraciones en línea. esto permite la restauración gradual a nivel de grupo de archivos.

La restauración en línea está disponible en las ediciones Enterprise y Developer de SQL Server posteriores a 2005

Otro pensamiento que me viene a la mente es separar los datos de referencia estáticos de solo lectura de los datos transaccionales. Para bases de datos más grandes, esto podría reducir la cantidad de tiempo y/o espacio necesarios para realizar una copia de seguridad.

1
Jason Horner