21
Versions earlier than 15.0:
A row on page %ld was accessed that has an illegal length of %d in database '%.*s'.
Version 15.0 and later:
Adaptive Server accessed a row that has an illegal length of %d while in database '%.*s'. %S_PAGE. The minimum row length is %d. The page size is %d.
This error may be caused by a hardware problem.
This error occurs when Adaptive Server accesses a data or index row whose length is smaller than the minimum row size or greater than the maximum row size.
The minimum length of a row for each object is stored in the minlen column of sysindexes and in each data or index page header. The size of a data row or index row is 1962 characters; allow 2 characters of row overhead for all-pages-locked (APL) tables, for a maximum usable row size of 1960. For data-only-locked (DOL) tables, subtract two characters per varchar column in determining usable row size.
This error can occur:
During normal processing, when Adaptive Server tries to access the row specified by the error message
During database recovery (database recovery occurs during Adaptive Server start-up or a load database or load transaction command is processed)
Error 614 can be caused by 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.
Error 614 is usually the result of a more serious underlying problem, and recovering from this error depends on when the error occurred. Determine whether the error occurred during normal processing or during database recovery, then follow the appropriate set of instructions in this section.
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 the table and index that correspond to the page number from the error message text.
WARNING! The procedure referenced in the step 1 uses 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), go to step 3.
If the object encountering the error is a system table and the index ID is not 0 (zero), see “Fixing a system table corrupted index” in the chapter “Other Useful Tasks” in the most recent version of Troubleshooting and Disaster Recovery.
If the index ID is 0, contact Sybase Technical Support to help you repair the corruption; however, it may be necessary to restore the database from clean backups.
For user tables, if the index ID is 0, go to step 4.
If the index ID is not 0, translate the 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 the index ID is 0, perform one of the following steps:
Restore the database from clean backups.
See the section “Rescuing data from a corrupted table” in the chapter “Other Useful Tasks” in the most recent version of Troubleshooting and Disaster Recovery.
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 see which rows are different (corrupted).
Before dumping a database, verify that it works correctly by running these commands prior to each dump:
dbcc checkdb.
dbcc checkalloc or dbcc checkalloc with the fix option. (See “Fixing and preventing allocation errors” in the chapter “Other Useful Tasks” in the most recent version of Troubleshooting and Disaster Recovery 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:
If the database with the 614 error is tempdb, check the page number. If this page is not valid for tempdb, the problem may be on another database (possibly due to a bad device). Stop here and contact Sybase Technical Support.
If the page is valid for tempdb, or the 614 error refers to a database other than tempdb, continue with step 2.
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 Troubleshooting and Disaster Recovery.
Create a database for load. Make sure the database you create has sizes at 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: Commands for information on “create database for load.”
Load the database from backup. (Refer to “load database” in the 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 with the information from “Reporting errors” available, including the output from select * from master..sysusages.
To prevent error 614 occurring on recovery, checkpoint each database that is being used before shutting down Adaptive Server.
Refer to “Developing a Backup and Recovery Plan” in the System Administration Guide: Volume 2 for information about how to safely create, dump, load, and re-create databases.
All versions
