The data file (.mdf/.ndf) has a MAXSIZE cap set and has reached it — even though the disk still has free space, SQL Server will not grow the file past this limit.. The disk volume hosting the data file is physically full. Other databases, tempdb, backups, or OS files have consumed all available space.. Autogrowth is disabled (FILEGROWTH = 0) or set to a tiny increment like 1 MB, causing growth to fail or not keep up with write volume during a large ETL load.. A runaway process — an audit trigger logging every row, a staging table that never gets truncated, or a failed MERGE that duplicates data — filled the file unexpectedly between scheduled maintenance windows.. Transaction log (.ldf) growth consumed the remaining disk space first, leaving no room for the data file to grow. This is common when the recovery model is FULL and log backups are not scheduled.

Step 1: Check current file sizes, used space, and max size to understand which file is full: SELECT name, type_desc, size * 8 / 1024 AS size_mb, FILEPROPERTY(name, 'SpaceUsed') * 8 / 1024 AS used_mb, CASE max_size WHEN -1 THEN 'UNLIMITED' ELSE CAST(max_size * 8 / 1024 AS VARCHAR) END AS max_size_mb, growth FROM sys.database_files;. Step 2: Check available disk space on the volume: EXEC xp_fixeddrives; — or on Linux: SELECT available_bytes / 1024 / 1024 AS free_mb FROM sys.dm_os_volume_stats(DB_ID(), 1);. Step 3: If the file has a MAXSIZE cap but the disk has space, raise or remove the limit: ALTER DATABASE [yourdb] MODIFY FILE (NAME = yourdb_data, MAXSIZE = UNLIMITED); — or set a specific cap like MAXSIZE = 100GB if you want a safety limit.. Step 4: If the disk is full, free space immediately. Delete old backup files, shrink the transaction log after a log backup (BACKUP LOG [yourdb] TO DISK = '/backups/yourdb_log.trn'; DBCC SHRINKFILE(yourdb_log, 1024);), or move tempdb to another volume.. Step 5: Set a proper autogrowth increment so the file can keep up with load: ALTER DATABASE [yourdb] MODIFY FILE (NAME = yourdb_data, FILEGROWTH = 512MB); — avoid percentage-based growth on large databases (10% of 500 GB = 50 GB growth event that can freeze I/O for minutes).. Step 6: Reclaim wasted space inside the data file by rebuilding fragmented indexes: ALTER INDEX ALL ON [schema].[table] REBUILD WITH (ONLINE = ON); — then optionally shrink: DBCC SHRINKFILE(yourdb_data, target_size_mb); but only as a one-time fix, not a scheduled task.. Step 7: Add a secondary data file on a different volume if the primary disk cannot be expanded: ALTER DATABASE [yourdb] ADD FILE (NAME = yourdb_data2, FILENAME = 'E:\Data\yourdb_data2.ndf', SIZE = 10GB, FILEGROWTH = 1GB);

Critical severityresource

SQL Server Error:
1105, Database Full

What does this error mean?

Error 1105 fires when the SQL Server database engine tries to allocate a new 8 KB data page but cannot — the data file (.mdf or .ndf) has hit its MAXSIZE limit, the underlying disk is full, or both. Every INSERT, UPDATE, SELECT INTO, and index rebuild that needs a new page fails immediately with this error. In a data-pipeline context this is particularly disruptive: ADF Copy Activities and Stored Procedure activities abort mid-batch, Power BI dataflows that write staging tables fail on refresh, and SSIS packages roll back their current data flow task. The error is not transient — retries will keep failing until you either free space in the database or expand the data file. You will typically see it first as a cascade of pipeline failures rather than a single query error.

Common causes

1The data file (.mdf/.ndf) has a MAXSIZE cap set and has reached it — even though the disk still has free space, SQL Server will not grow the file past this limit.
2The disk volume hosting the data file is physically full. Other databases, tempdb, backups, or OS files have consumed all available space.
3Autogrowth is disabled (FILEGROWTH = 0) or set to a tiny increment like 1 MB, causing growth to fail or not keep up with write volume during a large ETL load.
4A runaway process — an audit trigger logging every row, a staging table that never gets truncated, or a failed MERGE that duplicates data — filled the file unexpectedly between scheduled maintenance windows.
5Transaction log (.ldf) growth consumed the remaining disk space first, leaving no room for the data file to grow. This is common when the recovery model is FULL and log backups are not scheduled.

How to fix it

1Step 1: Check current file sizes, used space, and max size to understand which file is full: SELECT name, type_desc, size * 8 / 1024 AS size_mb, FILEPROPERTY(name, 'SpaceUsed') * 8 / 1024 AS used_mb, CASE max_size WHEN -1 THEN 'UNLIMITED' ELSE CAST(max_size * 8 / 1024 AS VARCHAR) END AS max_size_mb, growth FROM sys.database_files;
2Step 2: Check available disk space on the volume: EXEC xp_fixeddrives; — or on Linux: SELECT available_bytes / 1024 / 1024 AS free_mb FROM sys.dm_os_volume_stats(DB_ID(), 1);
3Step 3: If the file has a MAXSIZE cap but the disk has space, raise or remove the limit: ALTER DATABASE [yourdb] MODIFY FILE (NAME = yourdb_data, MAXSIZE = UNLIMITED); — or set a specific cap like MAXSIZE = 100GB if you want a safety limit.
4Step 4: If the disk is full, free space immediately. Delete old backup files, shrink the transaction log after a log backup (BACKUP LOG [yourdb] TO DISK = '/backups/yourdb_log.trn'; DBCC SHRINKFILE(yourdb_log, 1024);), or move tempdb to another volume.
5Step 5: Set a proper autogrowth increment so the file can keep up with load: ALTER DATABASE [yourdb] MODIFY FILE (NAME = yourdb_data, FILEGROWTH = 512MB); — avoid percentage-based growth on large databases (10% of 500 GB = 50 GB growth event that can freeze I/O for minutes).
6Step 6: Reclaim wasted space inside the data file by rebuilding fragmented indexes: ALTER INDEX ALL ON [schema].[table] REBUILD WITH (ONLINE = ON); — then optionally shrink: DBCC SHRINKFILE(yourdb_data, target_size_mb); but only as a one-time fix, not a scheduled task.
7Step 7: Add a secondary data file on a different volume if the primary disk cannot be expanded: ALTER DATABASE [yourdb] ADD FILE (NAME = yourdb_data2, FILENAME = 'E:\Data\yourdb_data2.ndf', SIZE = 10GB, FILEGROWTH = 1GB);

Example log output

ErrorCode=UserErrorDatabaseOperationFailed,Type=SqlException,Message=Could not allocate space for object 'dbo.fact_sales_load'.'PK_fact_sales_load' in database 'DW_Prod' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.,SqlErrorNumber=1105
Activity 'Copy_to_DW' failed after 0 retry attempt(s). Start time: 2026-05-11T02:15:43Z, End time: 2026-05-11T02:17:12Z, Duration: 89 seconds.

Frequently asked questions

How do I enable autogrowth for a SQL Server data file?

ALTER DATABASE [yourdb] MODIFY FILE (NAME = yourdb_data, FILEGROWTH = 512MB); — set a meaningful growth increment (not the default 1MB or 1%) to avoid frequent growth events.

How do I reclaim space from a SQL Server database?

First rebuild indexes (ALTER INDEX ALL ON table REBUILD), then check if empty space can be released: DBCC SHRINKFILE (yourdb_data, target_size_mb); — but avoid frequent shrinks as they cause fragmentation.

Does Azure SQL Database have error 1105?

Yes — Azure SQL has storage limits per service tier. If the database reaches the tier limit, error 1105 appears. Scale up the service tier or use auto-scale (Hyperscale tier) to avoid it.

Source · learn.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-1105-database-engine-error