Error 625

Severity

21

Message text

Versions prior to 15.0:

Could not retrieve row from logical page  %ld via RID because the entry in the offset table for that RID is less than  or equal to 0.

Version 15.0 and later:

Adaptive Server failed to retrieve a row via its RID in database '%.*s' because the entry in the offset table for that RID is less than or equal to 0. %S_RID. %S_PAGE.

NoteThis error may be caused by a hardware problem.

Explanation

Every row in a database has a unique row ID (RID). The two parts of a row ID are a logical page number and a row number. The row number part of row IDs are stored at the end of every data page and indicate where a certain row is located on that page.

Commands that use row IDs include dbcc checkdb, dbcc checktable, and dbcc checkcatalog. They verify the consistency of indexes and use the row IDs stored in nonclustered indexes to quickly access the data rows.

Error 625 occurs when Adaptive Server tries to retrieve a row from a data page by specifying the row ID and it fails because the requested row ID has an illegal value (smaller than or equal to zero).

This error can occur under the following conditions:

Errors 624 and 625 occur under similar conditions.

Action

Examine your operating system error log file and the Adaptive Server error log to determine if hardware errors may have corrupted your database devices.

Refer to “Finding an object name from a page number” in the chapter “Other Useful Tasks” in the most recent version of Troubleshooting and Disaster Recovery for instructions about how to use the dbcc page command to determine the table and the index involved. Save this information and use it in the appropriate section that follows.

WARNING! The procedure referenced in the preceding paragraph 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.

The specific action you take depends on whether or not you know which index or query caused the problem. In general, dropping and re-creating the index will resolve the index corruption.


Index unknown, query known

If you do not know which index is causing the problem, but you do know which query encounters the problem, use this section to correct it. If you do not know the index or query, use the next section.

  1. Determine which index should be dropped by reading the showplan output for the query that encounters the error and determining which nonclustered index the query is using to access the table in question.

    Turn on showplan and use the no execute mode:

    1> set showplan on
    2> go
    

    1> set noexec on
    2> go
    

    Enter the query that was causing the problem. For example:

    1> select title from titles where title > "Cooking"
    2> go
    
    
    
    STEP 1
    The type of query is SELECT
    FROM TABLE
    titles
    Nested iteration
    Index: titleind
    

    Turn showplan and the no execute mode off again:

    1> set noexec off
    2> go
    
    1> set showplan off
    2> go
    
  2. If the index identified in step 1 is on a system table (object ID is less than 100), 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.

  3. Otherwise, drop and re-create the index identified in step 1 (in this example “titleind”).

    If this did not clear the error, create a clustered index on the table or drop and re-create the existing clustered index. Note that creating a clustered index requires an amount of space equal to 120 percent to 150 percent of the size of the table where you want to create the index.


Both index and query unknown

If you do not know either the index or the query, rebuild all nonclustered indexes on the table using the instructions in this section.

  1. Look at the dbcc page output you obtained earlier.

  2. If the object is a system table (object ID is less than 100), 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 repairing the system table index. Then go to step 4.

  3. For a user table (object ID is 100 or greater), use sp_helpindex to list all indexes on the table, and then rebuild all the nonclustered indexes using one of two methods:

    • Drop and re-create each nonclustered index on the table;

    or:

    • If a clustered index also exists on the table, drop and re-create it, which causes all nonclustered indexes to be automatically rebuilt. If your table is large, you may not have the space to do this (a rough rule of thumb is 120 percent to 150 percent of your table size must be available).

    If the above methods did not clear the error, create a clustered index on the table (if space is available). You may then drop the clustered index.

  4. Run dbcc checktable on the table to confirm that the problem has been resolved.

Additional information

For more information, refer to “create database” in the Reference Manual: Commands guide.

If you need to call Sybase Technical Support for assistance, have available the information listed in “Reporting errors”, including the output from select * from master..sysusages.

Versions in which this error is raised

All versions