File Utilization Report

Overview

The File Utilization report shows every database file on the instance, drawn as a card per file and grouped by the volume the files sit on.

That grouping is the useful part. A file that is 90% full matters differently depending on whether the volume under it has a terabyte spare or eight gigabytes, and grouping by volume puts those facts next to each other.

Each card carries the used against free split, and the thresholds that decide whether a file is worth attention live in the drawing code rather than in a CASE expression in configuration – so the colours and the judgement stay together.

Where to find it

An instance-level report. Right-click the server → Instance Level Reports → File Utilization.

The help button opens https://databasehealth.com/server-overview/instance-level-reports/file-utilization-report/.

The File Utilization report
The whole report. Cards are grouped under the volume each file lives on.
One card per database file, grouped by volume
Within a volume group, the used and free split on each card is directly comparable.

Reading the report

Cards are grouped under the volume each file lives on. Within a group, the used/free split on each card is directly comparable.

The grid below carries the same files with the exact figures.

The file utilization grid
One row per database file, with its used and free space and the volume it lives on.

Shrinking a file

Incremental shrink is on the right-click menu, on both the cards and the grid.

It is incremental rather than one operation because a full shrink of a large file is long, holds locks, and fragments every index it moves. Steps let you stop.

Free space in a file is not waste. It is room the database will grow back into, and autogrowth events are expensive – especially without instant file initialization. This report shows you the free space so you can decide; it does not imply you should reclaim it.

The case for shrinking is usually that the space is never coming back – after an archive, a purge, or a migration – not that a file looks empty.

The All Instances version

There is an all-instances version of this report that stacks rows from every connected instance into one grid.

That version has no cards. Cards are per-file within a volume, and a grid mixing twelve instances cannot express that grouping, so the all-instances case falls back to the plain grid deliberately rather than drawing something misleading.

How to read the report

  1. Look at the volume groups, not just individual files. A nearly-full file on a nearly-full volume is urgent; the same file on an empty volume is not.
  2. Check the log files separately. A log that has grown large and is mostly free is usually a backup problem, not a space problem – see Backup Status.
  3. Look for one file far larger than its siblings. Proportional fill is not working, often because files were added later or have different growth settings.
  4. Before shrinking, ask whether the space is coming back.
  5. Cross-check Disk Space for whether the volume has room for the growth you are about to allow.

Common patterns

A log file mostly free after a long-delayed log backup. The space was needed; it is not needed now. Whether to shrink depends on whether the delay will recur.

One data file much larger than the others in the same filegroup. Added at a different time, or a different growth setting. Proportional fill will keep the imbalance.

Every file on one volume nearly full. A volume problem rather than a file problem. Disk Space is the page.

A file with a tiny autogrowth increment on a large database. Frequent small growth events, each one a pause. Worth fixing regardless of free space.

Report Why you would go there
Disk Space Whether the volume has room.
Files The same information for one database, with latency alongside.
I/O by Drive Whether that volume is also slow.
Backup Status Why a log file grew.
Disk Space Forecast When the volume runs out.

Frequently asked questions

Should I shrink a file that is mostly free? Usually not. Free space is room to grow into, and shrinking fragments indexes. Shrink when the space is genuinely not coming back.

Why is shrink incremental? Because a full shrink of a large file is long, holds locks, and fragments what it moves.

Why does the All Instances version look different? It has no cards. A grid stacking rows from twelve instances cannot express per-volume grouping, so it falls back to a plain grid rather than drawing something that would mislead.

Why is my log file so large? Usually because log backups were not running, or a long transaction prevented reuse. Check Backup Status.