Files
Overview
The Files report shows one card per database file, each carrying two splits:
- Read latency against write latency – how the storage is answering.
- Used against free – how much of the file is actually holding data.
Having both on one page is the point. Previously this report could tell you a file was slow but not whether it was also mostly empty, which meant a second trip to the File Utilization report before you could decide anything.
What this fixes
The old version was a HorizontalBars chart of file size over a grid of raw stall counters. For a single database that chart was two or three bars whose lengths the grid already spelled out, and it said nothing about the thing the query was sorted by. The space columns are new.
Where to find it
A database-level report. Select a database, then open Files.
Reading the grid
| Column | What it is |
|---|---|
| Type | Data or log. |
| File | Logical file name. |
| Size | Allocated size. |
| Used | How much holds data. |
| Free | How much does not. |
| % Free | The same as a proportion, drawn with a bar. |
| Reads | Read operations. |
| Avg Read Stall (ms) | Average read latency. |
| Writes | Write operations. |
| Avg Write Stall (ms) | Average write latency. |
| Total IO | Reads plus writes. |
| Total Stall (ms) | All time waited on this file. |
Latency here is judged on the same scale as the I/O reports – log files at 5 / 10 / 25 ms, data files at 10 / 20 / 50 – so a file that reads amber here reads amber there.
Shrinking a file
Incremental shrink is on the right-click menu, on both the cards and the grid.
Shrink is offered incrementally rather than as one operation because a full shrink of a large file is long, holds locks, and fragments every index it moves. Doing it in steps lets you stop.
Before shrinking anything, consider that free space in a file is not waste – it is room the database will grow back into, and growth events are expensive. The report shows you the free space so you can decide; it does not imply you should reclaim it.
How to read the report
- Look at the latency split first. A file slow on writes and fine on reads points somewhere different from one slow on both.
- Then the used/free split. A file that is mostly free and also slow may simply be badly placed.
- Compare data and log files separately. They are judged on different thresholds because log writes are synchronous.
- Check Total Stall, not just averages. A file with modest latency and enormous volume can be the biggest contributor.
Common patterns
The log file slow on writes, data files fine. Log writes are synchronous – every commit waits on one. Check where the log lives.
A data file mostly free after a large delete. Expected. Whether to shrink is a judgement about future growth, not an automatic yes.
Several data files with very different used percentages. Proportional fill is not working as expected – often because the files were added at different times or have different growth settings.
Related reports
| Report | Why you would go there |
|---|---|
| I/O by Database | The instance-wide view of the same counters. |
| I/O by Drive | Whether the volume is the problem rather than the file. |
| File Utilization | Growth and free space across all databases. |
| Disk Space | Whether the volume has room for growth. |
Frequently asked questions
Should I shrink a file with a lot of free space? Usually not. That space is room to grow into, and shrinking fragments indexes. Shrink when the space is genuinely never coming back – after archiving, say.
Why is shrink offered incrementally? Because a full shrink of a large file is long, holds locks, and fragments what it moves. Steps let you stop.
Why do log and data files use different latency thresholds? Because log writes are synchronous and serialised – every commit waits on one. The same number means something worse on a log file.