La consulta del SQL Server se ejecuta más despacio desde ADO.NET que en SSMS

Question

Tengo una consulta de un sitio web que tarda de 15 a 30 segundos, mientras que la misma consulta se ejecuta en .5 segundos desde el estudio de SQL Server Management. No puedo ver ningún problema de bloqueo con el Analizador de SQL, ni puedo reproducir el retraso manualmente desde SSMS. Hace una semana, me separé y volví a conectar la base de datos que parecía solucionar milagrosamente el problema. Hoy, cuando el problema volvió a aparecer feo, intenté simplemente reconstruir los índices. Esto también solucionó el problema. Sin embargo, no creo que sea necesariamente un problema de índice, ya que, a mi entender, los índices no se reconstruirán automáticamente en un simple detach/attach.

¿Alguna idea de lo que podría estar causando el retraso? Lo primero que pensé fue que tal vez algún parámetro que olfatea el procedimiento almacenado que se llama (dijo que el proceso almacenado ejecuta un CTE, si es que eso importa) estaba causando un mal plan de consulta, lo que explicaría la naturaleza intermitente del problema. Dado que tanto la separación/reinserción como la reconstrucción de un índice deberían invalidar teóricamente el plan de consulta en caché, esto tiene sentido, pero no estoy seguro de cómo verificar esto. Además, ¿por qué la misma consulta (copiada directamente del Analizador de SQL con los mismos parámetros exactos) no presenta el mismo retraso cuando se ejecuta manualmente a través de SSMS?

¿Alguna idea?

Answer 1

Si se almacena en caché un plan incorrecto, también se debe usar el mismo plan incorrecto de SSMS, si ejecuta la misma consulta con argumentos idénticos.

No puede haber mejor solución que encontrar la causa raíz. Tratar de mirar y tocar varias configuraciones con la esperanza de que solucione el problema nunca le dará la confianza de que realmente está arreglado. Además, la próxima vez el sistema puede tener un problema diferente y creerá que este mismo problema reapareció y aplicará una mala solución.

Lo mejor que se debe intentar es capturar el plan de ejecución incorrecto. Showplan XML Event Class El evento Profiler es su amigo, puede obtener el plan de la llamada ADO.Net. Este es un evento muy pesado, por lo que debe adjuntar un generador de perfiles y capturarlo solo cuando el problema se manifieste, en una sesión corta.

Las estadísticas de IO de consulta también pueden ser útiles. Los eventos RPC:Completed y SQL: Batch Completed incluyen lecturas y escrituras para que pueda comparar la cantidad de IO lógico realizado mediante la invocación de ADO.Net frente a SSMS. Una gran diferencia (para exactamente la misma consulta y params) indican diferentes planes. sys.dm_exec_query_stats es otra avenida de investigación. Puede encontrar su (s) plan (es) de consulta allí e inspeccionar las estadísticas de ejecución.

Todo esto debería ayudar a establecer con certeza si el problema es un mal plan o alguna otra cosa, para empezar.

Answer 2

¿Es posible que su consulta ADO.NET se esté ejecutando después de que el sistema haya estado ocupado haciendo otras cosas, de modo que los datos que necesita ya no estén en la RAM? Y cuando pruebas en SSMS, es?

Puede comprobar que mediante la ejecución de los siguientes dos comandos de SSMS antes de ejecutar la consulta:

CHECKPOINT 
DBCC DROPCLEANBUFFERS 

Si eso hace que los SSMS consulta para ejecutar lentamente, a continuación, hay algunos trucos que puede jugar en el ADO.NET para ayudarlo a funcionar más rápido.

Answer 3

He estado teniendo el mismo problema. La única forma en que puedo solucionar esto es configurar ARITHABORT. pero desafortunadamente cuando ocurre otra vez Tengo que desactivar ARITHABORT.

No tengo ni idea de qué tiene que ver ARITHABORT con esto pero funciona, he estado teniendo este problema durante más de 2 años y todavía no hay solución.Los databses estoy trabajando con más de 300 GB son así que quizás es un problema de tamaño ...

lo más cerca que llegué a la solución de este problema era de un post anterior Google Groups post

Avísame si ha logrado Resuelve completamente este problema ya que es muy frustrante.

Answer 4

Sé que estoy reflexionando sobre este tema muy tarde, pero quería publicar una solución que encontré cuando tenía un problema similar. En resumen, al agregar el comando SET ARITHABORT ON al inicio de mis procedimientos, el rendimiento de las consultas del sitio web estuvo en línea con el rendimiento visto desde las herramientas de SQL Server. Esta opción generalmente se establece en la conexión cuando ejecuta una consulta desde QA o SSMS (puede cambiar esa opción, pero es la predeterminada).

En mi caso, tenía aproximadamente 15 procesos almacenados diferentes que realizaban agregados matemáticos (SUM, COUNT, AVG, STDEV) en un conjunto de datos bastante considerable (de 10 a 100 de miles de filas) - agregando la opción SET ARITHABORT ON los moví a todos de 3 a 5 segundos cada uno a 20-30 ms.

Entonces, con suerte eso ayuda a alguien más.

Answer 5

Simon Sabin tiene una gran sesión sobre "cuando falla un plan de consulta" (http://sqlbits.com/Sessions/Event5/When_a_query_plan_goes_wrong) que trata sobre cómo abordar este problema dentro de los procesos utilizando varias sugerencias de "optimización para" y para ayudar a un proc a generar un plan coherente y no use el parámetro predeterminado sniffing.

Sin embargo, tengo un problema con una consulta ad-hoc (no en un proceso) donde el plan SSMS y el plan ASP son exactamente los mismos (análisis de tabla/índice agrupado) y la consulta ASP tarda 3+ minutos en lugar de 1 segundo. (En este caso, la exploración de tabla resulta ser una respuesta decente para obtener los resultados.)

¿Alguien quiere explicar eso?