Dans les précédentes versions de SQL Server Reporting Services, les données d’usage des rapports étaient stockées dans des fichiers de log, similaire à Microsoft Internet Information Services (IIS). Ce qui était tout à fait valable puisqu’il n’était pas possible de faire du clustering de serveurs frontaux (plusieurs serveurs web pour générer les mêmes rapports).

Tout cela est expliqué dans les pages suivantes :

• Monitoring Report Execution Performance with Execution Logs
• Server Management Report Samples

Avec SQL Server 2008 R2, la possibilité de mettre plusieurs serveurs de rapport en cluster a impliqué la modification de cette fonctionnalité en stockant ces informations dans une base de données. Cette base est donc directement celle utilisée par le moteur de rapport : « ReportServer », via plusieurs tables.

Il est déconseillé d’utiliser des requêtes directement dans les tables, à cette fin, plusieurs vues ont été développées :

• dbo.ExecutionLog
• dbo.ExecutionLog2
• dbo . ExecutionLog3 : La vue à utiliser

Il est possible de voir les données disponibles dans cette vue avec la requête :

USE ReportServer

select * from ExecutionLog3 order by TimeStart DESC

Plusieurs articles traîtent ce sujet :

• Report Server Execution Log and the ExecutionLog3 view
• Querying the Report Server Execution Log
• ExecutionLog2 View - Analyzing and Optimizing Reports

Cette fonctionnalité est activée de base avec des valeurs par défaut, notamment la durée de préservation des logs pour 60 jours (Cf. clé de « ExecutionLogDaysKept » dans la table « ConfigurationInfo »). Il convient de modifier ce paramètre si vous souhaité avoir un historique plus long tel qu’une année.

USE ReportServer

GO

 

UPDATE ConfigurationInfo

SET Value = '365'

WHERE Name = 'ExecutionLogDaysKept'

Il faut aussi modifier les paramètres de la base de données sur le mode de croissance de la base de données selon votre configuration. Par exemple, augmentation du fichier de base de données par bloc de 500 MB

Il nous faut maintenant voir comment exploiter ces données autrement que par les requêtes SQL en direct.