21
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.
This error may be caused by a hardware problem.
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:
During normal processing, when Adaptive Server tries to delete the row specified by the error message.
During database recovery. Database recovery occurs:
During Adaptive Server start-up
When a load database or load transaction command is processed
Some potential causes of error 631 are:
Data corruption during normal processing (for example, an operating system panic occurs, causing interruption in disk writes when using UNIX files for Sybase database devices). This may be due to a problem with Adaptive Server, the operating system, or hardware.
Hardware failure during loading or dumping.
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.
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.
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.
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.
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:
dbcc checkdb.
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.)
Alternatively, using dbcc checkstorage with checkverify can
examine for most types of consistency problems in less time.
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:
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.
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.”
Load the database from backup. Refer to “load database” in Reference Manual: Commands.)
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:
Adaptive Server error log
Text of all error messages
select * from master..sysusages output
One of the following items may help to prevent error 631 from occurring on recovery:
Use shutdown to shut down Adaptive Server instead of shutdown with nowait after a period of heavy update activity in your databases;
or:
checkpoint each database that is being used before shutting down Adaptive Server.
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.
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.
All versions
