Part of the DBA-Tools Project.
A SQL Server running out of room fails in several different ways depending on exactly which resource ran out: a full data file stops inserts, a full log file freezes the whole database, a full disk volume takes down everything on it, and a database quietly approaching a configured file size limit gives no warning at all until it hits the wall. Ten scripts on this site cover the full picture, from disk volumes down to individual filegroups, from a point-in-time snapshot to a real growth-rate forecast.
This post is the map. It groups them by the question they answer, and lays out a sensible order for a routine capacity review rather than checking each in isolation.
Why Storage and Capacity Matters
- Different resources fail differently: a full data file errors individual inserts, a full log file freezes every write in that database, a full disk volume can take down every database hosted on it
- Free space at the volume, database, and filegroup level are three different questions, a comfortable database-level total can hide a nearly-full filegroup, and a comfortable disk can still have a database configured with a tight max file size
- A snapshot tells you where things stand right now, a trend tells you when a real problem is coming, both matter and neither replaces the other
- Autogrowth is a safety mechanism, not a capacity strategy, frequent growth events during business hours cost latency even when they succeed
The Scripts, Grouped by What They Answer
Is there room right now, at the volume level?
- Disk Space, free and used space per OS volume hosting database files, queried through T-SQL alone, no RDP access needed
Is there room right now, at the database and file level?
- Database Free Space Summary, allocated, used, and free space per database, split into data and log, ordered by tightest free space first
- Database Sizes and Free Space, the same data and log split, ordered biggest database first, an inventory view rather than a triage view
- Filegroup Space, the same question one level deeper, since autogrow acts per file within a filegroup, not at the database level
- Database Files Detail, per-file path, size, max size, and growth settings, the configuration behind every number the other scripts report
Is it trending toward a problem?
- Database Growth Risk and Forecast, which databases are near their configured file size limit right now, plus a real projected date from historical growth rate once the collector has history
- Autogrowth History, every recorded autogrowth event from the default trace, the raw evidence behind a growth trend
Is the transaction log specifically the problem?
- Log Reuse Waits, the single most direct answer to “why won’t this log shrink,” reads
log_reuse_wait_descacross every database - Transaction Log Size and Usage, log size, used space, and percent used per database
- VLF Counts, virtual log file count per database, the internal fragmentation that repeated small autogrowth events leave behind
How They Fit Together
A sensible order for a routine capacity review:
- Start at the volume level with Disk Space, the broadest check and the one that needs no database-level setup at all
- Drop to the database level with Database Free Space Summary (or Database Sizes and Free Space for an inventory-first view) to see which specific databases are tight
- Go one level deeper with Filegroup Space when a database-level number looks comfortable but autogrow is still failing, or when the database uses more than one filegroup
- Check the configuration behind the numbers with Database Files Detail, growth settings and max size explain why a file behaves the way it does
- Check the trend, not just the snapshot with Database Growth Risk and Forecast and Autogrowth History, a comfortable number today can still be on a fast trajectory
- If the log specifically is the problem, start with Log Reuse Waits to find the actual blocking reason before reaching for Transaction Log Size and Usage or VLF Counts
Best Practices Across the Series
- Check free space at all three levels (volume, database, filegroup) before concluding a database is safe, each can hide a problem the others don’t show
- Treat
UNLIMITEDgrowth settings as “check the disk,” not as “no risk,” the real ceiling is still the volume underneath - Set up growth-rate collection early, even before a capacity conversation comes up, so a real forecast is available when someone asks “when will we run out”
- Fix a log that won’t reuse space at the actual cause (
Log Reuse Waits) before shrinking it, a one-off shrink without fixing the cause just grows back
See Also
This pillar is one of ten in DBA Scripts: The Complete Guide, the map across the whole series organized by the question you’re actually asking.
Summary
Running out of room is never really one problem, it’s several different questions depending on which resource and which level you’re looking at: the disk, the database, the filegroup, and whether the trend is getting worse. These ten scripts answer each of those separately, because a full disk, a full log, and a database quietly approaching a configured limit all need a different response.
Start at the volume level if you haven’t run a capacity review recently, then follow the chain down into whichever level turns up a real finding.
Leave a Reply