¿Cuándo deben almacenarse los índices no agrupados en grupos de archivos separados?

He oído que almacenar índices en un grupo de archivos y unidad diferente aumenta el rendimiento en una base de datos porque la unidad no tiene que ir y venir entre el índice y los datos a los que se refiere el índice. También he escuchado que esto es un mito.

¿Cuándo es aconsejable almacenar índices no agrupados en un grupo de archivos y unidad separados? ¿Qué evidencia de perfmon / profiler me llevaría a llegar a esa conclusión? ¿El hardware juega un papel en la decisión (si se usa un RAID / SAN en una sola unidad)?

La parte más lenta de un sistema de base de datos son las unidades de disco. Eliminar los cuellos de botella a nivel de disco mejorará el rendimiento. Cuando se buscan datos y se usa un índice, primero se busca el índice y luego se obtienen los datos correspondientes. Si tanto el índice como los datos están en los mismos discos, entonces está ocurriendo cierta disputa. Mientras que, si los datos se encontraban en un disco (físico) diferente, entonces ocurre un IO más rápido, lo que aumenta el rendimiento. La parte principal a tener en cuenta es que los datos o el índice están en discos físicos o LUN separados.

Utilizaría este escenario si necesita obtener un mejor rendimiento de su sistema, siempre que tenga los discos. Para los contadores del monitor de rendimiento que podrían utilizar Physical Disk – Avg. Disk sec/Read, Physical Disk – Avg. Disk sec/Write, Physical Disk – Disk Reads/sec, Physical Disk – Disk Writes/sectener un antes y después de la comparación de los cambios.

Ciertamente es cierto que distribuir sus E / S simultáneas entre diferentes unidades aumentará el rendimiento, eso no es un mito. Es un mito que hacerlo dos veces mejorará el rendimiento nuevamente.

Si eres MISMO , dividir tu matriz en dos particiones y poner índices en una y tablas en otra es una pérdida de tiempo.

Separar los índices de los datos en grupos de archivos separados = la mejora del rendimiento es muy discutible. La mejora del rendimiento "puede" suceder si tiene el hardware subyacente para admitirlo, pero solo por el hecho de separarlos en diferentes grupos de archivos no le da un aumento de rendimiento. Y tampoco es fácil medir el aumento de rendimiento debido a esto.

Ref: http://weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA-Monkey.aspx

Debes hacer la pregunta primero. ¿Por qué necesitas hacer esto?

1. ¿Desea mejorar el rendimiento de las copias de seguridad al NO incluir los índices?
2. ¿Busca mejorar el rendimiento de las lecturas y escrituras en estos índices?
3. ¿Estás haciendo esto para una mejor manejabilidad de la colocación de los objetos subyacentes?
4. ¿Tiene grandes volúmenes de datos que tienen diferentes necesidades de rendimiento?
5. ¿Desea utilizar SSD para índices no agrupados para mejorar el rendimiento, etc.?

Observé esta tarea para apoyar la necesidad de # 5 en la lista anterior y me parece una buena propuesta, aunque todavía no hemos actuado sobre eso.

Tenga en cuenta que esta decisión NO es tan fácil de tomar y debe averiguar qué está tratando de hacer y asegurarse de tener el hardware que admitir. No realice cambios como este a menos que haya probado bien y vea un aumento significativo en el rendimiento; de lo contrario, también podría abandonar esta idea. NO vale la pena si espera un aumento de rendimiento simplemente separando los índices en grupos de archivos separados.

Te contaré mi experiencia personal con respecto a este artículo. Los índices no agrupados deben almacenarse en un grupo de archivos separado cuando la unidad de disco actual no es lo suficientemente grande para el espacio necesario :-). Puedes reírte de eso ... pero sucede.

Entonces, una solución de emergencia para nosotros, cuando estábamos a punto de permanecer sin espacio libre en una unidad de datos, fue crear un script agradable para recrear todos los índices no agrupados en línea en un nuevo grupo de archivos en una unidad con espacio libre. Uno pensaría que es fácil y rápido comprar nuevo almacenamiento ... pero en realidad no es así.

En cuanto al rendimiento, no vimos nada fuera de lo común después del movimiento. Pero es una gran caja de almacenamiento SAN donde todo se mantiene unido :-).

En general; dividir datos e índices en discos separados de rendimiento similar puede aumentar el rendimiento para operaciones de escritura sustanciales en esa tabla o grandes operaciones de lectura que utilizan ese índice. Una metodología similar a otras operaciones de E / S, como una tabla particionada distribuida en múltiples discos físicos.

Sin embargo, también depende en gran medida del almacenamiento . Por ejemplo; si tiene un servidor con un agradable Fushion ioDrive (o algo similar) y también tiene discos giratorios individuales. Puede ser más beneficioso mantener todo en el ioDrive (a menos que el espacio sea limitado). También hay otras cosas a tener en cuenta: configuración RAID, configuración de almacenamiento de red.

Realice algunas marcas de banco en un servidor de prueba con hardware similar o (solo si un servidor secundario no es una opción) durante las horas no pico con datos temporales. El enlace DBA-Monkey de Sankar arriba es una buena forma de pensar.