Reporting Service databases are used to store objects definitions and their metadata. There are placed two databases – Reporting Services Database and Reporting Services Temporary database. Each instance of reporting services in native mode should have defined these two databases in configuration manager. See post Reporting Services, Basic configuration tips .
Reporting Services database
- Here is stored information regarding reporting services repository like reports, schedules, data sources users etc. Bellow few tables you may interested in.
Reporting services temporary database
- Here are stored data used for caching reports
The reporting services database structure is more than clear, based on name of tables. Even so I mention two tables you may be interested in. But as Microsoft states you shouldn’t use your custom queries directly against reporting services database. You should use API to get info you need, except of execution log you can access directly from database. See Microsoft web site for more info https://bit.ly/2Jxn9J6.
-
Catalog table – report server items – reports and theirs pats for example
- here you can find Report Definitions too. But these data are informative only. Do not expect that you if you change report definition here it changes on Report Server too. For such a purpose you should use Reporting Web Services endpoints or Reporting Services Extensions or hack Chunk and Segment tables where are stored the data reporting services work with in binary form
-
ExecutionLogStorage – information regarding repots rendering, processing and data retrieving.
- Here are few views pre-pared from Microsoft team to audit reporting services data
- Dbo.ExecutionLog, dbo.ExecutionLog2, dbo.ExecutionLog3
In next few posts I would like to show you work how you can work with Reporting Service tables since it is good tool how to monitor performance of reports and auditing users access to report serves. Stay in touch.