¿Por qué un SSRS informa el tiempo de espera cuando el procedimiento almacenado se basa en resultados de resultados en unos pocos segundos?

Question

Tengo un informe que muestra los datos devueltos de un procedimiento almacenado. Al usar el generador de perfiles, puedo capturar la llamada al procedimiento almacenado desde los servicios de informes.

El informe falla indicando que el informe se agotó, pero puedo ejecutar el procedimiento almacenado desde SSMS y devuelve los datos de cinco a seis segundos.

Tenga en cuenta que, en la ejecución de prueba de ejemplo, solo se devuelven dos filas al informe para su procesamiento, aunque dentro del procedimiento almacenado puede haber estado trabajando en miles o incluso millones de registros para recopilar el resultado pasado a los servicios de informes.

Sé que el procedimiento almacenado podría optimizarse más, pero no entiendo por qué el SSRS se desconecta cuando parece que la ejecución solo tarda unos segundos en ejecutarse desde el SSMS.

También ha surgido otro problema. Si vuelvo a crear el procedimiento almacenado, el informe vuelve a mostrarse perfectamente bien. Eso está bien, excepto después de un corto período de tiempo, el informe comienza a agotarse el tiempo de espera nuevamente.

El retorno del tiempo de espera parece estar relacionado con los nuevos datos que se agregan a la tabla principal contra la que se está ejecutando el informe. En el ejemplo que estaba probando, solo cien registros nuevos que se insertaron fueron suficientes para arruinar el informe.

Me imagino que más correctamente no es el informe que es la causa raíz. Es el procedimiento almacenado que está causando el tiempo de espera cuando se ejecuta desde SSRS.

Una vez que se agote el tiempo de espera, lo mejor que puedo hacer es reconstruir el procedimiento almacenado. Esto no parece ser una solución ideal.

El problema también parece estar ocurriendo en nuestro entorno de producción. Nuestras plataformas de prueba y desarrollo no parecen estar mostrando el mismo problema. Aunque dev y test no tienen el mismo volumen de registros que la producción.

Answer 1

El problema, como lo describió, parece provenir de variaciones en el plan de ejecución de algunas partes en su procedimiento almacenado. Observe qué estadísticas se mantienen en las tablas utilizadas y cómo las nuevas filas las afectan.

  

Si está agregando muchas filas en la   final del rango de una columna (piense   sobre la adición de números automáticos, o   marcas de tiempo), el histograma para ese   columna quedará obsoleta rápidamente.   Puede forzar una actualización inmediata desde   T-SQL ejecutando la ACTUALIZACIÓN   Declaración de ESTADÍSTICAS.

Answer 2

También he tenido este problema en el que el SPROC tarda segundos en ejecutarse, pero el SSRS simplemente se agota.

Por mi propia experiencia, he descubierto que hay un par de métodos diferentes para superar este problema.

1. ¡El parámetro está olfateando! Cuando su procedimiento almacenado se ejecute desde SSRS, " sniff " sus parámetros para ver cómo los está utilizando su SPROC. SQL Server producirá un plan de ejecución basado en sus hallazgos. Esto es bueno la primera vez que ejecuta su SPROC, pero no desea que lo haga cada vez que ejecute su informe. Así que declaro un nuevo conjunto de variables en la parte superior de mis SPROC que simplemente almacenan los parámetros pasados ??en la consulta y uso estos nuevos parámetros a lo largo de la consulta.

Ejemplo:

CREATE PROCEDURE [dbo].[usp_REPORT_ITD001]
@StartDate DATETIME,
@EndDate DATETIME,
@ReportTab INT
AS

-- Deter parameter sniffing
DECLARE @snf_StartDate DATETIME = @StartDate
DECLARE @snf_EndDate DATETIME = @EndDate
DECLARE @snf_ReportTab INT = @ReportTab

... esto significa que cuando su SPORC es ejecutado por SSRS, solo está mirando las primeras filas en su consulta para los parámetros pasados ??en lugar de la totalidad de su consulta. Lo que reduce considerablemente el tiempo de ejecución en SSRS.

1. Si su SPROC tiene muchas tablas temporales que se declaran como variables ( DECLARE @MyTable AS TABLE ), estas son realmente intensivas en el servidor (en términos de memoria) al generar informes. Al usar tablas temporales hash ( SELECCIONE MyCol1, MyCol2 INTO #MyTable ) en su lugar, SQL Server almacenará sus tablas temporales en TempDB en el servidor en lugar de en la memoria del sistema, haciendo que la generación de informes sea menos intensiva.

Answer 3

en algún momento agregar la opción WITH RECOMPILE a la sentencia CREATE del procedimiento almacenado ayuda. Esto es efectivo en situaciones en las que el número de registros explorados por el procedimiento cambia en la forma en que el plan de ejecución original no es óptimo.

Answer 4

Básicamente, todo lo que he hecho hasta ahora ha sido optimizar el sproc un poco más y parece que al menos soluciona temporalmente el problema.

Todavía me gustaría saber cuál es la diferencia entre llamar al sproc desde SSMS y SSRS.