File Size Over Time

Overview

Files shows what a database’s files look like now. File Size Over Time shows how they got there.

One chart per file, stacked down the page, each drawing the file’s size over the window you pick. Nothing else. That is enough to answer the three questions people actually have about file growth.

  • Is this growing, or did it grow once? A slope and a step look nothing alike.
  • Is the log the problem, or the data? The log has its own chart.
  • When did it start? The date the line changed direction is the date something changed.

This is a historic report. It draws recorded sizes, so it can only go back as far as the monitoring has been running.

File Size Over Time
One chart per file. The shape is the answer.

Where to find it

A database level report. Expand the database → HistoricFile Size Over Time.

The page title reads Historic File Size for <database name>.


Requirements

  • A historic database configured for this instance, holding the recorded file sizes.
  • The collection job running. The charts show what was collected. A period where nothing was collected is a period with no points, not a period where the file did not change.

Without any recorded history for the chosen window, the page says No file size history found for this period rather than drawing empty charts.


The two dropdowns

Dropdown Choices Default
Time Frame Last Week, Last Month, Last Year, All Time Last Week
Granularity By Day, By Month By Day

Granularity is what each point represents, and each point is the largest size seen in that period. Taking the maximum rather than the average is deliberate: a file that grew on the 3rd and was shrunk back on the 4th did grow, and an average would hide it.

Choosing By Month switches the time frame to Last Year with it, because monthly points across a week would be one point.

All Time removes the window entirely and draws everything on record.


Reading the charts

One chart per file, titled with the file’s physical path, with the Y axis in MB.

The physical path is the title rather than the logical name on purpose. A logical name of Data1 tells you nothing about where the growth is landing; E:\SQLData\AppDB_Data1.mdf tells you which volume is filling.

Hovering a point gives the size and the date.

Charts appear for every file in the database’s recorded history, so a file that was removed during the window still gets a chart with its history up to the point it stopped being recorded.


How to read the report

  1. Look at the shapes before the numbers. A straight climb, a staircase and a flat line with one step are three different problems.
  2. Read the log file chart separately from the data files. A log that grows and never comes back is a recovery model or a log backup problem, not a data volume problem.
  3. Find where the slope changed. That date is the question. What Changed and Structure Change Log cover the same date from the other side.
  4. Widen to All Time before concluding anything is unusual. A month is not enough to tell growth from a cycle.
  5. Take the slope to Disk Space Forecast. This page says the file is growing; that page says when the volume runs out.

Common patterns

A staircase. Autogrowth doing its job, one event per step. Each step is a pause for whoever was running the statement that triggered it. Growing the file deliberately during a window is cheaper than growing it under load.

A steep climb that flattens. A data load or an index rebuild. The file kept the space, because SQL Server does not give it back on its own.

A log file that climbs and never comes down. The log is not being truncated. In FULL recovery that means log backups are not running, or an open transaction, or something else holding the log. VLFs, Backup Status and Open Transactions are the three places to look, in that order.

A sawtooth on a data file. Something is shrinking the file on a schedule. That is worth stopping: every shrink is followed by a regrow, and the pair fragments the file and burns IO for no benefit.

A flat line with one step, months ago. A one-off. The file is correctly sized for the data and nothing needs doing.

A gap in every chart at once. The collection job was not running. It is a hole in the record, not a period without growth.


Where the data comes from

  • [DBHealthHistory].[dbo].[databaseFileHistory] for the file, its logical name and its physical path.
  • [DBHealthHistory].[dbo].[databaseFileSizeHistory] for the recorded sizes.

Points are grouped to the day or the month and reduced with a maximum, which is why a growth followed by a shrink inside one interval still shows the growth.

This page writes nothing.


Report Why you would go there
Files What each file looks like right now, with used and free space and latency.
File Utilization The same for every file on the instance, grouped by volume.
Disk Space Forecast When the volume this file lives on runs out.
VLFs The internal cost of a log file that has grown in many small steps.
Table Space Breakdown What inside the database is taking the space the file is growing for.
Databases by Size Which database on the instance accounts for the growth.

Frequently asked questions

The page says no file size history was found. Either the historic database is not collecting for this instance, or there is no data in the window you chose. Widen the time frame to All Time before concluding it is not collecting.

Why is the chart titled with a file path rather than the file name? Because the path says which volume the growth is landing on, which is usually the reason you are looking.

Why does a point show a size larger than the file is now? Because each point is the largest size recorded in that interval. A file that was grown and then shrunk inside one day shows the grown size.

Why does choosing By Month change my time frame? Because monthly points only make sense over a long window, so the time frame moves to Last Year with it.

Does this show free space inside the file? No. It shows the file’s size. Files and File Utilization show how much of that size is actually used.

Why is there a chart for a file that no longer exists? Because it existed during the window and its history is still recorded. Its line stops where the collection stopped seeing it.