Estimating Report Server Database Requirements
A report server database provides internal storage to one or more report servers. Disk space requirements can vary widely and are difficult to predict. Variables include the number of servers and users that are serviced by a single report server database, and whether you store full reports that include data (for example, report snapshots or report history).
The report server database can be installed on a remote SQL Server instance, or in a failover cluster. Installing the database on a separate, fast computer provides the best performance. The primary factor in improving performance is to speed disk access on the computer hosting the report server database.
To understand your disk space requirements and database size limits, you must monitor the database size over time and during high-use periods. For more information about which tools and techniques to use, see Monitoring Report Server Performance, Report and Snapshot Size Limits, and Planning for Scalability and Performance with Reporting Services on www.msdn.microsoft.com.
All of the items that are described in this topic are allocated space in a report server database or in the report server temporary database. Although each item is discussed separately, you cannot allocate or control space for individual item categories. For example, you cannot specify maximum limits for resources, caching, or report history. When estimating database size requirements, you must consider all of these items as a whole.
Reports, Folders, Shared Data Source Items, and Metadata
Report definitions, folders, shared data source items, and other metadata such as schedules, subscriptions, and properties are stored in a report server database. The amount of space that is required for storing these items is small in comparison to the other items discussed in this topic.
Resources
Resources are stored as binary large objects (BLOBs). If you are storing image files and collateral documents with your reports, the amount of space that you allocate to resources can be small. However, if you are using resources as part of an archiving strategy (for example, uploading a generated report as a PDF file), your storage requirements for resources could be very large.
Session State Information
Session state information is stored in the report server temporary database, in temporary tables that grow in response to the number of open sessions. Space requirements vary based on the number of users. One row is created for each new session. Unless you have a very large number of users, session state data is not a significant consideration in estimating database size requirements.
Cached Reports, Report History Snapshots, and Report Execution Snapshots
Cached reports (also known as temporary snapshots) are stored in the report server temporary database, in temporary tables, for a period of time (a cached copy may expire after a number of minutes or at a scheduled time). A cached report includes query results. It can be far larger than the report definition upon which it is based. If caching reports is part of your performance plan, you should allocate a sizeable amount of space for these reports.
For parameterized reports, a separate cached report can be created for every combination of parameter values. For example, if a report has a Region parameter that accepts North, South, East, and West as values, a cached copy for each region will be created.
Snapshots, whether they are saved as report history or used only for performance gains, are stored in the report server database (not in temporary tables). As with cached reports, these items may include a large rowset. If you are using report history to archive reports, you must plan on allocating more space over time to accommodate additional snapshots.