master File Map

Overview

Every file of every database on this instance, including the databases nobody can open.

This is the one page in the product that can describe a database that is offline, restoring, recovery pending or suspect, because sys.master_files is the only place those files are still listed. Everything else reads sys.database_files, which needs the database to be open.

The master File Map page: every file of every database, grouped by volume
The whole page in the By volume view. Fifty one files from twenty one databases, 47.14GB claimed across four drives, and the grid carrying the growth setting and the ceiling for each file.

Where to find it

Expand a server in the tree, expand the master database, then Master → File Map.

The findings are in the settings, not the sizes

Finding Why it matters
Growth in percent Compounds, and takes longer at every step.
Growth left at the old one megabyte default Why a file grows four hundred times in an afternoon.
A ceiling the volume cannot hold A MAXSIZE larger than the drive is a promise that cannot be kept.
A log file on the same volume as its data One volume failure takes both.

The space pages elsewhere in the product answer how full a drive is, which is a different question, and this page links to them rather than repeating them.

Two decodes that catch everybody

size and max_size are counts of eight kilobyte pages

Not bytes. A size of 1280 is 10 MB.

max_size carries three values that are words rather than numbers

Value What it means
-1 Unlimited.
0 No growth at all.
268435456 The two terabyte ceiling the engine puts on a log file whether or not anybody asked for one.

The two views

View What it groups by
By volume One group per drive, which is the view for “what is on this disk”.
By database One group per database, which is the view for “where does this database live”.

Reading the chart

The bars: one per volume, showing what the files on it have claimed
One bar per volume, with what the files on it have claimed on the right. E: is holding forty five files from nineteen databases here.

In the By volume view there is one bar per drive, holding what the files on it have claimed. By database gives one bar per database instead, which is the view for where a single database lives.

The line under the header is where the findings are: growth in percent, a growth increment under eight megabytes, and the databases keeping data and log on one volume.

Reading the grid

The grid: every file, its growth setting and its ceiling
Grows by and Up to are the columns to read. A percentage or a one megabyte increment is called out in color, and the three special ceiling values are spelled out in words.
Column What it is
Database The database the file belongs to, whether or not it can be opened.
File The logical file name.
Kind Rows, log, filestream or full text.
Size Converted from pages.
Grows by The growth increment, in megabytes or as a percentage. Percent and 1 MB are both called out.
Up to The ceiling, with the three special values spelled out in words.
Volume The drive letter or mount point.
Path The full physical path.
State Online, offline, restoring, recovery pending, suspect, or emergency.

The toolbar

Control What it does
By volume / By database The two views.
Database properties Opens master Database Properties.
master’s own files Narrows to master, which is what master Footprint covers in detail.

Where the data comes from

sys.master_files, joined to sys.databases for the state, with the volume derived from the physical path. No database has to be open for any of it.

Report Why you would go there
Disk Space How full each of these volumes actually is.
Files for a Database One database’s files with their free space, which needs the database open.
master Footprint master’s own files, in detail.
master Database Properties The other settings these databases differ on.
File Size Over Time How these files got to this size.

Frequently asked questions

A database is offline and its files are listed. Is that right? Yes, and it is the point of the page. sys.master_files keeps the file rows whether or not the database can be opened.

Growth is set to 10 percent. Is that bad? It compounds: every growth is larger than the last, so each one takes longer, and the file grows in bursts that lengthen over time. A fixed increment sized for the database is the usual advice.

Up to says 2,097,152 MB on my log and I did not set that. That is the engine’s two terabyte ceiling for a log file, stored as max_size 268435456. Nobody set it; it is there whether or not anybody asked.

Size looks wrong. size is a page count. Multiply by 8 KB. The page does that for you, which is why it can disagree with a raw query somebody wrote themselves.