Nuestra base de datos actualmente solo tiene un FileGroup, PRIMARY, que contiene aproximadamente 8 GB de datos (filas de tabla, í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?
Respuestas:
Hay dos partes en esta pregunta: cuándo agregar un nuevo FILEGROUP y cuándo agregar un nuevo ARCHIVO en un grupo de archivos. Primero hablemos de teoría:
Mark tiene razón sobre 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 hacer 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 las tablas actuales sin necesitar datos históricos para acceder.
Otra razón es el perfil de lectura / escritura de grupos de datos. Si tiene algunos datos que se escriben constantemente y otros datos que generan mucha actividad de lectura, puede crear diferentes tipos de almacenamiento para satisfacer esas necesidades. Podrías poner las cosas de escritura pesada en la incursión 10, y dejar las cosas con sesgo de lectura en la incursión más barata 5.
Ahora, hablemos de archivos versus grupos de archivos. Cuando coloca objetos en SQL Server, debe colocarlos en el nivel de grupo de archivos. Puede aterrizar 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 sobre cuándo agregar un grupo de archivos, pero ¿cuándo agrega un archivo?
Si está diseñando almacenamiento y tiene 80 discos duros, hay algunas maneras de dividirlo:
Los diferentes subsistemas de almacenamiento tienen diferentes perfiles de rendimiento. He trabajado con algunas SAN que funcionaron mejor con arreglos de unidades 12-16, y cualquier cosa más grande que eso no tuvo una mejora en el rendimiento. Otro ejemplo son las SAN con rutas múltiples: si tiene varios HBA que conectan su servidor a su almacenamiento, y si su software de rutas múltiples no es realmente activo / activo, entonces puede necesitar una matriz por ruta para distribuir la carga. Cuatro caminos, cuatro grupos de unidades obtendrán un mejor rendimiento en esos tipos de unidades.
En esos casos, termina con cuatro matrices diferentes, cuatro unidades diferentes en Windows (a menos que use puntos de montaje, e incluso entonces son carpetas diferentes) y necesitará cuatro archivos separados en SQL Server. Esos archivos separados pueden estar en el mismo grupo de archivos.
La razón principal es el rendimiento. Cuando se quede sin capacidad de IOPS en su unidad de disco de grupo de archivos principal, necesitará expandirse a un segundo grupo de archivos para dividir IOPS en múltiples discos / LUN dependiendo de la configuración de almacenamiento.
EDITAR: Brad Wilson hizo un buen comentario con respecto a los SSD. Si está utilizando un sistema de almacenamiento SSD / SATA / FC compuesto, 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 el grupo de archivos SSD, mientras que las tablas de historial / estadísticas se pueden almacenar en grupos de archivos SATA baratos.
También quisiera señalar que hay un aspecto de recuperación / disponibilidad de datos para esta pregunta también. Al usar varios grupos de archivos y no colocar ningún objeto definido por el usuario en el grupo de archivos primario, 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 del servidor SQL posterior a 2005
Otro pensamiento que 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 necesario para realizar una copia de seguridad.