¿Cuándo debo reconstruir los índices en mi base de datos relacional (SQL Server)?
¿Existe algún caso para reconstruir índices de manera regular?
Respuestas:
A riesgo de ser demasiado general en mi respuesta, diré que debe ejecutar un proceso de mantenimiento de índice regularmente. Sin embargo, su proceso de mantenimiento de índice solo debe reconstruir / reorganizar los índices que lo requieren específicamente.
Esto presenta la pregunta: ¿cuándo se debe reconstruir o reorganizar un índice? Rolando tocó esto muy bien. Nuevamente, me arriesgo a ser extremadamente amplio. Un índice requiere mantenimiento cuando el nivel de fragmentación afecta negativamente el rendimiento. Este nivel de fragmentación podría variar según el tamaño y la composición del índice.
Hablando para SQL Server, tiendo a elegir un tamaño de índice y un nivel de fragmentación del índice, en cuyo punto empiezo a realizar el mantenimiento del índice. Si un índice contiene menos de 100 páginas, no realizaré mantenimiento.
Si un índice está entre 10% y 30% fragmentado, haré REORGANIZEel índice y UPDATElas estadísticas. Si un índice está fragmentado en más de un 30%, lo haré REBUILD, con no UPDATE STATISTICS, ya que esto se encarga de esto REBUILD. Sin embargo, recuerde que una reconstrucción solo actualiza el objeto de estadísticas directamente asociado con el índice. Otras estadísticas de columna deberán mantenerse por separado.
Esta respuesta es realmente un largo camino para decir: Sí, debe realizar un mantenimiento de índice de rutina, pero solo en los índices que lo necesitan.
¿Cuándo debo reconstruir los índices en mi base de datos relacional (por ejemplo, SQL Server)?
Debería reconstruir los índices cuando se vuelvan muy fragmentados por eventos especiales. Por ejemplo, realiza una gran carga de datos en una tabla indexada.
¿Existe algún caso para reconstruir índices de manera regular?
Entonces, ¿qué pasa si sus índices se fragmentan regularmente debido a la actividad regular? ¿Debería programar reconstrucciones regulares? ¿Con qué frecuencia deberían correr?
Tom Kyte , en este hilo clásico de Ask Tom , recomienda:
El lapso de tiempo entre las reconstrucciones de índice debe ser aproximadamente PARA SIEMPRE.
...
No sé cómo decirlo mejor: el índice quiere ser grande y gordo con espacio adicional. Está en una columna que actualiza, moviendo la entrada de índice de un lugar a otro en el índice. Un día, la fila tiene un código de "A", al día siguiente el código es "G", luego "Z", luego "H" y así sucesivamente. Entonces, la entrada de índice para la fila se mueve de un lugar a otro en el índice. Mientras lo hace, necesita espacio, si el espacio no está allí, dividiremos el bloque en dos, y haremos espacio. Ahora el índice está engordando. Con el tiempo, el índice es 2-3 veces el tamaño que tenía cuando comenzó y está "medio vacío o más", pero eso está bien ya que mueve las filas. Ahora, cuando movemos las filas, ya no tenemos que dividir bloques para hacer espacio: la habitación ya está disponible.
Luego viene y reconstruye o suelta y vuelve a crear el índice (que tiene los mismos efectos, solo que la reconstrucción es "más segura") no tiene la posibilidad de perder el índice y puede ser más rápido ya que el índice puede ser reconstruido por escanear el índice existente en lugar de escanear la tabla y ordenar y construir un índice nuevo). Ahora, todo ese lindo espacio se ha ido. Comenzamos el proceso de dividir los bloques nuevamente, llevándonos de vuelta a donde comenzamos.
No ahorraste espacio.
El índice está de vuelta como estaba.
Simplemente estaría perdiendo el tiempo para reconstruirlo nuevamente, haciendo que este círculo vicioso se repita.
La lógica aquí es sólida, pero está sesgada en contra de un perfil de carga de lectura pesada.
Un índice "grueso" (es decir, uno con muchos espacios en blanco) realmente mantiene una buena cantidad de espacio para filas nuevas y movidas, reduciendo así las divisiones de página y manteniendo sus escrituras rápidas. Sin embargo, cuando lea de ese índice grueso tendrá que leer más páginas para obtener los mismos datos porque ahora está revisando más espacio vacío. Esto ralentiza tus lecturas.
Por lo tanto, en bases de datos con mucha lectura, desea reconstruir o reorganizar regularmente sus índices. (¿Con qué frecuencia y bajo qué condiciones? Matt M ya tiene una respuesta concreta a esta pregunta). En las bases de datos que experimentan una actividad de lectura y escritura más o menos equivalente, o en bases de datos que tienen mucha escritura, es probable que esté perjudicando el rendimiento de su base de datos al reconstruir índices regularmente.
La mayoría de las personas los reconstruyen de manera regular para que nunca lleguen a fragmentarse. Cuando necesita reconstruirlos se basa en la rapidez con que se fragmentan. Algunos índices deberán reconstruirse con frecuencia, otros básicamente nunca. Echa un vistazo a la secuencia de comandos que el SQLFool creó que maneja muchas de estas cosas por ti.
Como se señaló en la respuesta aceptada de Matt M, una regla general común es que los índices que están fragmentados en más del 30% deben reconstruirse.
Esta consulta lo ayudará a encontrar cuántos índices tiene más del 30% de fragmentación (cuando tenga algunos, debe reconstruirlos):
SELECT DB_NAME() AS DBName,
OBJECT_NAME(ind.object_id) AS TableName,
ind.name AS IndexName,
indexstats.index_type_desc AS IndexType,
indexstats.avg_fragmentation_in_percent,
indexstats.fragment_count,
indexstats.avg_fragment_size_in_pages,
SUM(p.rows) AS Rows
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
INNER JOIN sys.indexes AS ind ON ( ind.object_id = indexstats.object_id
AND ind.index_id = indexstats.index_id)
INNER JOIN sys.partitions AS p ON ( ind.object_id = p.object_id
AND ind.index_id = p.index_id)
WHERE indexstats.avg_fragmentation_in_percent > 30
GROUP BY
OBJECT_NAME(ind.object_id),
ind.name,
indexstats.index_type_desc,
indexstats.avg_fragmentation_in_percent,
indexstats.fragment_count,
indexstats.avg_fragment_size_in_pages
ORDER BY indexstats.avg_fragmentation_in_percent DESC¿Cuándo debo reconstruir índices?
Cuando el porcentaje de fragmentación del índice es superior al 30%.
¿Existe algún caso para reconstruir índices de manera regular?
No existe tal caso, pero en general, realizar el Mantenimiento del índice una vez por semana, durante el fin de semana, es la mejor práctica para mantener estable el entorno.
Recomendaría usar scripts de mantenimiento de Ola Hallengren (los mejores scripts de mantenimiento), personalizar los scripts según su entorno y programarlos para que se ejecuten durante el fin de semana.
Nota: No olvide actualizar las estadísticas después de reconstruir índices, porque la reconstrucción de índices no actualiza todas las estadísticas.
Como con la mayoría de las cosas en TI, depende. ¿Qué problema estás tratando de solucionar haciendo índices de reconstrucción? ¿Puedes demostrar que realmente soluciona el problema? Si es así, modifique los números hasta que encuentre la menor cantidad de mantenimiento que necesita hacer para solucionar el problema.
Si no soluciona el problema, o la razón por la que lo está haciendo es solo para apaciguar algunas métricas que monitorea porque podrían mejorar las cosas, entonces todo lo que está haciendo es quemar CPU e IO y posiblemente empeorar su problema.
Hay un argumento de que arreglar la fragmentación no hará ninguna diferencia en su servidor, entonces, ¿vale la pena hacerlo regularmente?
https://www.brentozar.com/archive/2017/12/index-maintenance-madness/