SSRS: Estadísticas de uso, rendimiento de la ejecución de informes y log de errores de reporting services

Por defecto cuando pensamos en el rendimiento de la ejecución de informes en reporting services lo primero que nos viene a la cabeza es el último informe que hemos creado. Se supone que antes de subirlo al portal de informes se supone que hemos probado en el entorno de test, con un volumen de datos similar y lo hemos validado a nivel lógico de datos. En términos de rendimiento es obligatorio, al menos para mi, controlar la ejecución de la consulta y optimizarla mirando que falla en el plan de ejecución y si hace falta donde está el cuello de botella usando el Profiler.

La cuestión es que cada día no podemos mirar ni controlar todo lo que se hace en la base de datos ni que sucede con aquel informe 'básico' implementado hace un año que coge los datos del ERP. Puede suceder que las tablas que usa hayan crecido de forma exponencial etc etc. Aunque podemos monitorizar también con los contadores de rendimiento desde el sistema operativo, cosas como esta suceden y si empezamos a recibir alertas o un usuario se percata de cierta lentitud lo suyo es tener alguna herramienta y saber cual es la carga de trabajo media y que de forma puntual nos permita analizar anomalías o picos de trabajo no habituales. Para eso podemos consultar las tablas de la base de datos que usa repoting services.

Para empezar debemos saber como se llama. Nos vamos a la Administrador de Configuración de Reporting Services, nos conectamos a la instancia que toque y miramos la pestaña Base de Datos.

Toda la información que podamos sacar casi siempre parte de las vistas ExecutionLog, ExecutionLog2 y ExecutionLog3 (SqlServer 08 R2). Estas contienen el registro de ejecución de cada informe. Otras tablas de uso obligado son Catalog y Subscriptions que contienen el detalle de informes y las suscripciones existentes respectivament.

A continuación algunas consultas útiles (suponemos que bbdd es ReportServer):

-- Informes mas usados

SELECT Name Informe, b.path Ruta, 
       COUNT(*) AS Ejecuciones
FROM ReportServer.dbo.ExecutionLog EL 
     JOIN FTXReportServer.dbo.CATALOG b 
     ON EL.reportid = b.itemid 
GROUP BY Name,b.path
ORDER BY COUNT(*)DESC;

-- Principales consumidores (usuarios)

SELECT UserName Usuario, COUNT(*) AS Ejecuciones,
       SUM(l.TimeDataRetrieval) MS_SUMDATARETRIEVAL, 
       SUM(l.TimeProcessing)MS_SUMPROCESSING, 
       SUM(l.TimeRendering)MS_SUMRENDERING,
       SUM(DATEDIFF(ms, l.TimeStart, l.TimeEnd)) AS MS_SUMTOTAL
FROM ReportServer.dbo.ExecutionLog2 l 
GROUP BY UserName ORDER BY MS_SUMTOTAL DESC;

-- Reports más lentos

SELECT TOP 10 Name Informe, b.path Ruta, Parameters Parametros,
       FORMAT Formato,TimeStart Inicio, TimeEnd Fin, ByteCount,
       (TimedataRetrieval+Timeprocessing+TimeRendering)/1000 AS Seg_TiempoTotal
FROM
FTXReportServer.dbo.ExecutionLog EL 
     JOIN FTXReportServer.dbo.CATALOG b 
     ON EL.reportid = b.itemid
ORDER BY TimedataRetrieval+Timeprocessing+TimeRendering DESC;

-- Control de suscripciones que se entregan via mail

SELECT c.Name AS INFORME, s.LastRunTime AS ULTIMA_EJECUCION,
       CONVERT(char(60), s.LastStatus) AS RESULTADO
FROM ReportServer.dbo.Subscriptions s 
     INNER JOIN ReportServer.dbo.Catalog c 
        ON c.ItemID = s.Report_OID 
WHERE DeliveryExtension LIKE '%Email%'
ORDER BY ULTIMA_EJECUCION DESC;

Log de errores

Para el que no lo sepa el log de errores en ejecución de informes de reporting services es un fichero que podemos encontrar en la capeta definida para la instancia de RS, carpeta ReportingServices\LogFiles. Esto es útil saberlo porque por ejemplo en modo de ejecución integrada con Sharepoint Services, si se produce un error en la ejecución de un informe el mensaje que aparece es bastante escueto y da poca información...