¿El tiempo requerido para la reconstrucción del índice depende del nivel de fragmentación?
¿La reconstrucción de un índice fragmentado del 80% tarda aproximadamente 2 minutos si la reconstrucción del mismo índice fragmentado del 40% dura 1 minuto?
Estoy solicitando el TIEMPO DE EJECUCIÓN (por ejemplo, en segundos) que puede requerirse para realizar la acción requerida, no sobre qué acción se requiere en qué situación particular. Soy consciente de las mejores prácticas básicas cuando se deben realizar reorganizaciones de índice o reconstruir / actualizaciones estadísticas.
Esta pregunta NO pregunta sobre REORG y la diferencia entre REORG y REBUILD.
El trasfondo: Debido a la configuración de diferentes trabajos de mantenimiento de índices (cada noche, trabajos más pesados los fines de semana ...), me preguntaba si un trabajo de mantenimiento de índice OFFLINE "ligero intenso" diario debería realizarse mejor en índices fragmentados bajos-medios para mantener el tiempos de inactividad pequeños, o ni siquiera importa, y la reconstrucción en un índice fragmentado al 80% puede tomar el mismo tiempo de inactividad que la misma operación en el mismo índice fragmentado al 40%.
Seguí las sugerencias y traté de descubrir qué estaba pasando. Mi configuración experimental: en un servidor de prueba que no hacía NADA más y no lo usaba nadie ni nada más, creé una tabla con un Índice agrupado en una columna de clave primaria de identificador único con algunas columnas adicionales y diferentes tipos de datos [2 números, 9 fecha y hora, y 2 varchar (1000)] y simplemente agregar filas. Para la prueba presentada agregué unas 305,000 filas.
Luego usé un comando de actualización y actualicé al azar un rango de filas que se filtran en un valor entero y cambié una de las columnas VarChar con un valor de cadena cambiante para crear fragmentación. Después de eso, verifiqué el avg_fragmentation_in_percentnivel actual sys.dm_db_index_physical_stats. Cada vez que creé una "nueva" fragmentación para mi punto de referencia, agregué este valor, incluido el physical_page_countvalor a mis grabaciones, del siguiente diagrama.
Luego corrí: Alter index ... Rebuild with (online=on);
y agarré el CPU timeusando STATISTICS TIME ONen mis grabaciones.
Mis expectativas: esperaba ver al menos la indicación de un tipo de curva lineal que muestre una dependencia entre el nivel de fragmentación y el tiempo de CPU.
Este no es el caso. No estoy seguro de si este procedimiento es realmente apropiado para un buen resultado. ¿Quizás el número de filas / páginas es demasiado bajo?
Sin embargo, los resultados indican que la respuesta a mi pregunta original definitivamente sería NO . Parece que el tiempo de CPU requerido que SQL Server necesita para reconstruir el índice no depende del nivel de fragmentación ni del recuento de páginas del índice subyacente.
El primer gráfico muestra el tiempo de CPU requerido para RECONSTRUIR el índice en comparación con el nivel de fragmentación anterior. Como puede ver, la línea promedio es relativamente constante y no existe una relación observable entre la fragmentación y el tiempo de CPU requerido.
Para respetar la posible influencia del número cambiante de páginas en el índice después de mis actualizaciones que podrían requerir más o menos tiempo para reconstruir, calculé el NIVEL DE FRAGMENTACIÓN * PÁGINAS CONTADO y usé este valor en el segundo gráfico que muestra la relación del tiempo de CPU requerido vs. fragmentación y recuento de páginas.
Como puede ver, esto tampoco indica que el tiempo requerido para la reconstrucción esté influenciado por la fragmentación, incluso si el número de páginas varía.
Después de hacer esas declaraciones, supongo que mi procedimiento debe estar equivocado porque el tiempo de CPU requerido para reconstruir un índice enorme y altamente fragmentado solo puede estar influenciado por el número de filas, y realmente no creo en esta teoría.
Entonces, debido a que realmente y definitivamente quiero descubrir esto ahora, cualquier comentario y recomendación son bienvenidos .
