Buscamos por distintos sitios y así darte la solución a tu duda, en caso de dificultades puedes dejarnos tu duda y te respondemos porque estamos para ayudarte.
Solución:
Un poco anticuado, pero para cualquiera que termine aquí con un problema similar…
Yo tuve el mismo problema. Para mí resultó ser un rastreo de parámetros, que al principio no entendía lo suficiente como para preocuparme. Agregué un ‘set arithabort on’ que solucionó el problema pero luego volvió. Entonces leí:
http://www.sommarskog.se/query-plan-mysteries.html
Se aclaró -todo-. Debido a que estaba usando Linq to SQL y tenía opciones limitadas para solucionar el problema, terminé usando una guía de plan de consulta (ver el final del enlace) para forzar el plan de consulta que quería.
Las aplicaciones .NET se conectan con la opción deshabilitada de manera predeterminada, pero está habilitada de manera predeterminada en Management Studio. El resultado es que el servidor realmente almacena en caché 2 planes de ejecución separados para la mayoría o todos los procedimientos. Esto afecta la forma en que el servidor realiza los cálculos numéricos y, como tal, puede obtener resultados muy diferentes según el procedimiento. Esta es realmente solo una de las 2 formas comunes en que un proceso puede recibir un plan de ejecución terrible, la otra es la detección de parámetros.
Eche un vistazo a https://web.archive.org/web/20150315031719/http://sqladvice.com/blogs/gstark/archive/2008/02/12/Arithabort-Option-Effects-Stored-Procedure-Performance. aspx para un poco más de discusión al respecto.
Yo diría que es casi seguro que se trataba de un rastreo de parámetros.
A menudo se afirma que SET OPTIONS puede afectar el rendimiento de esta manera, pero todavía tengo que ver una única fuente autorizada para este reclamo, excepto en el caso de que esté utilizando vistas indexadas/columnas calculadas persistentes.
En este caso (para SQL2005+ y a menos que su base de datos esté en modo de compatibilidad con SQL2000). si tienes los dos ARITHABORT y ANSI_WARNINGSOFF luego encontrará que el índice no se está utilizando, por lo que puede tener un escaneo en lugar de la búsqueda deseada (y algunos gastos generales ya que no se puede usar el resultado del cálculo persistente). ADO.NET parece tener por defecto ANSI_WARNINGS ON de una prueba rápida que acabo de hacer.
La afirmación en la respuesta de Ben de que “la forma en que el servidor realiza los cálculos numéricos” puede agregar minutos a un resultado que de otro modo tomaría menos de un segundo simplemente no me parece creíble. Creo que lo que tiende a suceder es que, al investigar un problema de rendimiento, se usa Profiler para identificar la consulta infractora. Esto se pega en Management Studio y se ejecuta y devuelve resultados al instante. La única diferencia aparente entre las conexiones es la ARITH_ABORT opción.
Una prueba rápida en una ventana de Management Studio muestra que cuando SET ARITHABORT OFF está activado y se ejecuta la consulta de que el problema de rendimiento se repite, por lo que aparentemente es un caso cerrado. De hecho, esta parece ser la metodología de solución de problemas utilizada en el enlace de Gregg Stark.
Sin embargo, eso ignora el hecho de que con esa opción configurada puede terminar obteniendo exactamente el mismo mal plan. del caché.
Esta reutilización del plan puede ocurrir incluso si ha iniciado sesión como un usuario diferente al que usa la conexión de la aplicación.
Probé esto ejecutando una consulta de prueba primero desde una aplicación web y luego desde Management Studio con SET ARITHABORT OFF y pude ver los recuentos de uso subiendo desde la siguiente consulta.
SELECT usecounts, cacheobjtype, objtype, text ,query_plan
FROM sys.dm_exec_cached_plans
CROSS APPLY sys.dm_exec_sql_text(plan_handle)
CROSS APPLY sys.dm_exec_query_plan(plan_handle)
Para que este intercambio de planes pf ocurra realmente, todo el caché del plan keys debe ser lo mismo. Así como también arithabort en sí, algunos otros ejemplos son que los usuarios que ejecutan necesitan el mismo esquema predeterminado (si la consulta se basa en la resolución implícita de nombres) y las conexiones necesitan el mismo language colocar.
Una lista más completa de caché de planes keys aquí