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
Page %ld was expected to be the first page of a TEXT/IMAGE value.
Adaptive Server stores text and image data in a linked list of pages separate from the rest of the table. Error 7901 is raised when a dbcc utility is processing a text/image page chain, but finds that the first page in this chain is not a text or image page. The error is due to a corrupt page header in the first page, or a bad text pointer in a row in the table.
Error 7901 is raised with the following states:
State |
Meaning |
|---|---|
1 |
dbcc checktable detected the first-page error while checking a table’s text/image chains. |
2 |
dbcc fix_text detected the first-page error while recalculating the statistics for a table’s text pages. |
3 |
dbcc rebuild_text detected the first-page error while rebuilding the internal data structures for text/image data. (This state is raised in version 12.0 and higher). |
Take the steps described below to resolve the error.
Identify the row(s) with the bad data using the following command:
1> select <unique_col> from table_name 2> where convert (int, textptr(<text_colname>)) 3> = <text_page> 4> go
where unique_col is any column or columns in your table which will uniquely identify the rows, text_colname is the text column, and text_page is the page ID in the message text.
Drop the row(s) in question.
Run dbcc checktable on the table to verify that the problem has been corrected.
As an alternative to dropping row(s), you can create a new table using select into, specifying all rows from the original table except the affected row(s) identified in Step 1. Refer to “How to Rescue Data from a Corrupted Table” in the Encyclopedia of Tasks chapter for details.
All versions
16
Data size mismatch occurred while checking TEXT/IMAGE values. The first page for this value is: %ld. There were %ld bytes found, which is different from the expected data length of %ld bytes.
This error may be caused by a hardware problem.
This error occurs when Adaptive Server detects a mismatch between the expected length of the text/image data of a text column and its actual length. The length of the text/image data is stored on the page header of the text/image data page.
This error usually occurs in one of the following situations:
When you run dbcc checktable on a table whose text or image column was updated to NULL and then updated again to a non-NULL value via a writetext command which did not commit.
When you run dbcc checktable or dbcc checkdb and your image or text data is corrupted. If this is the case, check your hardware error log and your operating system error log and determine the cause of the 7902 error.
In order to eliminate the 7902 error, perform the following steps for each table encountering it:
Record the page numbers reported by Error 7902 for your table.
Select the offending rows from your table in a separate temporary table, giving the name of the text column for the textptr function:
1> select * into #newtable from mytable 2> where convert (int, textptr(text_colname)) 3> in (list_of_page#'s) 4> go
The list of page numbers in the above query is the enumeration of all the page numbers specified by the 7902 errors. text_colname is the name of the text column.
Update the corrupted text/image data from the old table with the text/image data from the new table:
1> begin transaction 2> go
1> update mytable 2> set mytable.text_col = #newtable.text_col 3> from #newtable 4> where mytable.other_col = #newtable.other_col 5> go
Make sure that only the required number of rows are updated by the above query and then commit the transaction. other_col in the above query is the name of another column in your table which uniquely identifies a row (like a primary key). If you do not have any primary keys on your old table, run the above query with several search conditions in the where clause:
1> update mytable 2> set mytable.text_col = #newtable.text_col 3> from #newtable 4> where mytable.col1 = #newtable.col1 5> and mytable.col2 = #newtable.col2 6> go
Make sure that only the required number of rows are updated by the above query and then commit the transaction:
1> commit transaction 2> go
You will get the following messages during dbcc checktable:
Checking mytable
Msg 7902, Level 16, State 1:
Server 'PRODUCTION', Line 1:
Data size mismatch occurred while checking TEXT/IMAGE values. The first page for this value is: 321. There were 12 bytes found, which is different from the expected data length of 0 bytes.
Msg 7902, Level 16, State 1:
Server 'PRODUCTION', Line 1:
Data size mismatch occurred while checking TEXT/IMAGE values. The first page for this value is: 291. There were 17491 bytes found, which is different from the expected data length of 19291 bytes.
Run the following query in order to select the erroneous rows from mytable into #newtable:
1> select * into #newtable from mytable 2> where convert (int, textptr(text_colname)) 3> in (321, 291) 4> go
An alternate method is to select all data from the old table into a new table.
If the index ID is 0 or 255 and you do not have clean backups of your database, copy the data from the corrupted table into a new (dummy) table or into a file. Then rename your old, corrupted table and copy the data back into a new table using the original name. For more information about doing this, 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. 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 “dbcc” in the Reference Manual for information about dbcc checkalloc.
Consider using writetext with log or update instead of writetext with no log. This way, you will not have unlogged changes to your database and will not get 7902 errors if writetext with no log did not commit.
For more information, refer to select into, convert, and writetext in the Adaptive Server Reference Manual and in the Transact-SQL User's Guide.
All versions
16
Index %.*s is not consistent; found %ld leaf rows but %ld data rows. Drop and recreate the index.
This error is returned by dbcc checktable or dbcc checkdb (which calls dbcc checktable). When checking the integrity of a nonclustered index, checktable compares the leaf row count (the total number of rows in the leaf pages for the index) with the count of data rows. Error 7928 is raised when the leaf row count does not match the data row count, and indicates an index problem.
Correct the problem by re-creating the index as follows:
Check the output of the dbcc query to identify the table associated with the index.
If the table is a system table, refer to “How to Fix a Corrupted Index on System Tables” for instructions on how to repair the system table index. Then go to Step 4.
If the table is a user table, take the following steps:
Run sp_helpindex on the index to ensure that the information needed to re-create the index is available.
Drop the index.
Re-create the index.
Run dbcc checktable on the table to verify that the corruption is gone. If corruption still exists, call Sybase Technical Support.
Have the following information ready when you call Sybase Technical Support:
Server version and SWR rollup level
Text of all error messages
All transaction logs dating back to the last clean dbcc run.
All versions
16
Table Corrupt: keys in left child do not precede the parent key; check left child page %ld.
This serious error is returned by dbcc checktable or dbcc checkdb (which calls dbcc checktable). dbcc checktable checks a table and its indexes to determine whether:
Pages are linked correctly
Indexes are properly sorted
Pointers are consistent
Page offsets are consistent
sysindexes pages are correct
The data row count is equal to the leaf row count for nonclustered indexes
During index level checking, for each key in the parent page, dbcc checktable checks whether the last key in the left child page is less than the parent key, and whether the first key in the right child page is greater than or equal to the parent key. If the last key in the left child is not less than the parent key, Error 7930 occurs.
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 encountering 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. Then go to step 5.
If the object with the error is a system table and 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 a user table and the index ID is not 0, determine whether there is a clustered index on the table:
1> sp_helpindex table_name 2> go
where table_name is the name you determined in step 1.
If there is a clustered index on the table, rebuild it. Then go to step 5.
If there is a nonclustered index on the table, rebuild the index using the following steps.
Translate the index ID 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 corruption still exists, call Sybase Technical Support.
Refer to drop index and create index in the Reference Manual for information about dropping and re-creating indexes.
All versions
16
Table Corrupt: The entry is missing from the OAM for object id %ld indid %d for allocation page %ld.
This error is raised when Adaptive Server detects that the allocation pages associated with an object are not recorded in the object allocation map (OAM) for the object. This problem is detected by dbcc checkalloc, dbcc tablealloc, and dbcc indexalloc.
Usually, Error 7939 will not cause any operations to fail at run time, so it is acceptable to wait to correct this problem until non-peak hours. However, do not drop a table with the 7939 error, as subsequent dbcc checkalloc commands may produce 2540 and 2546 errors.
The instructions below are for fixing 7939 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 discover whether or not the errors are real can be time-consuming, you may want to go directly to the “Error Resolution” section now.
Run dbcc checkalloc in single-user mode if you suspect the 7939 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 to start Adaptive Server in single-user mode. Refer to “Checking Database Consistency” in the System Administration Guide 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 with fix option command. 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, use the procedure in “Fixing Allocation Errors when Object ID and Index ID are Known” in the Encyclopedia of Tasks chapter.
If a number, or something other than an object name is returned, use the procedure in “How to Fix and Prevent Allocation Errors” in the Encyclopedia of Tasks chapter.
All versions
22
The counts in the OAM are incorrect. This implies that there are entries missing. Run tablealloc utility with the FIX option on the table with the inaccurate OAM counts.
This error is raised when Adaptive Server detects that the total page count in the object allocation map (OAM) is different from the actual number of pages in the chain. This problem is detected by dbcc checkalloc, dbcc tablealloc, and dbcc indexalloc.
This error can result in various run-time failures and should be corrected; however, if no other errors are occurring, you can wait to correct the problem until non-peak hours.
The instructions below are for fixing 7940 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 discover whether or not the errors are real can be time-consuming, you may want to go directly to the “Error Resolution” section now.
Run dbcc checkalloc in single-user mode if you suspect the 7940 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 “Checking Database Consistency” in the System Administration Guide for information about dbcc checkalloc.
Error Resolution
If many of these errors are occurring, it is possible to clear them all at once by using the dbcc checkalloc with fix option command. Refer to “How to Fix and Prevent Allocation Errors” in the Encyclopedia of Tasks chapter for information about using dbcc checkalloc.
Get the table name that the error occurred on from the original output which indicated this error. If it is a user table, continue with “Action for User Tables”. If it is a system table, it requires a different procedure described in the section “Action for System Tables”.
Run dbcc tablealloc. This command 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):
1> dbcc tablealloc (table_name) 2> go
Refer to “dbcc” in the Reference Manual and “Checking Database Consistency” in the System Administration Guide for information about dbcc tablealloc.
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
Run dbcc tablealloc. This command corrects 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:
1> dbcc tablealloc (table_name, full, fix) 2> 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.
All versions
16
The number of pages used and unused for %ld index %d on allocation page %ld do not match the counts in the OAM entry.
This error occurs when Adaptive Server detects that the allocation page count in the Object Allocation Map (OAM) is different from the actual number of pages in the chain. This problem is detected by dbcc checkalloc, dbcc tablealloc, and dbcc indexalloc. The object ID is the value immediately before the index value in the error text.
Usually this error will not cause any operations to fail at run time. Therefore, it is acceptable to wait to correct this problem until non-peak hours.
The instructions below are for fixing 7949 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 discover whether or not the errors are real can be time-consuming, you may want to go directly to the “Error Resolution” section now.
Run dbcc checkalloc in single-user mode if you suspect the 7949 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 “Checking Database Consistency” in the System Administration Guide 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 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.
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, use the procedure in “Fixing Allocation Errors when Object ID and Index ID are Known” in the Encyclopedia of Tasks chapter.
If a number, or something other than an object name is returned, use the procedure in “How to Fix and Prevent Allocation Errors” in the Encyclopedia of Tasks chapter.
All versions
16
The serial allocation flag was found to be improperly set in allocation unit %ld, at extent ID %ld, with alloc map = %d and objid = %ld. This flag has been cleared by DBCC.
When you initialize a database device, the space is divided into allocation units of 256 2K pages each. When an object requires space, Adaptive Server allocates a block of 8 2K pages within the unit, known as an extent, to the object.
The first page of each allocation unit is an allocation page, which stores information about each extent contained in the allocation unit. The allocation page also contains a serial allocation flag, which indicates whether extents in the unit are allocated in serial, unbroken order. This flag enables more efficient processing: dumps and loads, for example, can process a set of transaction log pages as a group without having to traverse individual log pages.
dbcc checkalloc examines each allocation page for consistency. When it finds an allocation page with serial allocation turned on, checkalloc verifies that all extents in that allocation unit are indeed allocated serially. If this is not the case, checkalloc raises Error 7989.
Error 7989 is informational. No action is needed. checkalloc resets the flag to indicate that the extents are not serially allocated.
All versions
