Historic Waits
Overview
The Historic Overview page is the front door to a database’s collected history.
It is a row of metric cards over the stacked historic waits chart – the one chart on the page dense enough to earn the width, which is why it keeps its place while everything else became a card.
Every card clicks through to the full report for its metric, so the page is a routing layer as much as a summary: see which metric looks wrong, click it, land in the report that explains it. The related links strip carries the rest of the database’s historic reports.
The cards
| Card | What it tracks |
|---|---|
| Plan cache hit ratio | How often SQL Server found a plan it could reuse. |
| Page life expectancy | How long a page survives in the buffer pool – the classic memory-pressure signal. |
| CPU | SQL Server CPU against idle, over the collection window. |
| Deadlocks | Recorded deadlocks over time. |
| File size | How the database’s files have grown. |
| Long running queries | Samples the collector recorded. |
A card that cannot be filled shows an error state rather than a blank, so a missing metric is visibly missing rather than silently absent.
The historic waits chart
The stacked waits chart sits below the cards. It is the only chart on the page because it is the only one whose shape carries more than a single number – where the instance spent its waiting time, over time, by category.
Read it against the cards: a rise in a wait category usually has a matching movement in one of them.
Where to find it
A database-level historic page. Select a database in the tree; Historic Overview is one of its sections.
Requirements
This is a historic page. Everything on it reads the DBHealthHistory repository, populated by the Database Health Monitor collection process. Without collection configured for the instance, the cards have nothing to fill from.
Because it reads history rather than the live instance, it works when the monitored server is unavailable.
How the page loads
Built in two passes, so the window paints between them rather than sitting blank while every metric is queried. The first pass lays out the cards; the second fills in the waits chart.
A card that has not reported yet is still working, not empty. If you press Back, the page replays from the top rather than landing on a half-built pass.
How to read the page
- Scan the cards for the one that changed. A metric that moved is more interesting than one that is merely high.
- Read page life expectancy against CPU. Both falling together usually means memory pressure rather than a query problem.
- Check the plan cache hit ratio. A low or falling ratio points at ad hoc SQL – see Plan Cache and One Time Use Queries.
- Look at the waits chart underneath. A category rising at the same time as a card moving is the same event seen twice.
- Click the card rather than navigating manually. That is what they are for.
Common patterns
Page life expectancy falling steadily while file size grows. The database has outgrown the memory allocated to it.
Plan cache hit ratio low and long running queries rising together. Un-parameterised SQL: every call compiles, and compilation time shows up as duration.
Deadlocks clustering at one point in the window. An incident rather than a pattern. Deadlocks by Database has the timeline and the objects involved.
Cards look fine but the waits chart changed shape. Something moved that no single card tracks. The waits chart is the more sensitive instrument.
Everything flat and empty. Collection is probably not configured for this instance.
Related reports
| Report | Why you would go there |
|---|---|
| Historic Waits | The full version of the chart on this page. |
| Long Running History | The samples behind that card, with CPU against elapsed. |
| Deadlocks by Database | The deadlocks behind that card. |
| Plan Cache | Why the cache hit ratio is what it is. |
| CPU by Hour by Day | The full CPU history. |
Frequently asked questions
Why is there only one chart? Because it is the only one whose shape carries more than a single number. Everything else on the page is one metric over time, which a card states more directly than a chart would.
Why is a card showing an error? It could not be filled – usually a missing or unreadable history table. It shows the error rather than a blank so a missing metric is visibly missing.
Why does the page appear in two stages? It is built in two passes so the window paints between them. The cards come first, the waits chart second.
Why is everything empty? Historic collection is most likely not configured for this instance. Nothing on this page reads the live server.
Do the cards click through? Yes – each one opens the full report for its metric. That is the fastest way to use the page.