¿Por qué tarda tanto en calcular un plan de ejecución?

Uno de nuestros clientes acaba de actualizar a un nuevo servidor.

Para un procedimiento almacenado en particular, la primera vez que lo ejecuta, lleva más de tres minutos ejecutarlo. Las ejecuciones posteriores duran menos de 1 segundo.

Esto me lleva a creer que los primeros tres minutos se dedican principalmente al cálculo del plan de ejecución. Las ejecuciones posteriores solo usan el plan en caché y se ejecutan instantáneamente.

En nuestras bases de datos de prueba, se tarda unos 5 segundos en calcular el plan para el mismo procedimiento.

No veo nada terrible en el plan en sí, aunque no me imagino que sea relevante ya que el plan muestra cuánto tiempo lleva ejecutar la consulta, no calcularla.

El servidor es de 16 núcleos con 24 gb de memoria. No se produce una gran carga de CPU o memoria.

¿Qué es lo que podría estar causando un cálculo tan lento solo en una base de datos en particular?

¿Qué pasos puedo tomar para encontrar la causa del problema?

Editar

Entonces logré acceder al servidor y ejecuté la consulta con SET SHOWPLAN_XML ON .

Puedo confirmar que el tiempo de compilación de la consulta ocupa el 99% del tiempo de ejecución de la consulta. El StatementOptmEarlyAbortReason es "TimeOut" , en nuestra base de datos de prueba con una copia de su base de datos, el motivo es MemoryLimitExceeded.

sql-server sql-server-2008 execution-plan

— Mongus Pong
fuente

¿Estás seguro de que la compilación del plan lleva mucho tiempo, no solo leer datos en caché del disco?

— Mark Storey-Smith

El tiempo de compilación aparece en el plan XML en sí. ¿Ha identificado que definitivamente es tiempo de compilación y no otra cosa, por ejemplo, actualización automática sincrónica de estadísticas? ¿En qué versión de SQL Server estás?

— Martin Smith

@ MarkStorey-Smith Bueno, no estoy realmente seguro de nada. Sé que ejecutar DBCC FREEPROCCACHE , que solo borra ese caché del plan, demorará el tiempo de consulta siguiente hasta 3 minutos.

— Mongus Pong

@ MartinSmith Ah, sí, muy útil, he estado usando el plan de consulta visual. Sí, el tiempo de compilación es aproximadamente el tiempo de ejecución completo de la consulta. Estamos en SQL Server 2008 R2.

— Mongus Pong

@MongusPong: si crea una copia de estadísticas de la base de datos de producción, ¿puede reproducirla en su entorno de prueba? ¿Para qué dice el plan StatementOptmEarlyAbortReason?

— Martin Smith

Odio responder mi propia pregunta, especialmente porque he recibido tanta ayuda de otros para encontrar la solución, pero aquí va.

El problema se debió a algunas estadísticas de fallas en la base de datos. Mirando el plan de ejecución, el optimizador esperaba 11.5tb de datos devueltos por la consulta. En realidad se estaba recibiendo 87kb. Ahora sé que enormes desajustes entre las filas esperadas y reales devueltas es una señal de que las estadísticas están desactualizadas.

Simplemente corriendo

exec sp_updatestats

obliga a la base de datos a actualizar las estadísticas de todas las tablas.

Esto ha reducido el tiempo de ejecución de la consulta de 3 minutos a 6 segundos. ¡Todos ganadores!

Gracias por toda la ayuda chicos. : 0)

— Mongus Pong
fuente