Volumen compartido para datos (mdf múltiple) y otro volumen compartido para registros (múltiples LDF) en San

Question

Tengo 3 instancias de SQL Server 2008, cada una en diferentes máquinas con múltiples bases de datos en cada instancia.Tengo 2 LUNs separados en mi SAN para los archivos MDF y LDF.Los archivos NDX y Tempdb se ejecutan en la unidad local en cada máquina.Está bien.¿Para los 3 instancias compartir un mismo volumen para los archivos de datos y otro volumen para los archivos de registro?

No tengo el aprovisionamiento delgado en la SAN, así que me gustaría que no me gustaría la preparación de espacio en disco que crea múltiples volúmenes porque me acompañaron que debería crear un volumen (letra de unidad) para cada instancia, si no es para cada base de datos.Soy consciente de que debería dividir mis registros y archivos de datos al menos.Ningún caso compartiría los archivos de base de datos reales, solo el espacio en la unidad.

Cualquier ayuda es apretada.

Answer 1

Por supuesto, la respuesta es: "Depende". Puedo intentar darte algunos consejos sobre lo que depende, sin embargo.

Una instancia de SQL Server "asume" que tiene acceso exclusivo a sus recursos. Por lo tanto, completará toda la RAM disponible por defecto, usará todas las CPU y intentará saturar los canales de E / S para obtener el máximo rendimiento. Esa es la razón del consejo general para mantener sus casos de acceso simultáneamente a los mismos discos.

Otra cosa es que SQL Server "se sabe" que el acceso de E / S secuencial le brinda mucho más alto que la E / S de la aleatoria, por lo que hay muchos mecanismos en el trabajo (como la organización de filo, lectura, escritor perezoso, escritor perezoso y otros) para evitar la E / S al azar lo más posible.

Ahora, si tres instancias de SQL Server realizan solicitudes de E / S secuencial en un solo volumen al mismo tiempo, luego desde la perspectiva del volumen, se vuelve a obtener solicitudes de E / S aleatorias, lo que duele su rendimiento.

Dicho esto, es solo un problema si su subsistema de E / S es un cuello de botella significativo. Si su volumen del archivo de registro es lo suficientemente rápido como para que las escrituras secuenciales entremezcladas de las instancias no creen un problema, adelante. Si tiene suficiente RAM en las instancias de que las lecturas de datos se pueden satisfacer desde el caché de búfer la mayor parte del tiempo, no necesita mucho rendimiento de lectura en su subsistema de E / S.

Lo que debe evitar en cada caso es múltiples pasos de crecimiento en los archivos de registro o datos. Si está creciendo varios archivos en un sistema de archivos, obtendrá la fragmentación y la fragmentación puede transformar una solicitud de lectura o escritura secuencial incluso de una sola fuente a la E / S aleatoria nuevamente.

Toda la imagen cambia de nuevo si usa SSDS como discos. Estos tienen requisitos y comportamientos totalmente diferentes, pero como no dijiste nada sobre SSD, asumiré que utiliza una matriz basada en el disco "convencional" o la configuración de RAID.

Resumen corto: puede salirse con él, si las circunstancias tienen razón, pero es difícil evaluar sin saber mucho más sobre sus sistemas, desde la perspectiva de San y SQL.