Troubleshooting and Error Messages Guide
|Chapter 3 Error Message Writeups|
|Access Method Errors|
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.
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 "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.
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_ID3> 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 "How to Rescue Data from a Corrupted Table" in the Encyclopedia of Tasks chapter.
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 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 how to run these commands in multi-user mode and how to prevent spurious allocation errors from dbcc commands.)
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 "How to Drop a Database When drop database Fails" in the Encyclopedia of Tasks chapter.
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 the Reference Manual for more information on create database for load.
Load the database from backup. (Refer to "load database" in the Reference Manual.)
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.
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 for complete information about how to safely create, dump, load, and re-create databases.