Understanding and Managing the suspect_pages Table

Errors Recorded in suspect_pages Table

The suspect_pages table contains one row per page that failed with an 824 error, up to a limit of 1,000 rows. The following table shows errors logged in the event_type column of the suspect_pages table.

The suspect_pages table also records transient errors. Sources of transient errors include an I/O error (for example, a cable was disconnected) or a page that temporarily fails a repeated checksum test.

How the Database Engine Updates the suspect_pages Table

The Database Engine takes the following actions on the suspect_pages table:

• If the table is not full, it is updated for every 824 error, to indicate that an error has occurred, and the error counter is incremented.

• If a page has an error after it is fixed by being repaired, restored, or deallocated, its number_of_errors count is incremented and its last_update column is updated

• After a listed page is fixed by a restore or a repair operation, the operation updates the suspect_pages row to indicate that the page is repaired (event_type = 5) or restored (event_type = 4).

• If a DBCC check is run, the check marks any error-free pages as repaired (event_type = 5) or deallocated (event_type = 7).

Automatic Updates to the suspect_pages Table

A database mirroring partner updates the suspect_pages table after an attempt to read a page from a data file fails for one of the following reasons.

• An 823 error that is caused by an operating system CRC error.

• An 824 error (logical corruption such as a torn page).

The following actions automatically delete rows from the suspect_pages table.

• ALTER DATABASE REMOVE FILE

• DROP DATABASE

• DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS updates the suspect_pages table to indicate each page that it has deallocated or repaired.

• RESTORE also updates the list. A full, file, or page restore marks the page entries as restored.

Maintenance Role of the Database Administrator

Database administrators are responsible for managing the table, primarily by deleting old rows. The suspect_pages table is limited in size, and if it fills, new errors are not logged. To prevent this table from filling up, the database administrator or system administrator must manually clear out old entries from this table by deleting rows. Therefore, we recommend that you periodically delete or archive rows that have an event_type of restored or repaired, or rows that have an old last_update value.

To monitor the activity on the suspect_pages table, you can use the Database Suspect Data Page Event Class. Rows are sometimes added to the suspect_pages table because of transient errors. If many rows are being added to the table, however, a problem probably exists with the I/O subsystem. If you notice a sudden increase in the number of rows being added to the table, we recommend that you investigate possible problems in your I/O subsystem.

A database administrator can also insert or update records. For example, updating a row might useful when the database administrator knows that a particular suspect page is actually intact, but wants to preserve the record for a while.

Examples

' Select restored, repaired, or deallocated pages.
DELETE FROM msdb..suspect_pages
   WHERE (event_type = 4 OR event_type = 5 OR event_type = 7);
GO

' Select nonspecific 824, bad checksum, and torn page errors.
SELECT * FROM msdb..suspect_pages
   WHERE (event_type = 1 OR event_type = 2 OR event_type = 3);
GO

See Also

Reference

Concepts