What’s the issue?
User database files (data and log) should be placed on storage that supports the performance, availability, and capacity needs of the workload. SQL Server best practices recommend placing data and log files on dedicated drives separate from the operating system drive, allowing files to grow as needed, and separating log files from data files onto different physical volumes when possible.
This finding flags one or more of three related conditions: user database files placed on the C drive when other drives are present on the server, user database files configured with MAXSIZE set to a value other than UNLIMITED (preventing growth beyond the cap), and user database log and data files located on the same drive when separate volumes exist.
Each condition represents a deviation from accepted storage best practices and is typically the result of default settings being accepted during database creation rather than a deliberate design choice.
Why is this a problem?
Files on the C drive consume space on the operating system volume, which is sized for Windows and SQL Server binaries rather than user data. If the C drive fills up, Windows itself can become unstable, paging fails, and the SQL Server service may stop or refuse to start, causing an outage that affects every database on the instance. Backups and other administrative operations also compete for the same drive, increasing contention and recovery risk.
Files configured with a maximum size limit will stop growing when they hit the cap, even when free space remains on the underlying drive. The result is a query failure or transaction abort that surfaces to the application, often during routine activity that should have completed normally. The cap is sometimes set as a safety measure, but proper drive sizing and monitoring achieve the goal more reliably without creating an artificial failure point.
Log and data files on the same drive eliminate the I/O performance benefits of separating sequential log writes from random data file activity. They also create a single point of failure: if the drive is lost, both the database and its transaction log are lost simultaneously, which can prevent recovery to the most recent committed transaction even when backups exist.
Together, these conditions reduce performance, increase the risk of outages, and complicate disaster recovery in ways that are easy to avoid with proper file placement during database creation.
What should you do about this?
Identify affected files by querying sys.master_files and reviewing the physical_name, max_size, and database file type columns. Cross reference against the drive layout of the server to determine which files are on C, which have a maximum size cap, and which databases have log and data files on the same volume.
For files on the C drive, plan a relocation to the appropriate dedicated drives during a maintenance window. The standard process is to take the database offline, move the file at the operating system level, update the path with ALTER DATABASE [DatabaseName] MODIFY FILE (NAME = N’LogicalFileName’, FILENAME = N’
For files with a maximum size cap, change the setting to UNLIMITED with ALTER DATABASE [DatabaseName] MODIFY FILE (NAME = N’LogicalFileName’, MAXSIZE = UNLIMITED);. The change takes effect immediately. Pair this with proper drive sizing and monitoring so growth is supported but not unbounded in practice.
For databases with log and data on the same drive, plan to relocate the log file to a separate volume using the same offline and move procedure described above. If only one drive is available beyond C, prioritize separating log from data over any other split, since that separation provides the most operational benefit.