SQL Server Error 1101

Error number

1101

Severity

17 (resource or software problem)

State

1

Product

Microsoft SQL Server Database Engine

Versions

All supported SQL Server versions (2016 to 2025), Azure SQL Managed Instance

Category

Log & Storage Space

Last reviewed

24 October 2026

What it means

Error 1101 means SQL Server needed a new page in a filegroup whose data files are all full and cannot grow, so the statement that needed it failed.

Like error 1105, error 1101 is about the data files of one filegroup: none of them has a free page left, and none can grow because autogrowth is off, MAXSIZE has been reached, or the volume is full. The statement fails at severity 17 (insufficient resources) and is rolled back; nothing is damaged. The message names the database and the filegroup, which tells you which files to look at.

The difference from 1105 is what the message names. 1105 names the table or index whose rows did not fit. 1101 names no object: in our tests on SQL Server 2025 it came from statements that needed fresh pages for something new, such as SELECT ... INTO a new table, building an index, or the first rows of a new table, after ordinary inserts had already filled the file. Both have the same fixes, and both often appear together in the same incident, so treat them as one problem: make room in the filegroup.

Common causes

• The data file has autogrowth disabled or has reached its MAXSIZE, so the filegroup is full even though the disk may have space.
• The volume holding the data files is full, so autogrowth cannot extend them.
• An index create or rebuild, or a SELECT INTO, needs room for a complete new copy of the data on top of what is already there.
• The objects live in a secondary filegroup that is much smaller than PRIMARY, or a new table was created on a filegroup that is already full.

Diagnose it

Read-only These queries only read metadata and dynamic management views. They do not change data, permissions or configuration, so they are safe to run first.

SELECT fg.name AS filegroup_name, f.name AS logical_name, f.physical_name,
       f.size / 128.0 AS size_mb,
       CAST(FILEPROPERTY(f.name, 'SpaceUsed') AS int) / 128.0 AS used_mb,
       CASE f.max_size WHEN -1 THEN 'unlimited' WHEN 0 THEN 'no growth' ELSE CAST(f.max_size / 128 AS varchar(20)) + ' MB' END AS max_size,
       CASE WHEN f.growth = 0 THEN 'off' WHEN f.is_percent_growth = 1 THEN CAST(f.growth AS varchar(10)) + ' %' ELSE CAST(f.growth / 128 AS varchar(10)) + ' MB' END AS autogrowth
FROM sys.database_files AS f
JOIN sys.filegroups AS fg ON fg.data_space_id = f.data_space_id
ORDER BY fg.name, f.file_id;

SELECT DISTINCT vs.volume_mount_point,
       vs.total_bytes / 1048576 AS total_mb,
       vs.available_bytes / 1048576 AS free_mb
FROM sys.database_files AS f
CROSS APPLY sys.dm_os_volume_stats(DB_ID(), f.file_id) AS vs
WHERE f.type_desc = 'ROWS';

SELECT TOP (10) ds.name AS filegroup_name,
       OBJECT_SCHEMA_NAME(p.object_id) AS schema_name,
       OBJECT_NAME(p.object_id) AS object_name,
       SUM(au.total_pages) / 128.0 AS reserved_mb
FROM sys.allocation_units AS au
JOIN sys.partitions AS p ON au.container_id = CASE WHEN au.type = 2 THEN p.partition_id ELSE p.hobt_id END
JOIN sys.data_spaces AS ds ON ds.data_space_id = au.data_space_id
GROUP BY ds.name, p.object_id
ORDER BY reserved_mb DESC;

How to fix it

Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.

ALTER DATABASE AppDb
MODIFY FILE (NAME = N'AppDb', FILEGROWTH = 256MB, MAXSIZE = 100GB);

ALTER DATABASE AppDb
ADD FILE (NAME = N'AppDb_2', FILENAME = N'E:\SqlData\AppDb_2.ndf', SIZE = 4GB, FILEGROWTH = 256MB)
TO FILEGROUP [PRIMARY];

CREATE INDEX IX_Orders_CustomerId
ON dbo.Orders (CustomerId)
ON [ARCHIVE];

-- After agreement with the data owner and a verified backup
DROP TABLE dbo.Orders_Staging_2024;

Examples

SELECT INTO a new table when the filegroup is full

A throwaway database with an 8 MB data file, MAXSIZE 8 MB and no autogrowth. The loop fills the file with wide rows until error 1105 stops it (caught and printed); the copy then needs new pages.

-- Setup (throwaway database): data file SIZE = 8MB, MAXSIZE = 8MB, FILEGROWTH = 0
CREATE TABLE dbo.Orders (id INT IDENTITY, pad CHAR(4000) NOT NULL DEFAULT 'x');
BEGIN TRY
    WHILE 1 = 1 INSERT dbo.Orders DEFAULT VALUES;   -- fill the data file
END TRY
BEGIN CATCH
    PRINT 'File full: error ' + CAST(ERROR_NUMBER() AS varchar(10));   -- 1105
END CATCH;

SELECT * INTO dbo.Orders_Copy FROM dbo.Orders;

Msg 1101, Level 17, State 1, Line 10
Could not allocate a new page for database 'AppDb' because the 'PRIMARY' filegroup is full due to lack of storage space or database files reaching the maximum allowed size. Note that UNLIMITED files are still limited to 16TB. Create the necessary space by dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

Building a clustered index on a full filegroup

Same throwaway setup. Building the clustered index writes a new, sorted copy of the table, so it needs about as much free space as the table already uses.

CREATE TABLE dbo.Orders (id INT IDENTITY, pad CHAR(4000) NOT NULL DEFAULT 'x');
BEGIN TRY
    WHILE 1 = 1 INSERT dbo.Orders DEFAULT VALUES;   -- fill the data file
END TRY
BEGIN CATCH
    PRINT 'File full: error ' + CAST(ERROR_NUMBER() AS varchar(10));   -- 1105
END CATCH;

CREATE CLUSTERED INDEX CX_Orders ON dbo.Orders (id);

Msg 1101, Level 17, State 1, Line 9
Could not allocate a new page for database 'AppDb' because the 'PRIMARY' filegroup is full due to lack of storage space or database files reaching the maximum allowed size. Note that UNLIMITED files are still limited to 16TB. Create the necessary space by dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.
The statement has been terminated.

How to prevent it

Alert on used space per filegroup and free space per volume, not only on disk space: a capped file fills up while the disk still looks healthy. Before an index rebuild, a large SELECT INTO or a bulk load, check that the target filegroup has free space at least the size of the data being written.

Set MAXSIZE on purpose and review it with the capacity plan, and keep autogrowth increments fixed and reasonable. The transaction log is a separate file with its own limit; when it fills, the error is 9002.

Common questions

Learn more on CodeWithSQL

• Working with large databases
• SQL indexes

Official documentation

• MSSQLSERVER_1101 (Microsoft Learn)
• ALTER DATABASE file and filegroup options
• Database files and filegroups

Last technically reviewed 24 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.