Error 2558

Severity

16

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

Explanation

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.

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:

Pre-15.0.2:

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:

Pre-15.0.2:

1> dbcc traceoff (2513)
2> go

Version 15.0.2 and later

1> set switch off 2513 
2> go

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

• system segment – allows system catalog tables to be placed on devices that contain this segment for a particular database.

• default segment – allows user tables or indexes to be placed on devices that contain this segment without specifying the on clause (for example, create table test (i int) on segment_1) for a particular database.

• log segment – allows the transaction log to be placed on devices that contain this segment for a particular database.

  A device can contain more than one type of segment, although a segment can contain only one type of data (user data, transaction log data, and so on). Thus, different data can be on the same device, but not on the same segment.

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.

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.

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:

• The first 10MB of pages are data (default and system segments)

• The next 2MB are log

• The last 2MB are data

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.

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.

Prevention

• Consider using the on segment_name option with create table rather than using sp_placeobject to assign an object to a segment.

• Do not drop segments when objects are still mapped to them.

• Keep an up-to-date copy of the master..sysusages system table as well as scripts to re-create all databases. Use the scripts to ensure that the entries in the master..sysusages table for the database being loaded match the corresponding entries for the database that was dumped. More specifically, the segmap, lstart, and size columns of sysusages must be identical in content and order. Verify this before beginning the load database command.

• The entries in sysusages will be correct on the database if you execute the following commands with the same parameters and in the same order as they were on the dumped database:

  • create database

  • alter database

  • sp_addsegment

  • sp_dropsegment

  • sp_extendsegment

  • sp_logdevice

    You cannot depend on the output of the system procedure sp_helpdb to compare the contents of the sysusages table, because it does not necessarily display rows from sysusages in the actual logical page order. Instead, do direct selects against the sysusages table.

Action

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:

• Data pages or clustered index pages

• Nonclustered index pages

• text or image data pages

• System tables

• Transaction log 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.

An object ID value of 100 will not occur.

(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:

• Create a clustered index on the table, if you have the available space needed. If a clustered index already exists, drop and re-create it. If not, creating one will clear the error. You can then drop the clustered index.

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

(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.

(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.

or:

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.

(Object ID < 100 and not 8)

Call Sybase Technical Support.

(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