Error 624

Severity

Message text

Versions prior to 15.0:

Attempt to retrieve row from page via RID  failed because the requested RID has a higher number than the last RID on  the page. %S_RID.%S_PAGE.

Version 15.0 and later:

Adaptive Server failed to retrieve a row via its RID in database '%.*s' because the requested RID has a higher number than the last RID on the page. %S_RID. %S_PAGE.

This error may be caused by a hardware problem.

Explanation

This error occurs when Adaptive Server tries to retrieve a row from a data page by specifying the row ID (RID), but the retrieval fails because the requested row ID was a higher number than the last row ID on the page. This can happen:

During normal processing, if the leaf page of a corrupt non clustered index points to an incorrect or nonexistent row ID on a data page.
During database recovery at Adaptive Server startup (database recovery also occurs when a load database command is processed). Recovery fails because the data structure which contains the last checkpoint record in the transaction log is pointing to an incorrect or nonexistent record in the log.

Errors 624 and 625 occur under similar conditions.

Action

Recovery from this error depends on when the error occurred. Determine whether the error occurred during normal processing or during database recovery, then follow the instructions in one of these sections:

If the error occurred during normal processing

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

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 should 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, go to “Index and query both unknown”.

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: titlein
```
Turn showplan and the no execute mode off again:
```
1> set noexec off
2> go
```
```
1> set showplan off
2> go
```
If the index identified in step 1 is on a system table (object ID is less than 100), refer to “Fixing a system table corrupted index” in the chapter “Other Useful Tasks” in the Troubleshooting and Disaster Recovery guide for instructions on repairing the system table index. Otherwise, drop and re-create the index identified in step 1 (in this example “titleind”).

Index and query both 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.

Examine the dbcc page output you obtained earlier.

If the object is a system table (the object ID is less than 100), refer to “Fixing a system table corrupted index” in the “Other Useful Tasks chapter of the Troubleshooting and Disaster Recovery guide for instructions on how to repair the system table index. Then go to step 3.
For a user table, 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; this causes all nonclustered indexes to be 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).
Run dbcc checktable on the table to confirm that the problem has been resolved.

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. Follow the instructions below, depending on the version level of your server:

Drop the suspect database using the instructions in “Dropping a database when drop database fails” in the “Other Useful Tasks” chapter in 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 the Reference Manual: Commands for more 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.

Versions in which this error is raised

All versions