Error 631

Severity

21

Message text

Versions earlier than 15.0:

The length of %d passed to delete row routine for the row at offset %d is incorrect on the following page: %S_PAGE. The expected row length is %d. The offset should be no greater than %d.

Version 15.0 and later:

The length of %d passed to delete row routine for the row at offset %d is incorrect on the following page of database '%S_DBID': %S_PAGE. The expected row length is %d. The offset should be no greater than %d.

NoteThis error may be caused by a hardware problem.

Explanation

This error occurs when Adaptive Server attempts to delete a row (via a direct delete or inherently through updating) from an index or data page by specifying the row offset and the row length, and the action fails because the specified values of the offset or row length did not match the actual values.

Error 631 can happen under the following conditions:

Some potential causes of error 631 are:

Action

Error 631 is probably the result of a more serious underlying problem, and recovering from this error depends on when the error occurred. Follow the instructions in this section, selecting the correct set depending on whether the error occurred during normal processing or during database recovery.


If the error occurred during normal processing

  1. Use the procedure in “Finding an object name from a page number” in the chapter “Other Useful Tasks” in the most recent version of Troubleshooting and Disaster Recovery to identify which table and index correspond to the page number from the error message text.

    WARNING! The procedure referenced in the step 1uses the dbcc page command. Use the dbcc page command only as directed. This command is undocumented, nonstandard, and is provided “as is” without any warranty. Sybase Technical Support does not support this command for general use. Although the command syntax is provided for reference, use this command only in the specific diagnostic situations described, and with the specific syntax shown. Failure to do so could cause performance problems and database corruption.

  2. 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 “Fixing a corrupted system table index” in the chapter “Other Useful Tasks” in the most recent version of the Troubleshooting and Disaster Recovery guide 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 you may have to restore from clean backups.

  3. 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 the sp_helpindex procedure 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.

  4. If the index ID is 255, delete the bad data row.

    If the index ID is 0, do one of the following:

    • Restore the database from clean backups.

    • Refer to “Rescuing data from a corrupted table” in the chapter “Other Useful Tasks” in the most recent version of the Troubleshooting and Disaster Recovery guide.

      WARNING! Some data might be lost on this page 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 works correctly. Run the following commands prior to each dump:

  1. dbcc checkdb.

  2. dbcc checkalloc or dbcc checkalloc with the fix option. (Refer to “Fixing and preventing allocation errors” in the chapter “Other Useful Tasks” in the most recent version of the Troubleshooting and Disaster Recovery guide for information about how to run these commands in multi-user mode and how to prevent spurious allocation errors from dbcc commands.)

    NoteAlternatively, using dbcc checkstorage with checkverify can examine for most types of consistency problems in less time.


If the error occurred during database recovery

When this error occurs during recovery, the database is marked suspect and is not accessible. Usually, you must load the database from backup. To do this, follow the instructions below:

  1. Drop the database. If the drop fails, follow the instructions in “Dropping a database when drop database fails” in the chapter “Other Useful Tasks” in the most recent version of the Troubleshooting and Disaster Recovery guide.

  2. Create a database for load. Make sure the database you create has sizes as least as large as those in sysusages for the original database (and that all other sysusages values match the original values). Refer to “create database” in Reference Manual: Commands for more information on “create database for load.”

  3. Load the database from backup. Refer to “load database” in Reference Manual: Commands.)

  4. Use the online database command to make the database available for use.

If loading from backups is not feasible, call Sybase Technical Support. Have the following documentation ready:


Preventing this error on recovery

One of the following items may help to prevent error 631 from occurring on recovery:

or:

Examine both your operating system error log and the Adaptive Server error log to determine if hardware errors may have affected your database devices. Look for any kernel messages reporting I/O errors and check the hardware error log or diagnostics utilities for I/O errors.

Additional information

Refer to “Developing a Backup and Recovery Plan” in the System Administration Guide: Volume 2 for complete information about how to safely create, dump, load, and re-create databases.

Versions in which this error is raised

All versions