Disk Latency by Hour by Day

Overview

The Disk Latency by Hour by Day report shows when storage was slower than usual.

It is the odd one out in the by-hour-by-day family, and deliberately so. The others ask how busy was this hour and colour it on a scale from nothing to the peak. This one asks how far from typical this hour was – in either direction.

That difference is not cosmetic. Storage latency has no meaningful zero and no meaningful maximum; what matters is deviation. Eight milliseconds is excellent on one array and alarming on another, so a scale anchored to absolute magnitude would say nothing useful about either. Anchored to that volume’s own typical behaviour, it says exactly the right thing: this hour was not like the others.

Hours run down, days across, one cell per hour – with a drive selector and a read/write selector, because those are genuinely different measurements.

The Disk Latency by Hour by Day report
One drive and one direction at a time, on a diverging scale – outliers in both directions, with typical as the neutral midpoint.

Where to find it

An instance-level historic report. Right-click the server in the tree and open it from the historic reports. The page title reads Disk Latency by Hour by Day (historic) for <server name>.

Reading the heat map

Each cell is one hour of one day, and the colour is distance from typical, not magnitude.

The legend has five swatches with the neutral midpoint in the centre, so it reads as outliers both ways rather than as a scale from low to high. A cell in the middle of the ramp is an ordinary hour for that volume. Cells at either end are the ones worth looking at.

Both ends are findings. Unusually slow is the obvious one. Unusually fast is worth a glance too – it often means the workload that normally runs then did not run, which is its own kind of news.

This is genuinely a different colour model from the other heat maps, not the same one with the percent sign removed. Everything else the controls share – geometry, typography, caching, hit-testing – comes from the same render core, so a rendering fix lands in both.

No data is not typical

An hour where nothing was recorded is drawn differently from an hour that measured typical latency. On a diverging scale this matters more than usual, because the neutral midpoint colour means “ordinary” – and a gap in collection painted as ordinary would be actively misleading.

The selectors

Control What it does
Drive Which volume to draw. Populated from the drives the history actually holds.
Read / Write Which direction of I/O to measure.

Read and write latency are different measurements and often tell different stories. A write cache that is full, or a synchronous replica acknowledging slowly, shows up in writes and leaves reads untouched. Check both before concluding a volume is healthy.

Likewise, look at each drive separately. A single volume behind everything else is a very different problem from all of them degrading together – the first is one disk or one LUN, the second is the array, the HBA, or the host.

The toolbar

Button What it does
Show More Adds a week to the range.
Show Less Removes a week.

One to six weeks in one-week steps; the buttons hide at the ends.

The range is shared with the other by-hour-by-day reports. That sharing earns its keep here: reading this map against I/O by Hour by Day over the same window is how you tell slow because busy from slow for no reason, and those have completely different owners.

Requirements

A historic report reading the DiskLatency table in the DBHealthHistory repository, populated by the collection service. Without collection configured there is nothing to draw.

It reads history rather than the live instance, so it works when the monitored server is unavailable.

The figures are what SQL Server observed, which is latency as the database engine experienced it – including any queuing on the host. That is usually what you want, but it means a discrepancy with the array’s own statistics is not necessarily a contradiction.

How to read the report

  1. Pick one drive and one direction. Mixing them hides the finding.
  2. Look for cells at the slow end of the ramp, then check whether they cluster.
  3. Put it beside I/O by Hour by Day for the busy database. Slow and busy is contention; slow and quiet is the storage itself, and that is the more serious of the two.
  4. Check writes as well as reads. They fail differently.
  5. Compare drives. One bad volume and all volumes bad are different problems.
  6. Widen the range to separate a bad afternoon from a degrading trend.

Common patterns

Slow cells exactly matching heavy I/O hours. The volume is saturated at peak. Capacity or scheduling, not a fault.

Slow cells when I/O was light. The storage itself, or something else on shared storage. This is the case that needs the storage team, and the pairing with the I/O map is what proves it.

Writes slow, reads normal. Write cache, or a synchronous replica acknowledging slowly.

One drive out of several behaving badly. A single disk, LUN or path. Much easier to act on than a general slowdown.

A slow band at the same hour nightly. Backups, or another host’s workload on shared storage.

Gradually more slow cells week over week. Degrading storage or growing load. Widen the range – the trend is the finding, not any one cell.

Unusually fast cells. Often the absence of the workload that normally runs then. Worth confirming the job still runs.

Report Why you would go there
I/O by Hour by Day The comparison that separates busy from broken.
I/O by Drive Current I/O per volume.
Disk Space Whether the volume is also short of room.
Disk Space Forecast When it runs out.
Waits Whether I/O waits dominate the instance.

Frequently asked questions

Why is this scale different from the other heat maps? Because latency has no meaningful zero or maximum – what matters is deviation from that volume’s own typical behaviour. Eight milliseconds is fine on one array and alarming on another.

What does the middle colour mean? A typical hour for that drive. The ends of the ramp are the interesting cells, in both directions.

Why do I have to pick read or write? They are different measurements and often disagree. A write-side problem is invisible in the read figures.

Is this the array’s latency or SQL Server’s? What SQL Server observed, including host queuing. That is usually the number that matters, but it can differ from the array’s own statistics.

What does a blank cell mean? Nothing was recorded – a collection gap. It is drawn differently from a typical hour, because on a diverging scale “ordinary” is a colour with a meaning.

Why does the range change on the other heat maps? One shared setting, so this map and the I/O map always cover the same window.