Database Storage Pressure
Category: Storage · Also known as: High Database Storage Metacounter score
WISdom’s composite storage pressure score for the database is high this minute - a single rolled-up health number built from the underlying counters.
What this finding means
Section titled “What this finding means”WISdom’s composite storage pressure score for this database, on a 0 to 100 scale, was high for the minute. It rolls up IO stall times, IO-related waits, and read and write throughput attributable to this database into a single number.
Why it matters
Section titled “Why it matters”Storage is the most expensive resource to add and the one most often blamed without evidence. A composite score with the counters visible underneath is what turns ‘the SAN is slow’ into a claim you can put in front of whoever owns the array, which is the difference between a conversation and an argument.
How WISdom detects it
Section titled “How WISdom detects it”WISdom rolls the storage performance counters and wait statistics for the database into one weighted score per minute, then compares it to the four-week maximum for this minute-of-day. The rule is always evaluated and returns a score every minute.
| Collected from | WISdom Database Storage metacounter - a weighted composite of the perf counters and wait stats for storage at the database level. |
| Compared with | Max value for category during 15 minutes before and 15 minutes after of the same minute in the past 4 weeks |
| Related screen | Performance Metrics |
How it is scored
Section titled “How it is scored”This rule is always evaluated, so it reports a value every minute whether or not it is elevated. It contributes an incident score of 2 when the value exceeds the four-week maximum for this minute-of-day.
How to read the numbers
Section titled “How to read the numbers”Score against History max, then open the counters and separate read pressure from write pressure, because they are different problems. Read pressure usually traces to an access path; write pressure usually traces to log activity or checkpoint behaviour. Stall time per operation is the figure that travels well to a storage team.
What normally causes it
Section titled “What normally causes it”- An access path reading far more pages than the query returns.
- Buffer pool churn pushing logical reads down to physical reads.
- Backups, index maintenance, or ETL sharing the window and the volume.
- Genuine storage latency at the array or the virtualisation layer.
What this finding is not
Section titled “What this finding is not”- Not proof the storage is at fault. Most database storage pressure is read volume the instance should not have generated. Rule that out before escalating.
- Not a host measurement. Host Storage Pressure covers the volumes; this covers this database’s IO against them.
- Not comparable between databases. The score is relative to each database’s own history.
What are some possible resolutions?
Section titled “What are some possible resolutions?”The options below are ranked. Option 1 fixes the cause where it lives and costs nothing; option 3 spends money or escalates, so try it last.
1. Cut the IO at its source
Section titled “1. Cut the IO at its source”Storage pressure inside the database is almost always read volume from a poor access path, or write volume from log activity. Find the statement and the object first.
2. Separate the competing IO
Section titled “2. Separate the competing IO”Backups, index maintenance, and ETL running in the same window will look exactly like a storage limit. Move them apart before sizing anything.
3. Take the numbers to the storage owner
Section titled “3. Take the numbers to the storage owner”If the read volume is legitimate, hand over the stall time and the percentage of measured ceiling. Those two numbers are the capacity case.