Error 1105

Severity Level 17

Message Text

Can't allocate space for object '%.*s' in database '%.*s' because the '%.*s' segment is full. If you ran out of space in Syslogs, dump the transaction log. Otherwise, use ALTER DATABASE or sp_extendsegment to increase the size of the segment.

Explanation

This error occurs when SQL Server is unable to allocate space for a database. The object ID of the object identified in the message text indicates what type of space could not be allocated:

If the object ID is not 8, data space could not be allocated.
If the object ID is 8, log space could not be allocated.

These errors are written to the error log only when they occur during the checkpoint process. When a user process encounters this error, the message is returned to the client application without being written to the error log.

Action

Use one of the following procedures to correct the error, depending on whether the error occurred during run time or recovery.

Run-time 1105 errors

The specific action you take on a run-time 1105 error depends on the object ID.

Object ID ¹ 8 In this case, the message indicates that the data segment is full on the database indicated in the message. To obtain more data space, do one or more of the following:

Use alter database to increase the size of the data segment.
Drop objects from the database.
Delete rows from tables in the database.

Object ID = 8 In this case, the message indicates that the log segment is full on the database indicated in the message. To clear space in the log, follow these steps:

Determine how many rows are in the syslogs table, as follows:
```
use database_name
go
select count(*) from syslogs
go
```
Dump the inactive portion of the transaction log using the dump transaction statement. If this statement fails with the 1105 error, retry the statement using the with no_log option.
Repeat step 1. If the number of rows in syslogs has decreased significantly, proceed to step 4. If not, an outstanding transaction is probably preventing the log from being cleared. If this is the case, restart SQL Server and repeat step 2.
When SQL Server starts and the database is recovered, the outstanding transaction is rolled back, allowing the log to be cleared by a subsequent dump transaction statement. For information about managing the transaction log, see Chapter 4, "Transaction Log Management."
If the dump transaction statement was executed using either the no_log option or the truncate_only option in step 2, dump the database now, because these options prevent subsequent changes recorded in the log from being used to recover from a media failure. You must run dump database to ensure the recoverability of subsequent database modifications.
Note The database dump is not required if your environment does not save transaction logs for media failure recovery.
Do not assume that the occurence of error 1105 means that your transaction log is too small. If the data and the log are on the same segment, the actions described above can often free enough space without requiring you to increase the size of the transaction log.
If you are concerned that your transaction log is too small, read Chapter 4, "Transaction Log Management," before increasing the transaction log size. For information about using the alter database statement to increase log size, see the Microsoft SQL Server Transact-SQL Reference.

Recovery 1105 errors

The specific action you take on a recovery 1105 error depends on which type of database it occurs on.

On a user database If error 1105 occurs on a user database during recovery, correct the problem using the following procedure:

Use the sp_dboption system procedure to note the current user options on the database (so you can reset them in step 7).
Manually set the database status to no chkpt on recovery (status bit 16) and single user (status bit 4096) by adding the two status bits together and then using the | (OR) operator, as follows:
```
sp_configure 'allow updates', 1
go
reconfigure with override
go
begin tran
go
update master..sysdatabases
set status = status | 4112
where name = 'database_name'
go
```
Caution Because the database was marked suspect on the original recovery attempt, this procedure also resets some internal status bits to allow the database to recover normally. Do not use this procedure under any other circumstances.
The value of 4112 in the SET STATUS statement corresponds to the single user and no chkpt on recovery database options.
Check that the SET STATUS statement affected only one row.
If more than one row was affected, issue a rollback transaction statement. Otherwise, commit the transaction and shut down SQL Server:
```
commit tran
go
shutdown
go
```
Restart SQL Server.

After you restart SQL Server, dump the transaction log with the no_log option and reset the database status:

dump tran database_name with no_log
go
sp_dboption database_name, 'no chkpt', false
go
sp_dboption database_name, single, false
go
use database_name
go
checkpoint
go
sp_configure 'allow updates', 0
go
reconfigure with override
go

Use sp_dboption to reestablish any database options such as select into/bulkcopy noted in step 1.

On the master database If error 1105 occurs on the master database during recovery but SQL Server still starts, correct the problem by logging in and dumping the transaction log using the NO_LOG option, as shown in the following example:

dump tran master with no_log

If error 1105 occurs on the master database and prevents SQL Server from starting, contact your primary support provider.

On the model database If error 1105 occurs on the model database during recovery, SQL Server will not start. This is because the tempdb database, which is required to start the server, could not be built due to the problem with the model database. To correct this problem and restart SQL Server, use the following procedure:

Start SQL Server with the 3608 trace flag. This trace flag causes SQL Server to recover only the master database at startup. For details about using trace flags, see "Using Trace Flags," in Chapter 24, "Additional Problem-solving Techniques."
Execute the following statements to set the no chkpt on recovery option on the model database:
```
sp_dboption model, 'no chkpt', true
go
use model
go
checkpoint
go
```
Restart SQL Server.
Execute the following statement to truncate the inactive portion of the transaction log in model:
```
dump tran model with no_log
go
```

Reset the database option on model:

sp_dboption model, 'no chkpt', false
go
use model
go
checkpoint
go