Finding meaningful error details to report execution failures

Today a friend of mine asked for a hand with an SSRS error he was getting. I have to admit, at the time I was pretty busy and feel bad that I didn’t answer the question completely. The error was resolved though and the find/fix by him was impressive to say the least. One thing that was frustrating for both of us was the error presented from the report server when this particular report execution failed. In short, the error was not helpful at all. There is resource to find more in-depth descriptions on the error though by turning to the trace logs that are enabled on reporting services. Below, we will go through searching for these descriptive errors in the logs.

On the report server, navigate through the directory structure to the installation folders for the SSRS binary files. In these folder you will find a folder named, LogFiles. This folder will house the default report server trace logs. All execution trace events will be logged in these flat files and can be excellent information to troubleshooting report execution issues. After understanding the trace files, it is also a great way to utilize SSIS to import and report off of them to be more proactive on the report executions.

To read in-depth on the trace logs see, "Report Server Service Trace Log"

Learning how the log files are recycled can be key on finding the file that will help you in a troubleshooting session. The following extract from the BOL documentation explains just how this process is handled.

   "The trace log file is ReportServerService_.log. The trace log is an ASCII text file. You can use any text editor to view the file. This file is located at \Microsoft SQL Server\\Reporting Services\LogFiles. The trace log is created daily, starting with the first entry that occurs after midnight (local time), and whenever the service is restarted. The timestamp is based on Coordinated Universal Time (UTC). The file is in EN-US format. By default, trace logs are limited to 32 megabytes and deleted after 14 days"

Knowing the recycle times and when a new log is created can lower the length of time spent on searching them for the error needed.

Read more: LessThanDot

Posted via email from jasper22's posterous