SSRS Snapshots and History
Overview
SSRS Snapshots and History lists the rendered copies of reports that a Reporting Services catalog is keeping, weighs each one, and says which of them are worth a second look.
A snapshot is a report rendered once and stored, so that opening it costs the data sources nothing and everybody sees the same numbers. Report history is the same thing kept on purpose, several versions deep. Both are useful, and both are where a report server database’s size tends to come from: a report definition is kilobytes, and its stored renderings can be far larger.
The page decides what each stored row is from what in the catalog points at it:
- Current snapshot – the stored rendering a report currently runs from (
Catalog.SnapshotDataID). - History – a rendering that one or more report history entries point at. A rendering that is both reads Current snapshot and history.
- Orphaned – a rendering no report, history entry or report definition points at, and no open session is holding.
- Held by a session – a rendering nothing in the catalog points at that an open report session still holds.
Compiled definitions are not renderings. Every published report and shared dataset keeps its compiled definition in the same table (Catalog.Intermediate), so on a report server that keeps no snapshots at all, every row in that table is one of these. The page leaves them off the chart and the grid and counts them in the line under the headline instead.
Every rendering is weighed rather than just counted, because a server with four enormous snapshots is not tidier than one with forty small ones.
Where to find it
Only shown for a database holding a Reporting Services catalog.
- Tree: expand the report server database, then Real Time > SSRS > Snapshots and History.
- SSRS Caching and Execution: the Snapshots toolbar button, or right click a report that runs from a snapshot and choose Open Snapshots and History.
- SSRS What Fills This Database: the Snapshots toolbar button, or right click one of the rendering tables and choose Which renderings these are.
Requirements
- A Reporting Services catalog database, normally called
ReportServer. The SSRS pages are offered whendbo.ExecutionLoganddbo.Catalogboth exist in the database being looked at. SELECTondbo.SnapshotData,dbo.History,dbo.Catalog,dbo.SegmentedChunk,dbo.ChunkSegmentMappinganddbo.ChunkData.- The query is given 180 seconds. If it does not finish, the page says so rather than drawing an empty grid that looks like an empty server.
The two views
The toolbar has a two part switch, By size and By age, and two buttons that open SSRS Caching and Execution and SSRS What Fills This Database.
By size
One bar per stored rendering, sorted largest first. The label is the report name, or (no report) when neither a report nor a history entry points at the rendering. The line under it is the kind and how long ago it was taken. The value on the right is the rendering’s size.
By age
The same renderings, sorted oldest first, with the bar length set by days since the rendering was taken and the value on the right saying how long ago that was.
Colors and outlines
| Color | Meaning |
|---|---|
| Green | Nothing to say about this rendering |
| Amber | Nothing points at it and it is past its expiration date |
| Red | Orphaned: nothing points at it and no session holds it |
An orphaned or expired rendering also gets an amber outline around its bar. Hover over a bar for the report path, kind, size, page count, when it was taken, when it expires and the notes.
An expiration date only counts on a rendering nothing points at. The report server’s cleanup only removes an expired rendering once nothing references it, so the date on a current snapshot or a history entry decides nothing and is not flagged.
The chart draws as many rows as fit under the page’s chart height limit. When there are more, the note under the chart says how many of how many are shown, and the grid still holds every one.
Reading the grid
| Column | What it holds |
|---|---|
| Report | The report’s catalog path, or (no report or history entry) when nothing in the catalog claims it |
| Kind | Current snapshot, History, Current snapshot and history, Orphaned or Held by a session |
| Taken | When the rendering was created |
| Size | The stored rendering’s size, from both storage formats added together |
| Pages | The page count the report server recorded for the rendering |
| Expires | The expiration date, or no expiry |
| History kept | The report’s snapshot limit: a number of versions, server default, forever, or - when there is no report |
| Notes | Everything the page found about this rendering, in words |
The grid is sorted newest first. Kind and Notes are drawn in amber or red on a rendering that is expired or orphaned.
The Notes column can say:
- Nothing points at this rendering and both reference counts are zero, so the report server’s own cleanup removes it on a later pass (one that stays says that cleanup is not running), with how much space it is holding.
- Nothing points at this rendering yet its permanent reference count is above zero, so the report server’s own cleanup will never remove it, with how much space it is holding.
- Nothing in the catalog points at it and an open report session still holds it.
- It is past its expiration date.
- The report keeps its history forever, so nothing will ever trim it.
- It was rendered for one user’s parameters and cannot be reused by anybody else.
Findings
The headline counts the stored renderings, their total size, and how many are orphaned. The line under it adds, where they apply:
- How much space the orphaned renderings hold.
- How many renderings nothing points at are past their expiration date and waiting on the report server’s own cleanup.
- How many belong to a report whose snapshot limit is unlimited.
- How many were built for one user’s parameters.
- The date of the oldest rendering.
- How many more rows in the table are compiled definitions of published reports and shared datasets, and how much they take, since those are left off the page.
- That sizes add the newer segment storage and the older chunk storage together.
- That the page reads the catalog tables directly, so it covers every item on the report server rather than what the portal would show you.
Actions
- Click a bar to select that rendering’s row in the grid.
- Double click a bar to open its report in SSRS Catalog Inventory with the report’s row selected. A rendering with no report only has its row selected.
- Right click a bar for the same menu as that rendering’s grid row.
- Right click a grid row, below the usual Copy, Copy with Headers and Select All, for:
- Copy report path (when the rendering still has a report)
- Copy the snapshot id
- What caches and what snapshots – opens SSRS Caching and Execution
- This report in the catalog – opens SSRS Catalog Inventory with this report selected, or Open Catalog Inventory when the rendering has no report
- What fills this database – opens SSRS What Fills This Database
- Right click an empty part of the chart to copy the chart to the clipboard.
Nothing on this page deletes a rendering.
Where the data comes from
dbo.SnapshotData, one row per stored rendering or compiled definition, with what points at it found three ways:
- through
dbo.Catalog.SnapshotDataID, which is a report’s current rendering, - through
dbo.History, which is a report’s history entries, and - through
dbo.Catalog.Intermediate, which is a published report’s or shared dataset’s compiled definition. These rows are counted and left off the page.
A row found none of those ways is orphaned, unless its transient reference count says an open session still holds it.
The size is two numbers added together on the client side:
ChunkSegmentMapping.ActualByteCountsummed over the rendering’sSegmentedChunkrows, which is where newer report servers keep the bytes. Summing the mapping rather than measuring the segment avoids charging a shared segment to every chunk that uses it.DATALENGTHofChunkData.Content, which is where older versions kept them. A report server upgraded in place can have renderings in both.
Both are subqueries rather than joins, so a rendering with several chunks is not multiplied into several times its real size.
Related reports
- SSRS Caching and Execution – which reports run from a snapshot or a cache
- SSRS What Fills This Database – how much space the rendering tables take
- SSRS Schedules – the schedules that take snapshots
- SSRS Catalog Inventory – what is published
- SSRS Server Configuration – the server wide snapshot limit
Frequently asked questions
What does “forever” mean in the History kept column? The report’s own snapshot limit is minus one, so its history is never trimmed. Server default means the report has no limit of its own and uses SystemSnapshotLimit, which SSRS Server Configuration shows.
Why is the report shown as “(no report)”? The page found no report whose current rendering is this one, no history entry and no report definition pointing at it. That is how it tells a rendering that still belongs to something from one that does not.
The page says “This report server stores no rendered reports”. Is that a problem? No. Nothing is set to keep its result and no report keeps history, so every report is rendered fresh when somebody opens it. That is the simplest arrangement, and the one that costs the data sources the most. The message also says how many rows the snapshot table holds anyway: those are the compiled definitions every published report and shared dataset keeps there.