Rendimiento lento de Reporting Services, muy rápido en QueryAnalyser

Question

Estamos utilizando SQL Server 2005 con Reporting Services.

Tenemos una serie de informes, cada uno con una consulta SQL relativamente simple - por "relativamente" quiero decir que tenemos algunas combinaciones, pero nada peor que eso. No llamamos a ningún procedimiento almacenado en nuestras consultas; este no es un caso de olfateo de parámetros.

Al ejecutar uno de estos informes (llamémoslo informe A) a través de Reporting Services, lleva mucho tiempo completarlo, en el orden de decenas de minutos o incluso horas. Al ejecutar la consulta SQL correspondiente en el Analizador de consultas, se completa en unos pocos segundos.

El número de filas devueltas desde la base de datos puede ser tan solo de 1; sin embargo, el informe nunca termina.

Los otros informes funcionan bien.

Al mirar en la tabla ExecutionLog en Reporting Services, puedo ver que la mayor parte del tiempo está en TimeDataRetrieval (y estamos hablando de millones de segundos aquí ...) - esas veces que el informe realmente completa. Si el informe se anula manualmente, TimeDataRetrieveal es cero y TimeProcessing es absurdamente alto en su lugar.

He revisado los registros de Reporting Services, pero todo parece normal.

Ahora, antes de comenzar a sugerir "bloqueo" - bueno, nuestras consultas tienen activada la pista nolock.

Tal como está, he llegado al límite de mi imaginación tratando de encontrar el error. Cualquier pensamiento, comprensión será apreciado gustosamente.

/Christoffer

Answer 1

Terminé eliminando la consulta, básicamente una declaración a la vez, hasta que encontré al culpable. Una de las combinaciones en la consulta se unió en una tabla en constante crecimiento (millones de filas), utilizando una sugerencia "with (nolock index (x))".

Al eliminar la sugerencia de índice en el Analizador de consultas obtuve el mismo resultado que en Reporting Services: una consulta muy lenta . Esto no es sorprendente en sí mismo, pero de hecho parecía que la consulta, cuando se ejecutaba a través de RS, no usaba la sugerencia.

Intenté ejecutar el informe en RS nuevamente, usando la instrucción SET FORCEPLAN ON. Y ... funcionó: el tiempo de ejecución es ahora de unos pocos segundos, como debería ser.Según tengo entendido, la opción FORCEPLAN obliga al SQL Server a procesar las uniones en el orden indicado Y a tener en cuenta cualquier sugerencia.

¿Alguien tiene alguna idea de por qué la consulta a través de RS ignoraría la sugerencia, cuando obviamente el Analizador de consultas lo tiene en cuenta?

Answer 2

Mientras se ejecuta el informe, trate plan de ejecución de la captura co mediante el Analizador de SQL. Eche un vistazo si no tiene operadores CONVER_IMPLICIT, por ejemplo, y escaneos de tabla/índice en general.

http://msdn.microsoft.com/en-us/library/ms190233.aspx

Las conversiones impiden índices se utilicen y pueden ocurrir si se pasan parámetros que tienen tipo diferente de las columnas se comparan contra.

Puede intentar agregar OPCIÓN (RECOMPRA) a la consulta del informe, es posible que su informe sea víctima de parameter sniffing.

Compruebe si sus consultas utilizan funciones escalares definidas por el usuario. Pueden ser verdaderos asesinos de rendimiento. Si los tiene, es posible convertirlos a table valued functions.

Answer 3

Una actualización rápida: parece que cualquier consulta que requiera más de 30 segundos para ejecutarse causará automáticamente un tiempo de espera en Reporting Services. Mientras SET FORCEPLAN ON resolvía los problemas para algunos de los informes, todavía había informes de problemas que expirarían. Estas consultas aún funcionaban bien en el Analizador de consultas, aunque el tiempo de ejecución era superior a 30 segundos. Después de eliminar todos los demás problemas posibles con la configuración de tiempo de espera, en el servidor SQL, en Reporting Services, rsserver.config, en el IIS, descubrí que aún había un tiempo de espera que no podía modificar.

Mi sospecha es que tiene que ver con el tiempo de espera predeterminado de ADO.NET, y que Microsoft nos ha dejado sin forma de modificar este valor.

Finalmente, terminé teniendo una mirada más profunda a la consulta, reordenándola lo mejor que pude, y logré quitar algunos segundos del tiempo de ejecución. Ahora, finalmente, los informes se están ejecutando como deberían.

Este tiempo de espera no modificable me preocupa, sin embargo, ¿qué sucederá si el servidor SQL tiene una carga mayor de lo normal cuando se ejecuta la consulta?

Answer 4

Me he enfrentado a la misma situación.

En Management Studio, los resultados llegaron después de veinte segundos, pero cuando ejecuté el informe en Visual Studio bloqueó el sistema.

En el Analizador de SQL he rastreado la consulta y se dio cuenta que transforma mi consulta como:

exec sp_executesql N' 
       .................... 
       ....................' 
, @dateparameter1 = '2010-06-01 00:00:00' 
, @datepamareter2 = '2010-06-02 00:00:00' 
, @stringparameter=null 

He examinado el plan de ejecución y se dio cuenta de que yo era una víctima de descubrimiento de parámetros.

he reorganizado mi consulta, ya que se le dijo here, y funciona bien ahora ..

Answer 5

Me pasó también, fue descubrimiento de parámetros. Estaba usando la misma vista del informe para usar como filtro, simplemente usando los campos que quería.

Lo que hice fue crear una vista para el filtro y fue resuelto.