Esto es lo que he aprendido hasta ahora de mi investigación.
.NET envía configuraciones de conexión que no son las mismas que obtiene cuando inicia sesión en Management Studio. Esto es lo que verá si detecta la conexión con Sql Profiler:
-- network protocol: TCP/IP
set quoted_identifier off
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls off
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read committed
Ahora estoy pegando esa configuración encima de cada consulta que ejecuto cuando inicio sesión en el servidor sql, para asegurarme de que la configuración sea la misma.
Para este caso, probé cada configuración individualmente, después de desconectar y volver a conectar, y descubrí que cambiar arithabort de desactivado a activado redujo la consulta del problema de 90 segundos a 1 segundo.
La explicación más probable está relacionada con el rastreo de parámetros, que es una técnica que utiliza Sql Server para elegir lo que cree que es el plan de consulta más efectivo. Cuando cambia una de las configuraciones de conexión, el optimizador de consultas puede elegir un plan diferente y, en este caso, aparentemente eligió uno malo.
Pero no estoy totalmente convencido de esto. Intenté comparar los planes de consulta reales después de cambiar esta configuración y todavía no he visto que la diferencia muestre ningún cambio.
¿Hay algo más en la configuración de arithabort que podría causar que una consulta se ejecute lentamente en algunos casos?
La solución parecía simple:simplemente coloque set arithabort en la parte superior del procedimiento almacenado. Pero esto podría conducir al problema opuesto:cambiar los parámetros de consulta y de repente se ejecuta más rápido con 'apagado' que con 'encendido'.
Por el momento, estoy ejecutando el procedimiento 'con recompilación' para asegurarme de que el plan se regenere cada vez. Está bien para este informe en particular, ya que toma tal vez un segundo para volver a compilar, y esto no se nota demasiado en un informe que tarda de 1 a 10 segundos en volver (es un monstruo).
Pero no es una opción para otras consultas que se ejecutan con mucha más frecuencia y necesitan regresar lo más rápido posible, en solo unos pocos milisegundos.
