procedimientos - Extraño problema con el plan de ejecución del procedimiento de SQL Server
procedimiento almacenado sql server select (2)
También encontré dos casos "extraños" con Sql Server 2005, que también podrían relacionarse con su problema.
En el primer caso, mi procedimiento se ejecutó muy rápido, cuando se ejecutaba como dbo, y era lento cuando se ejecutaba desde la aplicación, bajo una cuenta de usuario diferente.
En el segundo caso, el plan de consultas del procedimiento se optimizó para los valores de los parámetros con los que se invocó el procedimiento por primera vez, y este plan se reutilizó posteriormente para otros valores de parámetros, lo que dio como resultado una ejecución lenta.
Para este segundo caso, la solución fue copiar los valores de los parámetros en variables locales en el procedimiento y luego usar las variables en las consultas en lugar de los parámetros.
Me preguntaba si ustedes podrían ayudarme a llegar al fondo de un problema extraño que tuve recientemente en SQL Server.
Tengo un procedimiento almacenado (vamos a llamar a SPold ) que es razonablemente grande con una gran cantidad de cálculos (no se puede hacer esto en la aplicación ya que la información para alrededor de 6000 usuarios debe volverse en una sola vez (reduzco esto a 1000 basado en el apellido)). El procedimiento almacenado generalmente se ejecuta en un par de segundos y se inicia una vez cada dos minutos.
Ahora, esta mañana, el procedimiento almacenado tardaba de repente de 4 a 10 veces en ejecutarse, lo que provocaba una serie de tiempos de espera. Descubrí que haciendo una copia del procedimiento con un nuevo nombre ( SPnew ) y ejecutándola, obtendría tiempos de ejecución rápidos nuevamente. Esto me indicó que el plan de ejecución era el problema con el original, SPold , así que decidí ejecutarlo con la recompilación. Esto devolvería los resultados más rápido (aunque no tan rápido como SPnew ), pero las llamadas posteriores de los usuarios a SPold volvieron a ser lentas. Era como si el nuevo plan no se cumpliera.
Lo que he hecho es arreglar esto, poner Exec SPnew en SPold , y ahora las llamadas a SPold vuelven rápidamente.
¿Alguien tiene alguna idea de lo que está pasando aquí? Lo único que se actualizó de la noche a la mañana fueron las estadísticas, aunque creo que esto debería afectar tanto a SPold como a SPnew .
Parece que está experimentando un plan de consulta en caché incorrecto debido a la detección de parámetros.
¿Puedes publicar el procedimiento almacenado?
En SQL Server 2005, puede usar la sugerencia de consulta OPTIMIZE FOR para obtener los valores preferidos de los parámetros para solucionar algunos de los problemas asociados con la detección de parámetros:
OPTIMIZAR PARA Indica al optimizador de consultas que use un valor particular para una variable local cuando la consulta se compila y optimiza. El valor se usa solo durante la optimización de la consulta y no durante la ejecución de la consulta. OPTIMIZE FOR puede contrarrestar el comportamiento de detección de parámetros del optimizador o puede utilizarse al crear guías de planes. Para obtener más información, vea Recompilación de procedimientos almacenados y optimización de consultas en aplicaciones implementadas mediante el uso de guías de planes .
Aunque SQL Server 2005 no admite OPTIMIZE FOR UNKNOWN (introducido en SQL Server 2008), eliminará la detección de parámetros para un parámetro dado:
OPTION (OPTIMIZE FOR (@myParam UNKNOWN))
Puede lograr el mismo efecto en SQL Server 2005 copiando el parámetro en una variable local, y luego usar la variable local en la consulta.