Error 2620

Severity

21

Message text

The offset of the row number at offset %d does not match the entry in the offset table of the following page: %S_PAGE.

Explanation

An offset table is stored at the end of every data page and it stores where rows are located on that page. Adaptive Server uses the offset table to quickly access the rows in each page. Error 2620 occurs during an insert operation when Adaptive Server detects inconsistencies in the offset table of the page specified by the error message.

NoteThis error can be caused by a hardware problem.

This is a serious error. You may be able to recover from this error but you may have to restore from known, clean backups.

Action

  1. Record the value of the page from the error message. Perform the procedure in “Finding an object name from a page number” in the most recent Troubleshooting and Disaster Recovery guide to determine the table and index that correspond to the page number.

  2. If the object encountering the error is not a system table (the object ID is less than 100), continue to step 3.

    If the object is a system table and the index ID is not 0 (zero), use the instructions in “Fixing a system table corrupted index” in the Troubleshooting and Disaster Recovery guide to repair the system table index.

    NoteIf the index ID is 0 (zero), contact Sybase Technical Support. They may be able to help repair the corruption, but it may be necessary to restore from clean backups.

  3. For user tables, if the index ID is 0 (zero) or 255, continue to step 4.

    If the index ID is not 0 (zero) or 255:

    1. Translate it into an index name:

      1> use <database_name> 
      2> go
      
    2. 1> select name from sysindexes 
      2> where id = <object_ID> and indid = <index_ID>
      3> go
      
    3. To ensure that the information needed to re-create the index is available, run sp_helpindex on the index prior to dropping it.

    4. Drop the index.

    5. Re-create the index. This clears the corruption in most cases.

    6. Run dbcc checktable on the table to verify that the corruption is gone.

  4. If the index ID is 0 (zero) or 255, do one of the following:

    • Restore the database from clean backups.

      or

    • Perform the procedure in “Rescuing data from a corrupted table” in the most recent version of the Troubleshooting and Disaster Recovery guide.

      WARNING! Some data on the page can be lost if you recover the 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).


What to do before dumping a database

Before dumping a database, verify that it is working correctly. More specifically, run the following commands prior to each database dump:

  1. dbcc checkdb.

  2. dbcc checkalloc or dbcc checkalloc with the fix option. See “Fixing and preventing allocation errors” in the most recent version of the Troubleshooting and Disaster Recovery guide for information about running these commands in multi-user mode and how to prevent false allocation errors from dbcc commands.)

Additional information

If problems persist, this procedure may not be sufficient to clean up the index corruption, and you should contact Sybase Technical Support with the information listed in “Reporting errors”, including output from dbcc checkalloc or dbcc tablealloc and dbcc checkdb.

Versions in which this error is raised

All versions