Fix ERROR_DATABASE_FULL 0X000010DA on SQL Server

Quick answer

Run DBCC SHRINKFILE on the transaction log, then set AUTO_GROWTH on the data file to handle future peaks.

What this error means

You got ERROR_DATABASE_FULL (0X000010DA) because your database hit its max size limit. This often happens during a big import, a long-running transaction, or when the transaction log file filled up and can't grow anymore. You'll see it in SQL Server error logs or your app's crash report. The core issue: either the data file (.mdf) or the log file (.ldf) reached its configured max size, or the disk itself is full. I've seen this most with SQL Server 2019 and 2022 when someone forgets to set auto-growth on the log file after a backup job change.

Fix steps

Step 1: Check what's full

1. Open SQL Server Management Studio (SSMS) and connect to the server.
2. Right-click the database — go to Tasks > Shrink > Files.
3. In the File type dropdown, pick Log first. Click OK.
4. After it finishes, check the error again by running your app or query.

What you'll see: If the log file was the culprit, the shrink frees space and the error disappears. The progress bar in SSMS shows percentage done.

Step 2: Shrink the data file if still full

1. Repeat Step 1 but pick Data in the File type.
2. In the Shrink action, choose Reorganize pages and set the max free space to 10 percent.
3. Click OK.

What you'll see: If the data file had empty space, the size shrinks. If it stays the same size, you need to expand the file instead.

Step 3: Expand the database file

1. Right-click the database — go to Properties > Files.
2. For the Data row, increase the Initial Size (MB) by 1024 MB (1 GB).
3. Set Auto-growth to By 512 MB and Max File Size to Unlimited.
4. Do the same for the Log row.
5. Click OK.

What you'll see: The database size increases immediately. Your app should work now. If the disk is full, you'll get a different error — skip to the prevention tip.

Step 4: Run a T-SQL command for full control

If SSMS is slow, run this in a query window. Replace YourDatabaseName with your actual name.

-- Check current file sizes
USE YourDatabaseName;
GO
SELECT name, size/128.0 AS SizeMB, max_size FROM sys.database_files;
GO

-- Shrink log file
DBCC SHRINKFILE (YourDatabaseName_log, 100);
GO

-- Set auto-growth to 512 MB with no max
ALTER DATABASE YourDatabaseName
MODIFY FILE (NAME = YourDatabaseName, SIZE = 2048 MB, FILEGROWTH = 512 MB, MAXSIZE = UNLIMITED);
GO

What you'll see: The query returns current sizes before the shrink. After the ALTER, the database can grow automatically.

Alternative fixes if the main one fails

• Check disk space: Open File Explorer on the SQL Server machine. If the drive where the database files sit (usually C: or D:) has less than 1 GB free, you can't expand. Delete temp files or move the database to another drive.
• Truncate the log file manually: If the log file is huge and won't shrink, back up the log first, then run DBCC SHRINKFILE (YourDatabaseName_log, 0, TRUNCATEONLY).
• Recover space from deleted data: Run DBCC SHRINKDATABASE (YourDatabaseName, 10) to reorganize pages across all files at once. This can take a while on big databases.
• Switch to simple recovery model: Only do this if you don't need point-in-time recovery. Right-click database > Properties > Options > Recovery model > Simple. Then shrink the log. Your log file stays small until you switch back.

Prevention tip

Set up a SQL Server Agent job that checks free space daily. Use this query to alert you when a database hits 80% of its max size:

SELECT name, 
       size/128.0 AS CurrentSizeMB, 
       max_size/128.0 AS MaxSizeMB, 
       (size/128.0)/(max_size/128.0)*100 AS PercentFull
FROM sys.database_files
WHERE max_size > 0;

If PercentFull is above 80, expand the file during a maintenance window. Also make sure your transaction log backups run often — every 15 minutes during high-traffic hours. That keeps the log file from ballooning. I've saved my own skin with a 15-minute log backup schedule during Black Friday sales.