Error 2558



Message text

Versions earlier than 15.0:

Extent not within segment: Object %ld, indid %d includes extents on allocation page %ld which is not in segment %d.

Version 15.0 and later:

Extent not within segment: Object %ld, indid %d, partition %ld includes extents on allocation page %ld which is not in segment %d


A segment is a label used to point to one or more database devices. Segments map the future allocations of different types of data to different devices.

Error 2558 occurs when dbcc checkalloc, dbcc tablealloc, or dbcc indexalloc discovers that a portion of a database resides on a segment which was not defined to contain that type of data. For example, if dbcc checkalloc discovers user data on a segment designated to hold transaction log data, error 2558 will occur.

NoteError 2558 is only raised when the 2513 trace flag is turned on.

When a database gets this error, it still functions. However, 1105 errors may occur as a side effect of the 2558 error.

In addition, if you have log on your data segment, and you lose the data device for some reason, you cannot get a good transaction dump with no_truncate. This means you cannot get up-to-the-minute recovery.

Sybase recommends that you do not turn on trace flag 2513 unless you have been getting 1105 errors or have recently run sp_logdevice, sp_placeobject, or alter database commands. When trace flag 2513 is on, dbcc checkalloc, dbcc tablealloc, and dbcc indexalloc commands take significantly longer to run and a lot of additional output may be created.

To turn on trace flag 2513, use these commands:


1> dbcc traceon (2513)
2> go

Version 15.0.2 and later:

1> set switch on 2513 with override 
2> go

To turn off trace flag 2513, use these commands:


1> dbcc traceoff (2513)
2> go

Version 15.0.2 and later

1> set switch off 2513 
2> go

Creating segments

By default, when Adaptive Server creates a database, it creates the following three segments:

For example, this command creates the default, system and log segments for the database example:

1> create database example 
2> on device_1 = 10
3> log on device_2 = 2
4> go

The system and default segments are mapped to device_1 and the log segment is mapped to device_2. For the example database, all future space allocations for system or user objects will occur on device_1 and all transaction log records will be placed on device_2. Other databases may use other portions of device_1 or device_2 and these devices may have different segment mappings for that database.

A 2558 error would result in the example database if system or user objects were located on device_2 or transaction log records on device_1.

Causes of error 2558

Following is a summary of how and when error 2558 is raised. For details, refer to the sections listed in the “See...” column in the following table.

Causes of error 2558


Loading into a database that has different data and log mapping than the dumped database.

“Different data and log mapping”

When you use sp_placeobject, the old allocation area is still in usea.

sp_placeobject” in Reference Manual: Procedures

When you use sp_dropsegment, existing objects are still mapped to the dropped segment.

sp_dropsegment” in Reference Manual: Procedures

a. Error 2558 is only raised in this case when trace flag 2513 is turned “on.”

Different data and log mapping

If this error occurred after you re-created and loaded a database from a dump, there were probably incorrect or different entries in the master..sysusages table. A database loaded from a dump must be created in exactly the same way as the database that was dumped. If it is not, different entries in master..sysusages can cause 2558 errors.

This can cause a “data on log” situation, where data, such as user or system objects, is loaded into a log segment. This means that less total log space is available to the database. The data is still accessible, but processing may be slowed, if not totally stopped, by the shortage of log space.

There can also be a “log on data” situation, where portions of the transaction log are loaded into a data segment. This is not as serious as the “data on log” scenario. This is because the portion of the transaction log on the data segment is eventually truncated using the dump transaction command, freeing up the space. All future transaction log allocations will be correctly placed on the log segment.

Suppose the example database were altered as follows:

1> alter database example on device_1 = 2
2> go

The logical order of the database pages is:

A 2558 error could result if the database were dumped, then dropped and re-created with different segment mappings. For example:

1> create database example on device_1 = 12
2> log on device_2 = 2
3> go

Although both ways of creating the database (create and alter, or just create) allocate the same amount of data and log space on the same devices, the mapping of data and log space is not the same. The first 12MB are allocated differently: in the first (create and alter) database, 10MB of data are followed by 2MB of log; in the second (create), the first 12MB are data. Dumping the first database and loading it to the second would cause 2MB of log to be mapped onto a data segment, yielding 2558 errors.

WARNING! If you load databases in this manner, you can get mapping that you do not expect and that can cause problems. Do not load databases in this manner! If you suspect that such a problem might have occurred, use sp_helpdb to check the mapping of your database.

All space allocations that occur on Database 2 after the load completes are correctly mapped.


If you use sp_placeobject to assign an object to a new segment, existing pages will still reside on the old segment.

If you have trace flag 2513 turned “on,” dbcc checkalloc, dbcc tablealloc, and dbcc indexalloc will display error 2558 after you use sp_placeobject.


If you have trace flag 2513 turned “on,” dbcc checkalloc, dbcc tablealloc, and dbcc indexalloc will display error 2558 if you use sp_dropsegment to remove a segment for which existing objects are still mapped.



You only need to resolve 2558 errors if the object taking up space on the wrong segment creates a problem for you.

If you received the error because of an sp_dropsegment, you may be able to resolve it using sp_addsegment or sp_extendsegment.

If there are a substantial number of 2558 errors due to an incorrect load database, you can drop and correctly re-create the database, then reload it.

Use this section if you have 2558 errors and cannot re-create the database from scripts or hard copy.

2558 errors occur on these types of pages:

The action needed to correct this error depends on the type of page on which the error occurred.

Use the following table to match up the object ID value (“Object” in the error message) and index ID (“indid” from the error message) with the corresponding data page type, then go to that section for the appropriate action. All action sections follow the table.

Type of data

Corresponding object ID and index ID values

“Data pages or clustered index pages”

Object ID > 99, index ID = 0 or 1

“Nonclustered index pages”

Object ID > 99, 1 < index ID < 255

“text or image data pages”

Object ID > 99, index ID = 255

“System table pages”

Object ID < 100 (and not equal to 8)

“Transaction log pages”

Object ID = 8

An object ID value of 100 will not occur.

Data pages or clustered index pages

(Object ID > 99 and Index ID = 0 or 1)

The error occurred on the data page or on the clustered index of a user table. Resolve the problem with either one of the following procedures:

Nonclustered index pages

(Object ID > 99 and 1 < Index ID < 255)

The error occurred on the nonclustered index of a user table. The error can be cleared by dropping and re-creating the index. Creating a clustered index causes all nonclustered indexes to be rebuilt as well. Therefore, if 2558 errors are occurring on several indexes on the same table, you can create a clustered index on that table to clear all these errors.

text or image data pages

(Object ID > 99 and index ID = 255)

The error occurred on data which is text or image datatype. Use either procedure below to correct the situation:

  1. Select all the information from the old table into a new table.

  2. Drop the old table. Any subsequent dbcc checkalloc, dbcc tablealloc, or dbcc indexalloc command will continue to show this error until the old table is dropped.

  3. Use sp_rename to rename the new table with the old table name.


Copy the table out, using bcp or select/into. Then drop and re-create the table, and copy the contents of the table back in, using bcp or select/into.

System table pages

(Object ID < 100 and not 8)

Call Sybase Technical Support.

Transaction log pages

(Object ID = 8)

If the error occurs on pages containing transaction logs, do the following:

  1. Have all users finish transactions and wait until this procedure is finished to initiate any further transactions.

  2. Perform the checkpoint command:

    1> use <database_name> 
    2> go
    1> checkpoint
    2> go
  3. Dump the transaction log according to your normal procedures.

  4. Notify users that they may resume normal operations.

Additional information

Refer to “Creating and Using Segments” in the System Administration Guide: Volune 2 for information about segments and devices.

Refer to the Reference Manual: Commands for information about checkpoint and dump transaction.

Versions in which this error is raised

All versions