¿Hay algún beneficio en la desfragmentación de índices SQL en un entorno SAN?

16

Nuestro servidor SQL vive en una SAN. Contiene docenas de bases de datos OLTP, algunas con varias tablas que contienen más de 1 millón de registros.

Hemos estado ejecutando scripts de mantenimiento de índice de Ola Hallengren semanalmente, y se ejecuta durante varias horas cada vez. Según el umbral de fragmentación, el script reorganizará o reindexará un índice. Hemos observado que durante la reindexación, los archivos de registro se vuelven enormes, lo que conduce a un consumo excesivo de ancho de banda durante el envío de registros.

Luego viene un artículo de Brent Ozar en el que dice que deje de preocuparse por los índices SQL :

Sus discos duros se comparten con otros servidores que también están haciendo solicitudes de unidades al mismo tiempo, por lo que las unidades siempre estarán saltando por todas partes para obtener datos. Desfragmentar sus índices es simplemente un trabajo ocupado sin sentido.

Buscar en Google esta pregunta lleva a diferentes opiniones, la mayoría apoyadas con argumentos que parecen demasiado breves o débiles. Nuestro plan tentativo es ajustar el umbral de fragmentación en nuestro script de mantenimiento para que se reorganice con mucha más frecuencia de la que reindexa.

¿Cuál es el veredicto final? ¿Vale la pena desfragmentar los índices SQL en una SAN teniendo en cuenta las cargas asociadas con la ejecución de trabajos de mantenimiento semanal?

— dev_etter
fuente

10

Las estrategias de desfragmentación ayudan a mejorar la velocidad de escaneo hacia / desde el disco .

La gran variedad de opiniones se debe a que la estrategia de desfragmentación ideal de un entorno debería depender de muchos factores diferentes. También hay múltiples capas potenciales de fragmentación en juego.

Decir que sus bases de datos están almacenadas en una SAN no es suficiente información. Por ejemplo:

¿Los archivos de la base de datos se almacenan en grupos RAID físicos separados o en el mismo grupo RAID? ¿Qué otros procesos están activos en ese mismo dispositivo? ¿Sus archivos de copia de seguridad también terminan allí? Es posible que deba solicitar esta información a su administrador de SAN porque no siempre es transparente.
¿Cuáles son los patrones de acceso para las bases de datos? OLTP es generalmente de acceso aleatorio, pero a veces una aplicación es feliz para escanear tablas y no puede cambiar su comportamiento (aplicación ISV). ¿Las aplicaciones son principalmente de lectura, de escritura o en algún punto intermedio?
¿Hay SLA de rendimiento en juego durante un período de recuperación / conmutación por error ?

La publicación de Brent supone que hay un grupo gigante de almacenamiento y todo lo comparte. Esto significa que los discos físicos rara vez están inactivos y, por lo tanto, la mayoría del acceso es aleatorio. Si esa es su situación, entonces el consejo se aplica, y estoy de acuerdo con él en su mayor parte. Si bien este tipo de estrategia es mucho más fácil de administrar, no es necesariamente (a) lo que tiene en su entorno, o (b) cuál es la mejor solución para su entorno.

Si el mantenimiento del índice es oneroso, considere hacerlo de manera menos agresiva y / o amortice el costo durante la semana (es decir, realice un mantenimiento ligero una vez / día, en lugar de un mantenimiento pesado una vez / semana).

También puede activar la SortInTempdbopción para reducir potencialmente la cantidad de registro que tiene lugar en las bases de datos del usuario.

— Jon Seigel
fuente

Wow, respuesta completa. Probablemente me llevará algún tiempo hacer toda la investigación, pero no dudo que me esté guiando por el camino correcto. De hecho, nuestra estrategia actual es ejecutar el mantenimiento de manera menos agresiva tanto desde el punto de vista de la reconstrucción como desde el de reorganización, creo que expresé mal en la pregunta. A partir de ahí, investigaré más sobre el resto de los factores que mencionó.

— dev_etter

1

@dev_etter: solo enumeré algunos factores; hay muchos más. El punto principal es la primera oración. Si tiene eso en cuenta al pensar en su entorno, dirigirá correctamente su decisión. Todo se deriva de eso. (Además, todo esto supone que no hay SSD involucrados.)

— Jon Seigel

FWIW, había pasado por alto algo por completo: la secuencia de comandos real en el paso del trabajo (en lugar de la fuente) se configuró para abordar cada índice que tenía un porcentaje mínimo de fragmentación de 1. Aumenté eso hasta 15 y también superé el umbral de reconstrucción desde 30 a 35. El trabajo ahora se ejecuta en poco más de 3 horas en lugar de 8. Su sugerencia de ser menos agresivo fue correcta. Mi culpa radicaba en el hecho de que pensaba que el trabajo ya había sido implementado para ser menos agresivo. Este enfoque es probablemente el mejor para nosotros, todavía tocamos y vamos, pero ya alivió algo de dolor.

— dev_etter

@ JonSeigel Estoy totalmente de acuerdo con esta respuesta. En mis viajes veo que la mayoría de los DBA comparten un único grupo, o al menos una matriz en el mismo nivel RAID. He tenido DBA en 3AM 24x7 solo para desfragmentar grupos de archivos individuales de bases de datos de más de 100 TB ... ¿y para qué exactamente? Tuvimos IO totalmente al azar en los discos y la latencia fue de 15 ms. En ese punto, debería señalar 15 ms y decirles a los desarrolladores que me dejen en paz.

— ooutwire

2

Idealmente, debería reorganizar / reindexar SOLAMENTE aquellos índices que necesitan atención, de lo contrario está desperdiciando recursos y potencialmente causando otros problemas.

Debe establecer una línea de base de rendimiento y cada vez que realice cambios compare el cambio de rendimiento con la línea de base para determinar si vale la pena implementar su cambio.

— Jimbo
fuente

Nuestra estrategia inmediata es hacer exactamente eso: vamos a ajustar la configuración de las variables minFragmentation y rebuildThreshold en este script: sqlfool.com/2011/06/index-defrag-script-v4-1

— dev_etter

0

De acuerdo, la pregunta es sobre los índices de base de datos, que son una construcción de un archivo o conjunto de archivos. Leer las respuestas anteriores llevaría a una persona a creer que estamos hablando de fragmentación a nivel de disco y no de los índices dentro de un archivo. Estas materias totalmente separadas.

El enfoque miope aquí es el rendimiento cuando se recuperan datos dentro y la base de datos OLTP mejora si los índices están fragmentados o reconstruidos. ¡La respuesta es sí! Sin embargo, es importante tener en cuenta que la fragmentación del disco también es un factor.

¿El "costo" más bajo en general? Haga el mantenimiento de su base de datos. Segundo costo más bajo, separe la base de datos, muévala a otro lugar, vuelva a formatear sus discos y siga las mejores prácticas para la Alineación de particiones de disco http://msdn.microsoft.com/en-us/library/dd758814.aspx . Por último, pero no menos importante, use un desfragmentador avanzado de terceros como Diskkeeper.

Tenga en cuenta que esto SOLO se recomienda para el almacenamiento de tipo NTFS (p. Ej., Sistema operativo Windows) y no es un aval para ningún producto ni estoy afiliado a Condusiv Technologies o sus subsidiarias.

— IryDBA2791
fuente

2

Probablemente desee evitar decir categóricamente "¡La respuesta es SÍ!" a espacios problemáticos que han sido discutidos extensamente por otros carteles. Si bien puede ser cierto que a veces la respuesta es "Sí", como Brent Ozar ha demostrado en su publicación de blog, ese no es siempre el caso.

— Max Vernon