This section contains error messages for dbcc (database consistency checker) commands.
Messages that ordinarily have severities greater than 16 will show severity 16 when they are raised by dbcc checktable and dbcc checkalloc so that checks will continue with the next object.
16
Table named %.*s not found; check sysobjects.
This error occurs when a dbcc command is run if Adaptive Server is unable to find the table name (or ID) in sysobjects.
Error 2501 can occur when running any of the following dbcc commands:
dbcc checktable
dbcc checkdb
dbcc tablealloc
dbcc reindex
dbcc fix_text
This error can be serious as it indicates possible corruption.
If this error occurs on a command for which you have specified a table name, check to make sure you have spelled the table name correctly:
1> select * from sysobjects 2> go
If this error occurs because the entry for an object has been removed from sysobjects but the object is still referenced by some other system tables, call Sybase Technical Support. They will help you try to remove the references to that object from the other system tables.
Before calling Technical Support, have the following information available:
Adaptive Server version and SWR version level
Adaptive Server error log
Output of dbcc checkalloc and dbcc checkdb
Text of all error messages
All versions
16
Table Corrupt: A page is linked in more than one chain; check this page:page number=%ld allocation status=%d
This error may be caused by a hardware problem.
This error occurs when Adaptive Server detects an inconsistency in the page chains associated with an object. For example, a page may be connected in more than one chain. If this error is detected by a dbcc command, a 605 error may also occur.
WARNING! If Error 605 occurs with this error, use the instructions presented under Error 605 or call Technical Support.
This is a serious error that must be corrected immediately.
Note the page number in the error message. Use the procedure in “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter to determine which table is associated with the corrupt page chain.
If the object with the error is not a system table (a system table's object ID is less than 100), continue with step 3.
If the object with the error is a system table and the index ID is not 0, refer to “How to Fix a Corrupted Index on System Tables” in the Encyclopedia of Tasks chapter for instructions on how to repair the system table index.
If the index ID is 0, contact Sybase Technical Support. They may be able to help you repair the corruption, but it may be necessary to restore from clean backups.
If the object with the error is not a system table, follow one of the procedures below to correct the problem, depending on what kind of object is involved:
If the page belongs to an index, drop and re-create the index.
If the page does not belong to an index, recover your database from a known clean backup or recover the tables not affected by this error via bcp. Refer to “How to Rescue Data from a Corrupted Table” in the Encyclopedia of Tasks chapter for details.
Examine your operating system error log and the Adaptive Server error log to determine if hardware errors may have caused the corruption.
Before calling Technical Support, have the following information available:
Adaptive Server version and SWR version level
Server error log
Text of all error messages
Output of dbcc page
All versions
16
Table Corrupt: Page linkage is not consistent; check the following pages: (current page#=%ld; page# pointing to this page=%ld; previous page# indicated in this page=%ld)
This error may be caused by a hardware problem.
This error occurs when Adaptive Server detects an inconsistency in the page linkage of one of the page chains associated with a table. There is one doubly linked page chain for the table's data as well as one for each index level. For example, a page's “next” pointer points to a page whose “previous” pointer points to a different page.
This is a serious error that must be corrected immediately.
Note the first page number in the error message. Use the procedure in “How to Find an Object Name from a Page Number”in the Encyclopedia of Tasks chapter to identify which object is associated with the “current page”.
If the object with the error is not a system table (a system table's object ID is less than 100), continue with step 3.
If the object with the error is a system table and the index ID is not 0, refer to “How to Fix a Corrupted Index on System Tables”in the Encyclopedia of Tasks chapter for instructions on how to repair the system table index.
If the index ID is 0, contact Sybase Technical Support. They may be able to help you repair the corruption, but it may be necessary to restore from clean backups.
If the object is not a system table, perform one of the actions below, depending upon what kind of object was involved in the error.
If the “current page” belongs to a nonclustered index (index ID is between 2 and 250), run dbcc checktable to verify that the data page linkage is good. If checktable runs cleanly, drop and re-create the index.
If the “current page” belongs to a clustered index (index ID is 1), drop all the indexes on that table, re-create the clustered index first, and then re-create the remaining nonclustered indexes.
If the “current page” does not belong to an index at all (index ID is 0 or 255) and there were no errors other than the 2503 error, perform the following steps:
Use bcp or select into to retrieve your data from the affected table. Refer to “How to Rescue Data from a Corrupted Table”in the Encyclopedia of Tasks chapter for instructions.
If errors still exist, restore from clean backups or call Sybase Technical Support.
Examine your operating system error log and the Adaptive Server error log to determine if hardware errors may have caused the corruption.
For information on locating device fragments, refer to “How to Determine Which Physical Devices a Database is On” in the Encyclopedia of Tasks chapter.
All versions
16
Table Corrupt: The values in adjust table should be in ascending order starting from the end of the table (page#=%ld row#=%d); check adjust table in this row
This error may be caused by a hardware problem.
An adjust table is stored at the end of every data or index row which has variable length columns. It is used to improve performance of Adaptive Server for rows with lengths greater than 256 bytes.
Error 2506 occurs when dbcc checkdb or dbcc checktable detects inconsistencies in the values stored in the adjust table of the row specified by the error message.
This error can occur on a data page or an index page.
If you have clean backups of your database, recovery from backups may be your best option. If you do not have clean backups of your database, refer to “How to Identify and Fix a Corrupted Table” in the Encyclopedia of Tasks chapter to correct the error.
WARNING! Some data on this page might be lost if you recover your table using bcp or select into (that is, the corrupted row and rows following it might be truncated and contain the wrong keys). Compare the two tables (old and new) row by row (by joining them on a primary key, for example) to determine which rows are different (corrupted).
Before dumping your database, make sure it is working correctly. More specifically, the following commands should be run prior to each dump:
dbcc checkdb.
dbcc checkalloc or dbcc checkalloc with the fix option. (Refer to “How to Fix and Prevent Allocation Errors”in the Encyclopedia of Tasks chapter for information about running these commands in multi-user mode and how to prevent spurious allocation errors from dbcc commands.)
Hardware errors on your database devices can cause Error 2506. To help rule out this possibility, do the following:
Check the Adaptive Server error log to determine whether there are other indications of hardware problems, such as kernel messages reporting I/O errors.
Check the hardware error log or diagnostics utilities for I/O errors. Refer to “Checking the Operating System Error Log” in the Encyclopedia of Tasks chapter.
If problems persist, refer to the error documentation in this manual or contact Sybase Technical Support.
Refer to bcp in the Adaptive Server utility programs manual.
Refer to “select” in the Reference Manual for information about the select into command.
Have the following information available before calling Sybase Technical Support:
Adaptive Server version and SWR version level
Adaptive Server error log
Operating system error log
Output of dbcc checkdb and dbcc checkalloc
All versions
16
Table Corrupt: Offset table is incorrect (page#=%ld row#=%d offset in offset table is=%d correct offset is=%d)
This error may be caused by a hardware problem.
An offset table is stored at the end of every data page and indicates where rows are located on that page. Adaptive Server uses the offset table to quickly access the rows in each page.
Error 2507 occurs when dbcc checkdb or dbcc checktable detects inconsistencies in the offset table of a row on the page specified by the error message.
Refer to “How to Identify and Fix a Corrupted Table”in the Encyclopedia of Tasks chapter to correct the error.
WARNING! Some data on this page might be lost if you recover your table using bcp or select into (that is, the corrupted row and rows following it might be truncated and contain the wrong keys). Compare the two tables (old and new) row by row (by joining them on a primary key, for example) to determine which rows are different (corrupted).
Before dumping your database, make sure it is working correctly. More specifically, the following commands should be run prior to each dump:
dbcc checkdb.
dbcc checkalloc or dbcc checkalloc with the fix option. (Refer to “How to Fix and Prevent Allocation Errors”in the Encyclopedia of Tasks chapter for information about running these commands in multi-user mode and how to prevent spurious allocation errors from dbcc commands.)
In addition to the above possible causes, hardware errors on your database devices can cause Error 2507. To rule out this possibility, do the following:
Check the Adaptive Server error log to determine whether there are other indications of hardware problems, such as kernel messages reporting I/O errors.
Check the hardware error log or diagnostics utilities for I/O errors.
If problems persist, refer to the error documentation in this manual or contact Sybase Technical Support.
Refer to bcp in the Adaptive Server utility programs manual.
Refer to “select” in the Reference Manual for information about the select into command.
Have the following information available before calling Sybase Technical Support.
Adaptive Server version and SWR version level
Adaptive Server error log
Operating system error log
Text of all error messages
Output from dbcc checkdb, dbcc checktable, and dbcc checkalloc
All versions
16
Table Corrupt: The row number and offset of each row in the page should have a matching entry in row number table; check this page (page#=%d row#=%d offset in row number table=%d)
This error may be caused by a hardware problem.
The offsets for data or index rows are stored at the end of every page (in the row number table) and indicate where a certain row is located on that page.
Error 2509 occurs when the dbcc checkdb or dbcc checktable command detects that a row does not have an entry matching its offset (location) on the page in the row offset table.
Attempts to delete the offending row will result in Error 631, while attempts to select the offending row may be successful.
This problem is probably a result of a problem within Adaptive Server but may also be caused by one of the following:
Hardware failure.
Sybase System Administration problems.
UNIX System Administration problems.
First, make sure that you ruled out any of the above-mentioned causes of this error by referring to the appropriate sections in Chapter 2, “Encyclopedia of Tasks”.
After you eliminated other more serious errors on this table, follow these steps to correct the 2509 error:
Follow the instructions in “How to Find an Object Name from a Page Number”in the Encyclopedia of Tasks chapter to identify which table and index correspond to the page number from the error message text.
If the object with the error is not a system table (object ID is more than 100), continue with step 3.
If the object with the error is a system table and the index ID is not 0, refer to “How to Fix a Corrupted Index on System Tables”in the Encyclopedia of Tasks chapter for instructions on how to repair the system table index.
If the index ID is 0, contact Sybase Technical Support. They may be able to help you repair the corruption or it may be necessary to restore from clean backups.
If the object with the error is a user table, use one of the following three methods to clear the 2509 error:
Create a clustered index on the corrupted table. Creating a clustered index will copy the whole table onto new data pages, and will overwrite the row number table on each page. If a clustered index already exists on the table identified in step 1, drop the clustered index and re-create it.
WARNING! If you have other serious errors on this table (Errors 614, 2506, 2507, or 2524), eliminate these errors first, before you create a clustered index. Refer to the documentation in this manual for how to eliminate other errors on this table.
Select the whole table into a new table, and drop the old table.
Bulk copy the affected table out, drop and re-create the table, and bulk copy back in.
WARNING! Some data on this page might be lost if you recover your table using bcp or select into (that is, the corrupted row and rows following it might be truncated and contain the wrong keys). Compare the two tables (old and new) row by row (by joining them on a primary key, for example) to determine which rows are different (corrupted).
For more information about how to copy a table in a new table or file, refer to “How to Rescue Data from a Corrupted Table” in the Encyclopedia of Tasks chapter.
Refer to create index and select in the Reference Manual and in the Transact-SQL User's Guide.
Refer to bcp in the Adaptive Server utility programs manual.
All versions
16
Key mismatch between index page %ld, at offset %d and data page %ld (row ID %d) in database ’%.*s’. Drop and re-create index id %d of table ’%.*s’.
This error may be caused by a hardware problem.
This message indicates that an index is inconsistent with the table data that it represents.
Use the following procedure to recover from this error:
Record the index page number and the data page number from the error text. Refer to “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter to identify which table and index correspond to the data and index page number. Record the object ID and index ID.
If the object with the error is not a system table (its object ID is 100 or greater), go to step 3.
If the object with the error is a system table, refer to “How to Fix a Corrupted Index on System Tables” in the Encyclopedia of Tasks chapter for instructions on how to repair the system table index.
If the object with the error is a user table, find the name of the index involved by executing the following query:
1> select name from sysindexes 2> where indid = index_id 3> and id = object_id 4> go
Drop and re-create the index. (Refer to the Adaptive Server Reference Manual for information about the drop index and create index commands.)
Run dbcc checktable and dbcc tablealloc on the affected table to verify that all problems have been corrected at the table level.
If problems persist, refer to the error documentation in this manual or contact Sybase Technical Support. Have the output from the appropriate dbcc commands available when you call.
All versions
16
Keys of index id %d for table ’%.*s’ in %S_MSG not in correct order. Drop and re-create the index. (index page %d)
This error may be caused by a hardware problem.
This error occurs when an index is not ordered correctly.
There are three possible values of ”%S_MSG” from the error message text:
Data page (only on clustered indexes)
Index page
Leaf page
Note the index ID and table name displayed in the error message output.
If the object with the error is not a system table (object ID is more than 100), continue with step 3.
If the object with the error is a system table, refer to “How to Fix a Corrupted Index on System Tables” in the Encyclopedia of Tasks chapter for instructions on how to repair the system table index.
If the object with the error is a user table, find the name of the index involved by executing the following query:
1> select name from sysindexes 2> where indid = index_ID 3> and id = object_ID 4> go
Drop and re-create the index. To verify that all problems have been resolved at the table level, run the dbcc checktable and dbcc tablealloc commands on the affected table.
If problems persist, refer to the error documentation in this manual or contact Sybase Technical Support. Have the output from the appropriate dbcc commands available for their review.
All versions
16
Table Corrupt: Object id %ld (object name = %S_OBJID) does not match between %.*s and %.*s
This error occurs when dbcc checkcatalog finds that an object exists in one system table but not in another system table where Adaptive Server expected to find it. This is a serious error as it indicates corruption.
Error 2513 occurs with the following states:
State |
Meaning |
|---|---|
1 |
The object was found in syscolumns but not in either sysobjects or systypes. |
2 |
The object (a view) was found in sysobjects but not in syscolumns. |
3 |
The object (a view) was found in sysobjects but not in syscomments. |
4 |
The object (a view) was found in sysobjects but not in sysprocedures. |
5 |
The object (a stored procedure) was found in sysobjects but not in syscomments. |
6 |
The object (a stored procedure) was found in sysobjects but not in sysprocedures. |
7 |
The object (a rule or default) was found in sysobjects but not in syscomments. |
8 |
The object (a rule or default) was found in sysobjects but not in sysprocedures. |
9 |
The object (a table) was found in sysobjects but not in syscolumns. |
10 |
The object (a table) was found in sysobjects but not in sysindexes. |
11 |
The object (a table) was found in sysindexes but not in sysobjects. |
Call Sybase Technical Support when this error occurs. They may be able to help you delete the object that is causing the error. However, because other objects may reference that object, deleting it cleanly may be difficult. If this is the case, recovering from backups may be a better choice.
All versions
16
Table Corrupt: Type id %ld (type name = %.*s) does not match between %.*s and %.*s
syscolumns contains a row for every column in a table, and systypes contains a row for every type in a table. Error 2514 occurs when dbcc checkcatalog detects a type mismatch between the systypes and the syscolumns system tables.
Error 2514 is most often caused by a select into across databases when at least one column from the original table is a user-defined datatype. It can also be caused by cross-database views and applications that map data across databases when a user-defined datatype involved in the operation has conflicting definitions in the two databases.
The 2514 error often prints out a usertype value that seems out of place: 0 or a large number. If your 2514 error does not match this description, call Technical Support for further assistance.
Use the following procedure to find the incorrect entry in syscolumns and replace it with the correct value. Note that “c” and “t” are actually typed in; they are not variables. This method allows Adaptive Server to compare all tables to search for the mismatch.
Identify the rows containing incorrect entries:
1> select c.name, c.usertype, c.type 2> from syscolumns c 3> where not exists 4> (select * from systypes t 5> where t.usertype = c.usertype) 6> go
name usertype type ------------------- --------- ------- PartNumber 0 56
More than one row may be returned.
Search for the correct value for each incorrect syscolumns usertype by querying the systypes usertype column, using the value reported in type. Do this for each row reported in step 1 above:
1> select t.name, t.usertype, t.type 2> from systypes t 3> where t.type in ( 56 ) 4> and t.usertype < 100
Results of the query should resemble the following:
name usertype type --------------- ------------ --------- int 7 56
The value returned under usertype is the correct value which should appear in the usertype column of syscolumns, 7 in this example.
Change the incorrect row value in the systypes column usertype with the correct value you obtained in step 2:
Enable updates to system tables (substitute your site's values for “7,” “0,” “56” and “PartNumber” in this query):
1> sp_configure "allow updates", 1 2> go
1> begin transaction 2> update syscolumns set usertype = 7 3> where usertype = 0 and type = 56 4> and name = "PartNumber" 5> go
To commit the transaction, type:
1> commit transaction 2> go
Repeat the steps above for any other incorrect rows, substituting the required values for usertype, type, and name in the query.
When you have updated all the incorrect rows, disable updates to system tables:
1> sp_configure "allow updates", 0 2> go
1> checkpoint 2> go
Run dbcc checkcatalog again to verify that the problem is corrected.
All versions
16
Table Corrupt: Procedure id %ld (procedure name = %S_OBJID) does not match between %.*s and %.*s
This error occurs when dbcc checkcatalog finds that an entry for a compiled object (for example, a stored procedure or trigger) exists in the table sysprocedures and that entry does not exist in the sysobjects table.
If the error occurred on an object in sysprocedures in master, enable updates to system tables:
1> use master 2> go
1> sp_configure "allow updates", 1 2> go
Determine how many rows contain the object entry:
1> use database_name 2> go
1> select * from sysprocedures 2> where id = procedure_ID 3> go
where database_name is the name of the database that contains the table with the object and procedure_ID is the ID of the procedure in the 2517 error.
If you need to recover the stored procedure, get the text of the stored procedure:
1> sp_helptext stored_proc_name 2> go
Remove the object entry from sysprocedures:
1> begin transaction 2> delete sysprocedures 3> where id = object_ID 4> go
where object_ID is the ID of the procedure in the 2517 error.
Check the results carefully, and commit the transaction only if the update affected the expected number of rows. If it affected more than the expected number of rows, roll back the transaction. To commit the transaction, type:
1> commit transaction 2> go
Disable updates to system tables:
1> sp_configure "allow updates", 0 2> go
1> checkpoint 2> go
Run dbcc checkcatalog again to verify that the problem is corrected. If the object entry still exists in other tables, you may get other error messages (such as Error 2513). If you do get other error messages, follow the directions in this manual for handling those errors.
If you wanted the object that has been deleted, re-create it using the information obtained in step 3.
All versions
16
Database named %.*s not found; check sysdatabases
This error occurs when Adaptive Server is unable to find the database you specify when running dbcc checkcatalog, dbcc checkdb, or dbcc dbrepair.
Some reasons for this error are:
You have mistyped the name of a database or the database you specified does not exist.
Corrupt indexes exist on sysdatabases.
Determine whether the database you are specifying exists:
1> sp_helpdb 2> go
Search the output to determine whether you have misspelled the database name or whether the dbid for the database you specified exists but the name has been removed or changed.
If the database you are specifying exists and you are getting a 2520 error, run dbcc checkdb on the master database to find out whether it is corrupt. If dbcc checkdb returns error messages, corruption has occurred. Whether or not you believe corruption has occurred, call Sybase Technical Support. You may be able to rebuild the indexes for master or you may have to restore master from a backup.
Before calling Technical Support, have the following information available:
Adaptive Server version and SWR version level
Output of dbcc checkdb
Text of all error messages
All versions
16
Table Corrupt: Page is linked but not allocated. Run DBCC TABLEALLOC to correct the problem. (alloc page#=%ld, extent id=%ld, logical page#=%ld, object id in extent=%ld, index id in extent=%ld, object name=%S_OBJID)
This error may be caused by a hardware problem.
This error is serious, especially if it occurs on a table's data pages. It means that a page is currently in use by a table or index but it has not been marked as allocated. The same page could be allocated again, resulting in a loss of whatever data resides on the page.
Pages encountering the 2521 error will not be included in a database dump. This is because database dumps are performed by reading allocation pages and not by traversing page chains. Therefore, this error should be corrected before dumping the database.
The instructions below are for fixing 2521 errors once
they have occurred. Two easy-to-use strategies exist for detecting
this error sooner in the future. Refer to “Detecting Allocation Errors as Early as Possible” in the Encyclopedia of Tasks
chapter for information about these strategies.
Occasionally dbcc checkalloc reports this error when no real error condition exists. You can either check to see if these errors are real, or continue with this section and take action to correct them, whether or not they reflect a real allocation error.
Because the process used to determine whether the errors are real can be time-consuming, you may want to go directly to “Error Resolution” below.
Run dbcc checkalloc in single-user mode if you suspect the 2521 error messages are incorrect. If the error is in master, use the section “How to Start Adaptive Server in Single-User Mode” in the Encyclopedia of Tasks chapter for instructions about how to invoke Adaptive Server in single-user mode. Refer to “dbcc” in the Reference Manual for information about dbcc checkalloc.
If many of these errors are occurring, it is possible to clear them all at once by using the dbcc checkalloc and dbcc checkalloc with fix option commands. Refer to “How to Fix and Prevent Allocation Errors” in the Encyclopedia of Tasks chapter for information about using dbcc checkalloc.
If the text of the error message includes a real object name, not a number, then the error is on an existing object to which the system catalog has correct references. Continue now to “Identify Table: User or System Table”.
If a number appears instead of the object name, then that object only partially exists and the error must be corrected using the procedure described in “How to Fix and Prevent Allocation Errors” in the Encyclopedia of Tasks chapter.
Look at the value for “object id in extent” in the error message. If it is 100 or greater, go to “Action for User Tables”. If the “object id in extent” is below 100, it is a system table and requires a different procedure described in the section “Action for System Tables”.
If the “object id in extent” in the error message is 100 or greater, follow these steps to correct the error:
Check the value of the “index id in extent” in the error message to determine whether it is a table (value is 0) or an index (with a value between 0 and 255).
Run dbcc tablealloc or dbcc indexalloc, depending on whether the object named in the 2521 error message is a table or an index. Before you run the appropriate command, keep the following in mind:
dbcc tablealloc can correct this problem on a table or an index, but if the problem is on an index, you can avoid affecting the entire table by using the dbcc indexalloc command. If the table is large or heavily used, it may be more practical to use dbcc indexalloc.
These commands correct the error only when run in the full or optimized mode. Do not specify the nofix option, or the 2521 error will not be corrected.
You can use either the “object name” or “object id in extent” values from the error message in the commands above where the argument “object_name” appears.
Use the command appropriate for your situation:
For Tables (index id in extent = 0) |
For Indexes (0 < index id in extent < 255) |
|---|---|
1> dbcc tablealloc (object_name) 2> go |
1> dbcc indexalloc (object_name, 2> index_id_in_extent) 3> go |
Refer to “dbcc” in the Reference Manual and “Checking Database Consistency” in the System Administration Guide for information about the dbcc tablealloc and dbcc indexalloc commands.
If the “object id in extent” in the error message is less than 100, follow these steps to correct the error:
Put the affected database in single-user mode:
If the database is master, use the procedure in “How to Start Adaptive Server in Single-User Mode” in the Encyclopedia of Tasks chapter, and then continue with this procedure.
If the database is not master, use the sp_dboption stored procedure to put the affected database in single-user mode:
1> use master 2> go
1> sp_dboption database_name, single, true 2> go
1> use database_name 2> go
1> checkpoint 2> go
Check the value of the “index id in extent” in the error message to determine whether it is a table (value is 0) or an index (value is greater than 0).
Run dbcc tablealloc or dbcc indexalloc, depending on whether the object named in the 2521 error message is a table or an index. Before you run the appropriate command, keep the following in mind:
dbcc tablealloc command above can correct either a table or an index, but if the problem is on an index, you can avoid affecting the entire table by using the dbcc indexalloc command. If you need to minimize the amount of time the table is unavailable, it may be more practical to use dbcc indexalloc.
These commands correct the error only when run in the full or optimized mode, with the fix option specified. This is necessary because the default value is nofix when these commands are run on system tables.
You can use either the “object name in extent” or “object id” values from the error message in the commands above where the argument “object_name” appears.
Use the command appropriate for your situation:
For Tables (index id in extent = 0) |
For Indexes (0 < index id in extent < 255) |
|---|---|
1> dbcc tablealloc (object_name, 2> full, fix) 3> go |
1> dbcc indexalloc (object_name, 2> index_id_in_extent, full, fix) 3> go |
Turn off single-user mode in the database:
If the database is master, use the procedure in “Returning Adaptive Server to Multiuser Mode” in the Encyclopedia of Tasks chapter.
If the database is not master, use the following procedure:
1> use master 2> go
1> sp_dboption database_name, single, false 2> go
1> use database_name 2> go
1> checkpoint 2> go
Refer to “dbcc” in the Reference Manual and “Checking Database Consistency” in the System Administration Guide for information about the dbcc tablealloc and dbcc indexalloc commands.
All versions
16
Table Corrupt: Row length is inconsistent between the computed row length and the recorded row length on page; check the following page and row: pageno=%ld row#=%d computed row length=%d row length on page=%ld
This error may be caused by a hardware problem.
Adaptive Server computes the length of each row by using the values stored in the offset and adjust tables of each row. Errors 2524 occurs when dbcc checkdb or dbcc checktable detects that the actual length of a row does not match the computed length of that row.
This error can occur on a data page as well as on an index page.
If you have clean backups of your database, recover from backups. If you do not have clean backups of your database, refer to “How to Identify and Fix a Corrupted Table” in the Encyclopedia of Tasks chapter to correct the error.
WARNING! Some data on this page might be lost if you recover your table using bcp or select into (that is, the corrupted row and rows following it might be truncated and contain the wrong keys). Compare the two tables (old and new) row by row (by joining them on a primary key, for example) to determine which rows are different (corrupted).
Before dumping your database, make sure it is working correctly by running the following commands prior to each dump:
dbcc checkdb.
dbcc checkalloc or dbcc checkalloc with the fix option. (Refer to “How to Fix and Prevent Allocation Errors” in the Encyclopedia of Tasks chapter for information about running these commands in multi-user mode and how to prevent spurious allocation errors from dbcc commands.)
Error 2524 is probably caused by a problem within Adaptive Server but may also be caused by hardware errors on your database devices. To help rule out this possibility, do the following:
Check the Adaptive Server error log to determine whether there are other indications of hardware problems, such as kernel messages reporting I/O errors.
Check the operating system error log or diagnostics utilities for I/O errors. Refer to “Checking the Operating System Error Log” in the Encyclopedia of Tasks chapter.
If problems persist, refer to the error documentation in this manual or contact Sybase Technical Support.
Refer to bcp in the Adaptive Server utility programs manual.
Refer to “select” in the Reference Manual for information about the select into command.
Have the following information available before you call Sybase Technical Support:
Adaptive Server version and SWR version level
Adaptive Server error log
Operating system error log
Output of dbcc checkdb and dbcc checkalloc
Text of all error messages
All versions
16
Table Corrupt: Object id wrong; tables: alloc page %ld extent id=%ld l page#=%ld objid in ext=%ld (name = %S_OBJID) objid in page=%ld (name = %S_OBJID) objid in sysindexes=%ld (name = %S_OBJID)
This error occurs when dbcc checkalloc detects one of the following problems:
The object ID on a page does not match the object ID on the allocation structure (extent) associated with that page. This is the case when the “objid in ext” matches the “objid in page” from the error message.
The object ID on a page does not match the object ID in the system table sysindexes . This is the case when the “objid in ext” does not match the “objid in sysindexes” from the error message.
Compare the “objid in ext” to “objid in page” from the error message. If they do not match, go to “Object IDs Do Not Match”. If they are equal, go to “Object IDs Match”.
WARNING! If you drop an object before you correct the 2525 error condition, the drop operation could cause pages belonging to another object to be deallocated. This can cause 1108 errors.
There are two possible situations in this scenario. Either the object exists and may be corrupted or it no longer exists. To determine which scenario you have, do the following:
1> use database_name 2> go
1> select object_name(objid_in_extent) 2> go
where database_name is the database where the corruption is reported and objid_in_extent is from the error message.
If the result of the query is a table that currently exists or if either object (object ID on the page or the object ID of the allocation structure associated with that page) is a system table (object ID is less than 100), call Sybase Technical Support. If you have dial-in facilities, Technical Support may be able to repair this corruption without losing any data. However, restoring from known, clean backups may be necessary.
If the query does not return any rows, this means the object that is marked as owning the extent no longer exists.
If the table is a user table, you may be able to correct this error. Back up the data in the table either by using bcp to copy out the table whose object ID appears in “objid in page” or by selecting it into a new table. Refer to “How to Rescue Data from a Corrupted Table” in the Encyclopedia of Tasks chapter for instructions.
Once a copy of the table has been made, you can do one of the following:
Create a clustered index on the table. If you already have a clustered index, drop it and then re-create it.
Drop the corrupt table, re-create it, and move the data back into the table using a bcp in, an insert with a subselect from the holding table, or select into. Alternatively, the holding table itself can be renamed once the original table has been dropped.
There are two possible scenarios:
The pointer to a distribution page for a particular index may be invalid.
There may be a mismatch between the index ID on the allocation page and the index ID on the data page.
Use the following commands to determine which index has the problem. This query compares the “id” column in the output to the “objid in sysindexes” from the error message, and the “distribution” column to the “l page #” from the error message.
1> use database_name 2> go
1> select indid, name, object_name(id) 2> from sysindexes 3> where id = objid_in_sysindexes and 4> distribution = l_page_# 5> go
If this query does not return any rows, contact Sybase Technical Support.
If the query does return a row, drop and re-create the index specified by this query to correct the problem. (Refer to the Adaptive Server Reference Manual for more information about drop index and create index.)
Execute dbcc tablealloc to make sure that the problem is corrected. If the problem still exists, contact Sybase Technical Support.
If the object IDs match, dbcc extentdump and dbcc page can also be used to investigate the problem.
All versions
16
Table Corrupt: Attempted to get page %ld, object %ld; got page %ld, object %ld.
This error may be caused by a hardware problem.
This error occurs when dbcc checkdb, dbcc checktable, dbcc checkalloc, or dbcc tablealloc detects an inconsistency between the location of a page on disk and the page number stored in the page header. In the best case, only the value of the page number is wrong. In the worst case, the entire page is corrupt.
This is a serious error that must be corrected immediately.
If the page number in the error is evenly divisible by 256, the error has occurred on an allocation page. All objects referred to by that allocation unit (that page and the 255 pages following it) may be affected (up to 32 objects). Otherwise, the error occurred on a system or user table.
WARNING! Attempts to drop an object with a 2529 error may result in 821 and 813 errors and additional database corruption.
Note the object ID displayed in the error message.
Run dbcc checkalloc and dbcc checkdb on the database affected to determine the full extent of the corruption.
The 2529 error often results from hardware errors, or system administration problems such as inadvertent use of a raw partition for two separate purposes. Check on and correct any such problems before attempting to restore the database:
Refer to “Correct Use of Raw Partitions” in the Encyclopedia of Tasks chapter for information about using raw partitions.
Check the Adaptive Server error log to determine whether there are other indications of hardware problems, such as kernel messages reporting I/O errors.
Check the operating system error log or diagnostics utilities for I/O errors.
If the 2529 error is on a system table (object ID is less than 100), call Sybase Technical Support. If the object ID is 99, another option is to restore from backups.
If the 2529 error is on a user table (object ID is greater than or equal to 100), you may be able to select the data into another table and drop the original table. Refer to “How to Rescue Data from a Corrupted Table” in the Encyclopedia of Tasks chapter for instructions.
After you drop the original table, you may get an 821 error. In this case, shut down Adaptive Server and restart it. Try a select from the old corrupt table to make sure it is gone, then run dbcc checkalloc and dbcc checkdb to confirm that there is no more corruption.
In some cases, a 2529 error is first reported as a 2503 error, and becomes a 2529 error after Adaptive Server is restarted. Although the procedure described above may clear the 2529 error, it will not remove the main cause of your corruption.
Before calling Technical Support, have the following information available:
Adaptive Server version and SWR version level
Adaptive Server error log
Operating system error log
Output of dbcc checkdb and dbcc checkalloc
Text of all the error messages
All versions
16
Table Corrupt: Page is allocated but not linked; check the following pages and ids: allocation pg#=%ld extent id=%ld logical pg#=%ld object id on extent=%ld (object name = %S_OBJID) indid on extent=%ld
This error occurs when dbcc checkalloc determines that a page is marked as allocated to an object but that page is not being used. There is no corruption or data loss associated with this error.
Each 2540 error means the loss of one blank data page. A few 2540 errors are no cause for concern. However, if many of these errors occur, the amount of “lost” disk space could be significant.
The instructions below are for fixing 2540 errors once
they have occurred. Two easy-to-use strategies exist for detecting
this error sooner in the future. Refer to “Detecting Allocation Errors as Early as Possible” in the Encyclopedia of Tasks
chapter for information about these strategies.
Occasionally dbcc checkalloc reports this error when no real error condition exists. You can either check to determine whether the error is real, or continue with this section and take action to correct it, whether or not it reflects a real allocation error.
Because the process used to discover whether or not the error is real can be time-consuming, you may want to go directly to “Error Resolution” now.
Run dbcc checkalloc in single-user mode if you suspect the 2540 error messages are incorrect. If the error is in master, use the section “How to Start Adaptive Server in Single-User Mode” in the Encyclopedia of Tasks chapter for instructions about how to invoke Adaptive Server in single-user mode. Refer to “dbcc” in the Reference Manual for information about dbcc checkalloc.
If many of these errors are occurring, it is possible to clear them all at once by using the dbcc checkalloc and dbcc checkalloc with fix option commands. Refer to “How to Fix and Prevent Allocation Errors” in the Encyclopedia of Tasks chapter for information about using dbcc checkalloc.
If the text of the error message includes a real object name, not a number, then the error is on an existing object which the system catalog has correct references to, and you should continue now to “Identify Table: User or System Table”.
If a number appears instead of the object name, then that object only partially exists and the error must be corrected using the procedure described in “How to Fix and Prevent Allocation Errors” in the Encyclopedia of Tasks chapter.
Look at the value for “object id on extent” in the error message. If it is 100 or greater, continue with “Action for User Tables”. If the “object id on extent” is below 100, it is a system table and requires a different procedure as described in the section “Action for System Tables”.
If the “object id on extent” in the error message is 100 or greater, follow these steps to correct the error:
Check the value of the “indid on extent” in the error message to determine whether it is a table (value = 0) or an index (value > 0).
Run dbcc tablealloc or dbcc indexalloc, depending on whether the object named in the 2540 error message is a table or an index. Before you run the appropriate command, keep the following in mind:
dbcc tablealloc corrects this problem on a table or an index, but if the problem is on an index, you can avoid affecting the entire table by using dbcc indexalloc. If the table is large or heavily used, it may be more practical to use dbcc indexalloc.
These commands can correct the error only when run in the full or optimized mode, and with the nofix option not specified, the default for user tables.
You can use the object name or object ID in the following commands where the argument “object_name” appears.
Use the command appropriate for your situation:
For Tables (index id in extent = 0) |
For Indexes (0 < index id in extent < 255) |
|---|---|
1> dbcc tablealloc (object_name) 2> go |
1> dbcc indexalloc (object_name, 2> indid_on_extent) 3> go |
Refer to “dbcc” in the Reference Manual and “Checking Database Consistency” in the System Administration Guide for information about dbcc tablealloc and dbcc indexalloc.
If the “object id on extent” in the error message is less than 100, follow these steps to correct the error:
Put the affected database in single-user mode:
If the database is master, use the procedure in “How to Start Adaptive Server in Single-User Mode” in the Encyclopedia of Tasks chapter, and then go to step 2.
If the database is not master, use the sp_dboption stored procedure to put the affected database in single-user mode:
1> use master 2> go
1> sp_dboption database_name, single, true 2> go
1> use database_name 2> go
1> checkpoint 2> go
Check the value of the “indid on extent” in the error message to determine whether it is a table (value is 0) or an index (value is greater than 0).
Run dbcc tablealloc or dbcc indexalloc, depending on whether the object named in the 2540 error message is a table or an index. Then execute the appropriate command. Before you run the appropriate command, keep the following in mind:
dbcc tablealloc corrects either a table or an index, but if the problem is on an index, you can avoid affecting the entire table by using dbcc indexalloc. If you need to minimize the amount of time the table is unavailable, it may be most practical to use dbcc indexalloc.
These commands correct the error only when run in the full or optimized mode, with the fix option specified, because the default value is nofix on system tables.
You can use the “object name” or “object id on extent” in the commands above where the argument object_name appears.
Use the command appropriate for your situation:
For Tables (index id in extent = 0) |
For Indexes (0 < index id in extent < 255) |
|---|---|
1> dbcc tablealloc (object_name, 2> full, fix) 3> go |
1> dbcc indexalloc (object_name, 2> indid_on_extent, full, fix) 3> go |
Turn off single-user mode in the database:
If the database is master, refer to “Returning Adaptive Server to Multiuser Mode” in the Encyclopedia of Tasks chapter.
If the database is not master, use the following procedure:
1> use master 2> go
1> sp_dboption database_name, single, false 2> go
1> use database_name 2> go
1> checkpoint 2> go
Refer to “dbcc” in the Reference Manual and “Checking Database Consistency” in the System Administration Guide for information about dbcc tablealloc and dbcc indexalloc.
All versions
16
Table Corrupt: Extent id %ld on allocation pg# %ld has objid %ld and used bit on, but reference bit off.
This error is reported by dbcc checkalloc if an allocation structure or extent is not linked to the other extents for the object referenced by “objid”, but does reference a page which is linked in the object's page chain. Each occurrence of this error can represent a loss of up to eight pages on disk, or 16K. The pages cannot be used until the error is corrected. Error 2546 can lead to data corruption and can result in various run-time failures. If no other errors are occurring, you can wait until nonpeak hours to correct the problem.
The instructions below are for fixing 2546 errors once
they have occurred. Two easy-to-use strategies exist for detecting
this error sooner in the future. Refer to “Detecting Allocation Errors as Early as Possible” in the Encyclopedia of Tasks
chapter for information about these strategies.
Occasionally dbcc checkalloc reports this error when no real error condition exists. You can either check to determine whether the error is real, or continue with this section and take action to correct it, whether or not it reflects a real allocation error.
Because the process used to discover whether or not the error is real can be time-consuming, you may want to go directly to “Error Resolution” now.
Run dbcc checkalloc in single-user mode if you suspect the 2546 error messages are incorrect. If the error is in master, use “How to Start Adaptive Server in Single-User Mode” in the Encyclopedia of Tasks chapter for instructions about how to invoke Adaptive Server in single-user mode. Refer to “dbcc” in the Reference Manual for information about dbcc checkalloc.
If many of these errors are occurring, it is possible to clear them all at once by using the dbcc checkalloc and dbcc checkalloc with fix option commands. Refer to “How to Fix and Prevent Allocation Errors” in the Encyclopedia of Tasks chapter for information about using dbcc checkalloc.
Execute the following query to make sure the object exists and is correctly referred to in the system catalog:
1> use database_name 2> go
1> select object_name ( objid_from_error_msg) 2> go
If an object name is returned, then the error is on an existing, correctly referenced object. If this is the case, go now to the section “Identify Table: User or System Table”.
If a number, or something other than an object name is returned, use “How to Fix and Prevent Allocation Errors” in the Encyclopedia of Tasks chapter.
Look at the value for “objid” in the error message. If it is 100 or greater, continue with the next section “Action for User Tables”. If the “objid” is below 100, it is a system table and requires a different procedure as described in the section “Action for System Tables”.
If the “objid” in the error message is 100 or greater, follow these steps to correct the error:
Run the dbcc page command described in “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter to obtain the value for the “indid”. Substitute the value for “extent id” in the 2546 error message in place of the “page_number” as described in the procedure.
Run dbcc tablealloc or dbcc indexalloc, depending on whether the value for “indid” indicates it is a table or an index. Before you run the appropriate command, keep the following in mind:
dbcc tablealloc will correct this problem on a table or an index, but if the problem is on an index, you can avoid affecting the entire table by using dbcc indexalloc. If the table is large or heavily used, it may be more practical to use dbcc indexalloc.
These commands will correct the error only when run in the full or optimized mode as long as the nofix option is not specified, the default for user tables.
You can use the object name, if you know it, or the “objid” value from the error message in the commands above where the argument objid appears.
Use the command appropriate for your situation:
For Tables (index id in extent = 0) |
For Indexes (0 < index id in extent < 255) |
|---|---|
1> dbcc tablealloc (objid) 2> go |
1> dbcc indexalloc (objid, indid) 2> go |
Refer to “dbcc” in the Reference Manual and “Checking Database Consistency” in the System Administration Guide for information about dbcc tablealloc and dbcc indexalloc.
If the “objid” in the error message is less than 100, follow these steps to correct the error:
Run the dbcc page command described in “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter to obtain the value for the “indid.” Substitute the value for “extent id” in the 2546 error message in place of the “page_number” as described in the procedure.
Put the affected database in single-user mode:
If the database is master, use the procedure in “How to Start Adaptive Server in Single-User Mode” in the Encyclopedia of Tasks chapter, and then go to step 3.
If the database is not master, use the sp_dboption stored procedure to put the affected database in single-user mode:
1> use master 2> go
1> sp_dboption database_name, single, true 2> go
1> use database_name 2> go
1> checkpoint 2> go
Run dbcc tablealloc or dbcc indexalloc, depending on whether the value of the “indid” from step 1 above indicates that it is a table or an index, then execute the appropriate command. Before you run the appropriate command, keep these facts in mind:
dbcc tablealloc will correct either a table or an index, but if the problem is on an index, you can avoid affecting the entire table by using dbcc indexalloc. If you need to minimize the amount of time the table is unavailable, it may be more practical to use dbcc indexalloc.
These commands will correct the error only when run in the full or optimized mode with the fix option specified, because the default for system tables is nofix.
You can use the object name if you know it, or “object id” value from the error message in the commands above where the argument objid appears.
Use the command appropriate for your situation:
For Tables (indid = 0) |
For Indexes (0 < indid < 255) |
|---|---|
1> dbcc tablealloc (objid, 2> full, fix) 3> go |
1> dbcc indexalloc (objid, 2> indid, full, fix) 3> go |
Turn off single-user mode in the database:
If the database is master, use “Returning Adaptive Server to Multiuser Mode” in the Encyclopedia of Tasks chapter.
If the database is not master, use the following procedure:
1> use master 2> go
1> sp_dboption database_name, single, false
2> go
1> use database_name 2> go
1> checkpoint 2> go
Refer to “dbcc” in the Reference Manual and “Checking Database Consistency” in the System Administration Guide for information about dbcc tablealloc and dbcc indexalloc.
All versions
16
Table Corrupt: Segment number %d specified for use in the segment map in sysusages has no entry in syssegments. The entry in sysusages is for dbid %d (db name = %S_DBID), with a virtual starting address of %ld.
Three system tables store information about segments: master..sysusages, and two system tables in the user database, sysindexes and syssegments. When you allocate a device to a database, an entry is added to master..sysusages, and sysusages.segmap provides bitmaps to the segments of the database on each device. When you create a database Adaptive Server creates the syssegments table in that database and adds rows in the table for the system, default, and log segment. Whenever you add or update segments in a user database, syssegments is updated to reflect new or changed information about the user segments.
Error 2547 is raised when a dbcc check finds an invalid value of sysusages.segmap for a segment. This can happen if you load a user database with user segments different from those in the target database; for example, if you load a database and the target database is larger than the source of the load, and contains a segment which is not in the source, the syssegments table in the newly loaded database will not contain the segment from the higher portion of the target database. As a result, the segmap column in sysusages includes a value not found in syssegments in the newly loaded database, and the dbcc check raises the 2547 error.
If the segmaps disagree within
the size of the database being loaded, sysusages will
be updated to match the loaded database and no 2547 error will be
encountered.
You can correct the problem by updating sysusages to remove the affected segment information, then defining the necessary segment with sp_addsegment.
Take the following steps:
Execute the following command:
1> select * from master..sysusages where dbid = <dbid> 2> go
where <dbid> is the dbid in the error message text.
Note that the segment number reported in the message text is the exponent (power) to which 2 is raised to derive sysusages.segmap. Using this information, find the segmap row in the query output corresponding to the value reported in the error.
For example, suppose sysusages contains a row with segmap = 11, and your error text reports segment number 3; then 2**3 = 8, which is the number by which you need to reduce the segmap value (11) to arrive at a corrected segmap value of 3.
Allow updates to system tables:
1> sp_configure "allow updates", 1 2> go
Correct the affected sysusages row:
1> update master..sysusages set segmap = <new_segmap> where dbid = <dbid> and segmap = <old_segmap> 2> go
In our example:
1> update master..sysusages set segmap=3 where dbid=5 and segmap=11 2> go
Check that exactly one row was affected. Then commit:
1> commit 2> go
Disallow updates to system tables:
1> sp_configure "allow updates", 0 2> go
Shut down and restart the server.
Run sp_addsegment to add any necessary segments to the database. Remember to dump the database after using sp_addsegment.
If errors persist, contact Sybase Technical Support. Have the following information ready before you call:
output of select @@version
output of select * from master..sysusages where dbid = <db_id> where <db_id> is the database ID in the message text.
output of select * from <database_name>..syssegments where <database_name> is the database named in the message text.
Segment errors often result from loading a dump to a target database which is logically different (that is, the placement of segments on the devices is different) from the source database. For a detailed discussion of segments and segment mapping, see
"Creating and Using Segments" in the System Administration Guide.
TechNote 1324, "Segment Remapping with load database When Moving a Database." This document is available in the Technical Library on the Sybase Support site at http://www.sybase.com/support.
All versions
16
Missing segment in sysusages segmap.
This error is reported by dbcc checkcatalog if there is a row in sysusages (in the master database) that has a value of 0 in the segmap column. A value of 0 means that the corresponding space will not be used for further space allocation (data, log, or user-defined objects). The error is not fatal but it does indicate that any free space on that section of the database will not be used.
Causes of this error might be:
All of the segments have been removed from a logical device (via sp_dropsegment).
A direct update has been made to the segmap column of sysusages where the value has been changed to 0.
If you do not want any new space allocated on the affected segment, no action is necessary.
Otherwise, run sp_addsegment or sp_extendsegment on the Sybase logical device that has the problem. If the segment does not already exist in syssegments, use sp_addsegment. If the segment exists, use sp_extendsegment.
To add a new segment:
1> use database_name 2> go
1> sp_addsegment segname, database_name, devname 2> go
where:
segname is the name of the new segment.
database_name is the name of the database where the segment is to be defined.
devname is the name of the database device where segname will be located. (A database device may have more than one segment associated with it. The space on the new segment will only be used if you create tables or indexes on that new segment.)
To extend an existing segment on the device that has a segmap of 0:
1> use database_name 2> go
1> sp_extendsegment segname, database_name, devname 2> go
where:
segname is the name of the existing segment. You can extend the segment called default. If you do, the command would be:
1> use database_name 2> go
1> sp_extendsegment "default", database_name, 2> devname 3> go
database_name is the name of the database where the segment is to be extended.
devname is the name of the database device that has the segmap 0.
To check that the problem has been resolved, type:
1> select * from sysusages where
2> dbid = db_id("database_name") and
3> segmap = 0
4> go
where database_name is the name of the database where the segment you added or extended resides. If no rows are returned, the problem has been resolved.
For further information about sp_addsegment and sp_extendsegment, refer to the Reference Manual.
For further information about segments, refer to “Creating and Using Segments” in the System Administration Guide.
All versions
16
Extent not within segment: Object %ld, indid %d 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.
Error 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, follow these commands:
1> dbcc traceon (2513) 2> go
To turn off trace flag 2513, follow these commands:
1> dbcc traceoff (2513) 2> go
By default, when Adaptive Server creates a database, it creates the following three segments:
The system segment allows system catalog tables to be placed on devices that contain this segment for a particular database.
The 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.
The 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.
Causes of Error 2558 |
See... |
|---|---|
Cause: Loading into a database that has different data and log mapping than the dumped database. |
|
Cause: When you use sp_placeobject, the old allocation area is still in usea. |
“sp_placeobject” |
Cause: When you use sp_dropsegment, existing objects are still mapped to the dropped segment. |
“sp_dropsegment” |
a. Error 2558 is only raised in this case when trace flag 2513 is turned on. |
|
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 may 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.
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.
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 being loaded into 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.
You only need to resolve 2558 errors if the object taking up space on the wrong segment is 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, it might be a good idea to drop and correctly re-create the database, and 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, and 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 |
|---|---|
object ID > 99, index ID = 0 or 1 |
|
object ID > 99, 1 < index ID < 255 |
|
object ID > 99, index ID = 255 |
|
object ID < 100 (and not equal to 8) |
|
object ID = 8 |
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:
Select all the information from the old table into a new table.
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.
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:
Have all users finish transactions and wait until this procedure is finished to initiate any further transactions.
Perform the checkpoint command:
1> use database_name 2> go
1> checkpoint 2> go
Dump the transaction log according to your normal procedures.
Notify users that they may resume normal operations.
Refer to “Creating and Using Segments” in the System Administration Guide for information about segments and devices.
Refer to the Reference Manual for information about checkpoint and dump transaction.
All versions
16
Data page number %ld is empty but is not the first page. Status = 0x%x.
When an object is first created, a single, empty page is allocated to it. Usually there are no other empty pages. Error 2559 occurs when dbcc checktable or dbcc checkdb encounters an empty page while traversing the page chain of an object which is not the first page of the chain.
If you are not encountering any other errors either at run time or from dbcc, it is possible that the empty page will not cause any further problems. Therefore, it is acceptable to wait to correct this problem until nonpeak hours. If other errors are occurring, refer to the information in this manual if applicable or contact Sybase Technical Support.
Correct this situation by forcing the page chain involved to be rebuilt. This can be accomplished in different ways, depending on whether or not the page chain involved is associated with an index or table data. To determine this, refer to “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter to determine the index ID and object ID associated with the page number from the error message.
If the error is on a user table (a system table's object ID is less than 100), go to “User Tables or Clustered Indexes (Index ID is 0 or 1).”
If the error is on a system table and the index ID is not 0, the error is on a system table index. Refer to “How to Fix a Corrupted Index on System Tables” in the Encyclopedia of Tasks chapter for instructions on how to repair the system table index.
If the error is on a system table and the index ID is 0, contact Sybase Technical Support. They may be able to help you repair the corruption or it may be necessary to restore from clean backups.
User Tables or Clustered Indexes (Index ID is 0 or 1)
There are two ways to correct this error, depending on whether you have enough extra disk space to create a clustered index on the table in question.
If a clustered index exists, drop and re-create it. If not, create a dummy clustered index and then drop it. This will remove this problem since creation of a clustered index causes the table to be copied and does not copy the empty pages. Note that clustered index creation does require considerable disk space (refer to “create index” in the Reference Manual).
Use bcp to copy the table out of and then back to the Server:
bcp the table data out to an operating system file.
Empty the table with the truncate table command.
(Optional) Drop all indexes on the table.
bcp the table data into Adaptive Server.
(Optional) Re-create all indexes on the table.
For Nonclustered Indexes (1 < Index ID < 255)
There are two ways to correct this error on a nonclustered index:
Execute the following query in the database in question to determine the index name:
1> select name from sysindexes 2> where id = object_ID and indid = index_ID 3> go
where object_ID and index_ID are from the output of dbcc page run earlier.
Drop and re-create the nonclustered index specified in the query.
Create a clustered index since this forces all nonclustered indexes to be rebuilt. This method may not be suitable for large tables because of the overhead required for creating a clustered index.
All versions
10
Database '%S_DBID' is not in single user mode - may find spurious allocation problems due to transactions in progress.
This warning occurs when you execute dbcc checkalloc on a database that is not in single-user mode. dbcc checkalloc displays this message and then continues to execute.
Executing dbcc checkalloc on a database that is not in single-user mode may cause error messages to be displayed which do not reflect the actual state of your database. These error messages are referred to as spurious. Error messages 2521, 2540, 2546, 7939, 7940, and 7949 may be spurious under these conditions.
No action is required.
If other errors are reported by dbcc checkalloc, refer to this manual for information on how to deal with them.
If your operational environment allows it, put the database in question into single-user mode prior to running dbcc checkalloc.
For the master database, refer to “How to Start Adaptive Server in Single-User Mode” in the Encyclopedia of Tasks chapter.
For other databases, use sp_dboption as follows:
1> use master 2> go
1> sp_dboption database_name, single, true 2> go
1> use database_name 2> go
1> checkpoint 2> go
Refer to “How to Fix and Prevent Allocation Errors” in the Encyclopedia of Tasks chapter.
Refer to “dbcc” in the Reference Manual for information about dbcc checkalloc.
All versions
16
Database '%.*s' is not marked suspect. You cannot drop it with DBCC.
This error occurs when you try to use dbcc dbrepair to drop a database that is not marked suspect. Only databases that have been marked suspect can be dropped using this command.
Databases are marked suspect in the following ways:
Adaptive Server marks a database suspect when some critical errors occur.
The Sybase System Administrator can mark a database suspect in order to drop it with the dbcc dbrepair command.
Try to drop the database with the drop database command. If this fails, use the procedure described in “How to Drop a Database When drop database Fails” in the Encyclopedia of Tasks chapter.
All versions
16
Index page number %ld is empty. Status = 0x%x.
Tables can contain text columns, which are variable-length columns that can hold printable characters, and image columns, which are variable-length columns that can hold binary data. Adaptive Server stores text and image data in a linked list of data pages separate from the rest of the table. Each 2K text or image page stores a maximum of 1800 bytes of data.
Error 2574 occurs when a dbcc check finds problems with a page that is part of a table's text or image page chain. Error 7105 is a related error; it is raised when Adaptive Server attempts data retrieval or another operation on a table with a bad text or image page chain.
Error 2574 is typically due to a small number of bad rows in a table with text or image data, and can be corrected by dropping and re-creating those rows.
Use the following steps to address the problem:
Identify the table. Refer to “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter for information.
Determine the first page of the text/image chain using dbcc pglinkage, with the starting page being the page number from the error message. For example, assuming dbid=7 and starting page number 531:
1> dbcc pglinkage(7, 531, 0, 1, 0, 0) 2> go
Object ID for pages in this chain = 208003772. Beginning of chain reached. Page : 531 Page : 532 Page : 530 3 pages scanned. Object ID = 208003772. Last page in scan = 530.
Page 530 is the first page of the text/image chain.
Identify the row(s) with the bad data using the following command:
1> select column1 from table_name 2> where convert (int, textptr(text_colname)) 3> = first_page_of_chain 4> go
where column1 is any column or columns in your table which will uniquely identify the rows.
Drop the row(s) in question.
Insert the rows back into the table.
Run dbcc checktable on the table to verify that the problem has been corrected.
All versions
16
The last page %ld in sysindexes for table '%.*s' has next page # %ld in its page header. The next page # should be NULL. Please check sysindexes.
The sysindexes table lists each table and index, and the segment where each table, clustered index, nonclustered index, and chain of text pages is stored. It also lists other information such as the first page and root for the object. For heap tables (those with no clustered index), the root entry points to the last page in the table's data page chain.
Adaptive Server expects to find a value of zero for the next page number on the last page for a table (meaning that there are no more pages in the page chain). Error 2575 is raised when dbcc checktable or dbcc checkdb is run, and the next page number in the table's last page is not zero. This error is caused by an incorrect root page value for the table in sysindexes, or corruption in the table's last page.
If this is the only error message you see when you run dbcc checktable or dbcc checkdb, it is likely that the table's root entry in sysindexes is incorrect. Use one of these options to recover from the problem:
Select the table data into a new table, drop the old table, and rename the new table to the old table name. Run dbcc checktable to check that the problem has been resolved.
Bulk copy the affected table out, drop and re-create the table, and bulk copy back in. This is the most efficient solution for a very large table. Run dbcc checktable to confirm that the problem is resolved.
For more information about how to copy a table in a new table or file, refer to “How to Rescue Data from a Corrupted Table” in the Encyclopedia of Tasks chapter.
Call Sybase Technical Support. They may be able to determine the correct last page number and patch the table's root entry in sysindexes.
If you see other errors in addition to Error 2575, the problem may be more extensive. Follow the instructions in this manual for handling those errors.
Before calling Technical Support, have the following information available:
Adaptive Server version and SWR version level
Adaptive Server error log
Output of dbcc checktable or dbcc checkdb
Text of all error messages
All versions
16
The first page %ld in sysindexes for table '%.*s' has previous page # %ld in its page header. The previous page # should be NULL. Please check sysindexes.
The sysindexes table lists each table and index, and the segment where each table, clustered index, nonclustered index, and chain of text pages is stored. It also lists other information such as the first page and root for the object.
Adaptive Server expects to find a value of zero for the previous page number on the first page for a table (meaning that there are no prior pages in the page chain). Error 2578 is raised when dbcc checktable or dbcc checkdb is run, and the previous page number in the table's first page is not zero. This error is caused by an incorrect first page value for the table in sysindexes, or corruption in the table's first page.
If the object with the error is a system table, call Sybase Technical Support. They may be able to help you repair the corruption, but it may be necessary to restore from clean backups.
If the table is a user table, and this is the only error message you see when you run dbcc checktable or dbcc checkdb, it is likely that the table's first page entry in sysindexes is incorrect. Use one of these options to recover from the problem:
Select the table data into a new table, drop the old table, and rename the new table to the old table name. Run dbcc checktable to check that the problem has been resolved.
Bulk copy the affected table out, drop and re-create the table, and bulk copy back in. This is the most efficient solution for a very large table. Run dbcc checktable to confirm that the problem is resolved.
For more information about how to copy a table in a new table or file, refer to “How to Rescue Data from a Corrupted Table” in the Encyclopedia of Tasks chapter.
If you see other errors in addition to Error 2578, the problem may be more extensive. Follow the instructions in this manual for handling those errors.
Before calling Technical Support, have the following information available:
Adaptive Server version and SWR version level
Server error log
Output of dbcc checktable or dbcc checkdb
Text of all error messages
All versions
16
Data page (%S_PAGE) has been marked as an overflow page; however, the previous page (%S_PAGE) does not indicate that there is an overflow page linked to it.
With a clustered index, Adaptive Server maintains data so that the physical order of rows is the same as their logical, indexed order. The bottom or leaf level of a clustered index contains the table's actual data pages. When an index key has a large number of duplicates, all of the data rows may not fit on the same data page. Due to the structure of a clustered index, it is not possible to simply insert these 'overflow' rows to the beginning of the next data page. Instead, Adaptive Server allocates and inserts a new data page between the original data page and the next data page, marking this an overflow page to store the additional values (and marking the original page as having an overflow page). The original page, and the overflow page linked to it, now both contain at least one row with that key value. The overflow page contains only rows with an overflow index value.
On tables without a clustered index, the second page through the last page of the table are marked as overflow pages; the first page through the next-to-last page are marked as having an overflow page.
When dbcc checktable examines a page that is marked as an overflow page, it checks the previous (original) page for consistency. Error 2582 is raised when the original page is not marked as having an overflow page.
Take the following steps to correct the problem:
Use the procedure described in “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter to translate the second page number displayed in the error message into an object ID.
If there is a clustered index on the table, run dbcc tablealloc to correct the problem:
1> dbcc tablealloc (table_name, full, fix) 2> go
Keep in mind that tablealloc can correct the error only when run in the full or optimized mode.
If there is no clustered index on the table, use one of these options to recover from the problem:
Select the table data into a new table, drop the old table, and rename the new table to the old table name. Run dbcc checktable to check that the problem has been resolved.
Bulk copy the affected table out, drop and re-create the table, and bulk copy back in. This is the most efficient solution for a very large table. Run dbcc checktable to confirm that the problem is resolved.
For more information about how to copy a table in a new table or file, refer to “How to Rescue Data from a Corrupted Table” in the Encyclopedia of Tasks chapter.
All versions
16
Number of data pages counted by DBCC differs from count in the data OAM.
The Object Allocation Map (OAM) tracks information about the allocation and deallocation of storage space for objects (tables and indexes). An OAM entry exists for each table (except syslogs and sysgams) and for the table's indexes.
All pages for an object are logically chained together, each page containing a header that includes the page numbers of the previous and next pages in the chain.
Error 2583 is raised when Adaptive Server detects that the count of data pages in the OAM is different from the actual number of pages in the chain. This problem is detected by dbcc checkdb and dbcc checktable.
Usually this error will not cause any operations to fail at run time. Therefore, it is acceptable to wait to correct the problem until nonpeak hours.
Error 2583 is similar to Error 7949; both are raised due to OAM data inconsistencies. Error 2583 occurs when Adaptive Server finds incorrect used page counts for the object, whereas Error 7949 occurs when the server finds incorrect unused page counts.
The instructions below are for fixing 2583 errors once
they have occurred. Two easy-to-use strategies exist for detecting
this error sooner in the future. Refer to “Detecting Allocation Errors as Early as Possible” in the Encyclopedia of Tasks
chapter for information about these strategies.
If many of these errors are raised, as might be the case if you run dbcc checkdb and several tables are affected, it is possible to clear them all at once by using the dbcc checkalloc command with the fix option. Refer to “How to Fix and Prevent Allocation Errors” in the Encyclopedia of Tasks chapter for information about using dbcc checkalloc.
If only a small number of these errors are raised and you know the table name (that is, if you ran dbcc checktable), start by determining whether the affected table is a user table or a system table:
1> select id from sysobjects 2> where name = object_name 3> go
User tables have object IDs of 100 or more; system tables have IDs under 100. Corrective action is different in the two cases because the database must be in single-user mode before correcting system tables.
If the affected table is a user table, run dbcc tablealloc to correct the error:
1> dbcc tablealloc (table_name, full, fix) 2> go
Keep in mind that dbcc tablealloc can correct the error only when run in the full or optimized mode.
Refer to “dbcc” in the Reference Manual and “Checking Database Consistency” in the System Administration Guide for information about dbcc tablealloc.
If the affected table is a system table, follow these steps to correct the error:
Put the affected database in single-user mode:
If the database is master, refer to “How to Start Adaptive Server in Single-User Mode” in the Encyclopedia of Tasks chapter, and then go to step 2.
If the database is not master, use the sp_dboption stored procedure to put the affected database in single-user mode:
1> use master 2> go
1> sp_dboption database_name, single, true 2> go
1> use database_name 2> go
1> checkpoint 2> go
Run dbcc tablealloc to correct the error:
1> dbcc tablealloc (table_name, full, fix) 2> go
Keep in mind that for a system table, dbcc tablealloc can only correct the error when run in the full or optimized mode, and with the fix option specified.
Turn off single-user mode in the database:
If the database is master, refer to “Returning Adaptive Server to Multiuser Mode” in the Encyclopedia of Tasks chapter.
If the database is not master, use the following procedure:
1> use master 2> go
1> sp_dboption database_name, single, false 2> go
1> use database_name 2> go
1> checkpoint 2> go
Refer to “dbcc” in the Reference Manual and “Checking Database Consistency” in the System Administration Guide for information about dbcc tablealloc.
All versions
16
Could not find index row which has id %d for table ’%.*s’.
Error 2591 is raised when you run a dbcc command if Adaptive Server is unable to find an index in sysindexes. The ’id %d’ parameter in the message text shows the index id of the index that the dbcc command expected to find.
Error 2591 occurs with the following dbcc commands:
dbcc reindex
dbcc indexalloc
Error 2591 is raised with the following states:
State |
Meaning |
|---|---|
1 |
dbcc reindex is unable to locate a primary index row for a clustered index on a system table in sysindexes. |
2 |
dbcc reindex is unable to locate a primary index row for a non-clustered index on a system table in sysindexes. |
3 |
dbcc indexalloc is unable to locate the specified index in sysindexes. |
If the error was raised when using dbcc indexalloc, check the index name you supplied in the command, and retry using the correct index name. To verify the available indexes for the table:
1> sp_help <table_name> 2> go
If the error was raised when using dbcc reindex, you need to use an alternative method for correcting the index. Note the object name and index id appearing in the message text, and identify the object id as follows:
1> select object_id(’table_name’) 2> go
Then use the procedure described in “How to Fix a Corrupted Index on System Tables” in the Encyclopedia of Tasks chapter to correct the index.
All versions
16
%S_PAGE has an incorrect pgfreeoff value of %d. The offset should be %d.
The free byte offset on a page indicates the offset of the first unused byte on that page. Error 2596 occurs when dbcc checktable detects that the free byte offset on a page is incorrect.
This is a serious error as it indicates possible corruption on the affected page. This error can occur in conjunction with other errors, particularly Error 2506.
If Error 2596 occurs on a system table being processed by dbcc checktable, call Sybase Technical Support.
If the number of the free byte offset shown in the error message is lower than the expected number, some data has been lost. To determine how much data has been lost, find the difference (in bytes) between the actual free byte offset and the expected free byte offset (both numbers are shown in the error message output). The amount of data lost includes 2 bytes overhead per row where there are only fixed-length columns or 4+n bytes overhead per row with variable-length columns where n is the number of variable-length columns. If you need help, call Technical Support.
Decide whether you should restore the database that contains the affected table from backups. In making that decision, consider the number of rows lost and the number of other corruption errors that have occurred on this table and database.
If the free byte offset on the page header is higher than the expected value, no data has been lost. However, some extraneous rows may exist.
If you have clean backups of your database, recover from backups. If you do not have clean backups of your database, follow these steps to correct the error:
Use the procedure in “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter to identify which table and index correspond to the page number from the error message text.
If the object with the error is not a system table (a system table's object ID is less than 100), continue with step 3.
If the object with the error is a system table and the index ID is not 0, refer to “How to Fix a Corrupted Index on System Tables” in the Encyclopedia of Tasks chapter for instructions on how to repair the system table index.
If the object with the error is a system table and the index ID is 0, contact Technical Support. They may be able to help you repair the corruption or it may be necessary to restore from clean backups.
For user tables, if the index ID is 0 or 255, continue with step 4.
If the index ID is not 0 or 255, translate it into an index name:
1> use database_name 2> go
1> select name from sysindexes 2> where id = object_ID and indid = index_ID 3> go
To ensure that the information needed to re-create the index is available, run sp_helpindex on the index prior to dropping it.
Drop the index.
Re-create the index. This clears the corruption in most cases.
Run dbcc checktable on the table to verify that the corruption is gone.
If the index ID is 255, delete or update the data row to remove the reference to the bad text page.
If the index ID is 0, do one of the following:
Restore the database from clean backups.
Refer to “How to Rescue Data from a Corrupted Table” in the Encyclopedia of Tasks chapter.
WARNING! Some data on this page might be lost if you recover your table using bcp or select into (that is, the corrupted row and rows following it might be truncated and contain the wrong keys). Compare the two tables (old and new) row by row (by joining them on a primary key, for example) to determine which rows are different (corrupted).
Before dumping your database, make sure it is working correctly by running the following commands prior to each dump:
dbcc checkdb.
dbcc checkalloc or dbcc checkalloc with the fix option. (Refer to “How to Fix and Prevent Allocation Errors” in the Encyclopedia of Tasks chapter for information about running these commands in multi-user mode and how to prevent spurious allocation errors from dbcc commands.)
All versions
