USE <dbname>; GO SELECT file_id, name FROM sys.database_files; GO DBCC SHRINKFILE (<fileid>, TRUNCATEONLY);
You can check autogrow settings here:
SELECT name, type_desc, size, growth, is_percent_growth FROM [database_name].sys.database_files;
Ideally you will create the database with sufficient size to avoid autogrowth at all, since this operation can be expensive (especially if you don’t have instant file initialization) and can block all other activity for the duration of the growth event. You may want to manually expand the file now or during a maintenance window to avoid this happening during peak activity. So proactively you can do this (e.g. to change the auto growth setting to 100 MB):
ALTER DATABASE [database_name] MODIFY FILE (NAME = N'database_name_data', FILEGROWTH = 102400KB);
If your drive has 16 MB of free space, then you need to free up some space somehow, or move the database to a drive that has more space. It’s possible that the drive has been taken up by an overgrown log file, probably because you’re in full recovery model and have never taken a log backup. In this case you can either:
Switch to simple recovery mode, run CHECKPOINT, and then DBCC SHRINKFILE to make the log a reasonable size. Resist the temptation to shrink the file to 1 MB; you don’t want to get into a tug-of-war with your disk space.
Stay in full, then BACKUP LOG, and then DBCC SHRINKFILE with the same caveats as (1).
Now, it could also be that you’re in simple mode and the log has ballooned to support some atypically large transaction. So you may still be able to do (1) without any worry, but if you’re going to be running these large transactions again, or not doing (1) or (2) regularly, then you’re only “solving” the problem temporarily. Get a bigger disk or use full recovery model and manage your log much more effectively.