performance - services - La consulta rápida se ejecuta lentamente en SSRS
ssrs expression (17)
Tengo un informe de SSRS que llama a un procedimiento almacenado. Si ejecuto el procedimiento almacenado directamente desde una ventana de consulta, regresará en menos de 2 segundos. Sin embargo, la misma consulta ejecutada a partir de un informe de SSRS de 2005 tarda hasta 5 minutos en completarse. Esto no solo sucede en la primera ejecución, sino que ocurre todo el tiempo. Además, no veo este mismo problema en otros entornos.
¿Alguna idea sobre por qué el informe de SSRS se ejecutaría tan lento en este entorno particular?
¿Utiliza "agrupar por" en la tabla SSRS?
Tenía un informe con 3 agrupados por campos y noté que el informe se ejecutó muy lentamente a pesar de tener una consulta ligera, hasta el punto en que ni siquiera puedo marcar valores en el campo de búsqueda.
Luego eliminé las agrupaciones y ahora el informe aumenta en segundos y todo funciona en un instante.
Añadiré que tuve el mismo problema con una consulta de procedimiento no almacenada, solo una declaración de selección simple. Para solucionarlo, declare una variable dentro de la declaración SQL del conjunto de datos y la configuré igual al parámetro SSRS.
¡Qué solución tan molesta! Aún así, ¡gracias a todos por acercarme a la respuesta!
Aparte del problema de detección de parámetros, he encontrado que SSRS generalmente es más lento en el procesamiento del lado del cliente que (en mi caso) los informes de Crystal. El motor SSRS simplemente no parece ser capaz cuando tiene muchas filas para filtrar o agregar localmente. Por supuesto, estos son problemas de diseño de conjuntos de resultados que con frecuencia se pueden abordar (aunque no siempre si se requieren los detalles para el desglose) pero el motor de informes más ... um ... maduro es más indulgente.
En mi caso, solo pude resolverlo eliminando el campo integrado [& TotalPages] de la parte inferior. El tiempo cuando bajó de minutos a menos de un segundo.
Algo extraño que no pude determinar estaba teniendo impacto en el cálculo del total de páginas.
Estaba usando SSRS 2012.
En mi caso, solo tuve que desconectarme y conectar el SSMS. Realicé un perfil de la consulta y la duración de la ejecución fue de 1 minuto, aunque la consulta se ejecuta en menos de 2 segundos. Reinicié la conexión y volví a ejecutar, esta vez la duración mostró el tiempo de ejecución correcto.
En nuestro caso, no se requiere código.
Nota de nuestro servicio de asistencia: "Limpiar su Configuración de Internet solucionará este problema".
Quizás eso significa "caché claro".
Enfrenté el mismo problema. Para mí fue solo para deshacer la opción:
Tablix Properties => Page Break Option => Mantener juntos en una página si es posible
Del Informe SSRS. Intentaba poner todos los registros en la misma página en lugar de crear muchas páginas.
Gracias por las sugerencias proporcionadas aquí. Hemos encontrado una solución y resultó estar relacionada con los parámetros. SQL Server estaba produciendo un plan de ejecución intrincado cuando se ejecutaba desde el informe SSRS debido al "olfateo de parámetros". La solución consistía en declarar variables dentro del procedimiento almacenado y asignar los parámetros entrantes a las variables. Luego, la consulta utilizó las variables en lugar de los parámetros. Esto provocó que la consulta se realizara de forma coherente, ya sea que se llamara desde el Administrador del Servidor SQL o mediante el informe SSRS.
Me encontré con un problema similar de mi procedimiento almacenado ejecutándose rápidamente desde Management Studio pero ejecutándose muy lentamente desde SSRS. Después de una larga lucha, resolví este problema eliminando físicamente el procedimiento almacenado y recreándolo. No estoy seguro de la lógica detrás de esto, pero supongo que es debido al cambio en la estructura de la tabla utilizada en el procedimiento almacenado.
Si su procedimiento almacenado usa servidores vinculados o openquery , pueden ejecutarse rápidamente por sí mismos, pero tardan mucho tiempo en renderizarse en SSRS. Algunas sugerencias generales:
- Recupere los datos directamente del servidor donde se almacenan los datos utilizando una fuente de datos diferente en lugar de usar el servidor vinculado para recuperar los datos.
- Cargue los datos del servidor remoto en una tabla local antes de ejecutar el informe, manteniendo la consulta del informe simple.
- Utilice una variable de tabla para recuperar primero los datos del servidor remoto y luego unirse a sus tablas locales en lugar de devolver directamente una combinación con un servidor vinculado.
Veo que la pregunta ha sido respondida, solo estoy agregando esto en caso de que alguien tenga este mismo problema.
Simplemente deseleccioné ''Repetir columnas de encabezado en cada página'' dentro de las Propiedades de Tablix.
Tuve el informe html problema de salida en el informe de recuperación de 32000 líneas. La consulta se ejecutó rápidamente pero el resultado en el navegador web fue muy lento. En mi caso, tuve que activar "Paginación interactiva" para permitir al usuario ver la primera página y poder generar el archivo de Excel. La ventaja de esta solución es que la primera página aparece rápidamente y el usuario puede generar exportaciones a Excel o PDF, lo que sí es un inconveniente es que el usuario puede desplazarse solo por la página actual. Si el usuario desea ver más contenido, debe usar los botones de navegación arriba de la cuadrícula. En mi caso, el usuario aceptó este comportamiento porque la exportación a Excel era más importante.
Para activar "Paginación interactiva", debe hacer clic en el área libre en el panel de informes y cambiar la propiedad "Tamaño interactivo" / "Altura" en el nivel de informe en el panel Propiedades. Establezca esta propiedad en diferente de 0. Establecí en 8.5 pulgadas en mi caso. Asegúrese también de haber desmarcado la propiedad "Mantener juntos en una página si es posible" en el nivel Tablix (haga clic con el botón derecho en Tablix, luego en "Propiedades de Tablix", luego en "General" / "Opciones de salto de página").
Tuve el mismo escenario ... Informe muy básico, el SP (que solo tiene 1 parámetro) tardaba 5 segundos en recuperar 10K registros, pero el informe tardaría 6 minutos en ejecutarse. De acuerdo con el generador de perfiles y la tabla RS ExecutionLogStorage, el informe estuvo gastando todo el tiempo en la consulta. El comentario de Brian S. me llevó a la solución. Simplemente agregué WITH RECOMPILE antes de la declaración AS en el SP, y ahora el tiempo del informe coincide bastante con el tiempo de ejecución del SP.
Tuve el mismo problema, aquí está mi descripción del problema
"Creé un procedimiento de tienda que generaría 2200 filas y se ejecutaría en casi 2 segundos. Sin embargo, después de llamar al procedimiento de almacenamiento desde SSRS 2008 y ejecutar el informe, nunca se ejecutó y finalmente tengo que matar el BIDS (Business Intelligence Development Studio) del administrador de tareas ".
Lo que intenté: Intenté ejecutar el SP desde el inicio de sesión del usuario del informe, pero el SP también se estaba ejecutando normalmente para ese usuario. Lo comprobé, pero no funcionó.
Solución:
En realidad, el problema es que, aunque SP está generando el resultado, el motor de SSRS se está tomando el tiempo de leer estas muchas filas y devolverlas. Así que agregué la opción WITH RECOMPILE en SP y ejecuté el informe ... aquí fue cuando sucedió el milagro y mi problema se resolvió.
Tuvo el mismo problema y lo solucioné dando al conjunto de datos compartido un parámetro predeterminado y actualizando ese conjunto de datos en el servidor de informes.
Un par de cosas que puede hacer, sin ejecutar el informe real, solo ejecute el sproc desde la pestaña de datos de los servicios de informes. ¿Todavía toma tiempo? Otra opción es utilizar el Analizador de SQL y determinar qué entra y sale del sistema de la base de datos.
Otra cosa que puede hacer para probarlo es recrear un informe simple sin ningún parámetro. Ejecute el informe y vea si hace una diferencia. Puede ser que su informe de RS esté dañado o mal formado, lo que puede hacer que el procesamiento sea muy lento.
Agregue esto al final de su proceso: option(recompile)
Esto hará que el informe se ejecute casi tan rápido como el procedimiento almacenado