Esto es lo que he aprendido hasta el momento de mi investigación.
.NET envía configuraciones de conexión que no son las mismas que las que obtiene cuando inicia sesión en Management Studio. Aquí es lo que se ve si oler la conexión con SQL:
-- 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 los que arreglan por encima de todas las consultas que corro cuando se conecte al servidor SQL, para asegurarse de que los ajustes son los mismos.
Para este caso, probé cada configuración individualmente, después de desconectar y volver a conectar, y encontré que cambiar arithabort de apagado a encendido reducía la consulta de 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 Sql Server utiliza 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, al parecer 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 aún no he visto el diff mostrar ningún cambio.
¿Hay algo más acerca de la configuración de arithabort que podría ocasionar que una consulta se ejecute lentamente en algunos casos?
La solución parecía simple: simplemente ponga 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 '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 lleva aproximadamente un segundo recompilar, y esto no es demasiado notorio en un informe que demora de 1 a 10 segundos en regresar (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.
Tuve el mismo problema y http://stackoverflow.com/questions/250713/sqldataadapter-fill-method-slow resolvió mi problema – David