Understanding and Managing the suspect_pages Table
The suspect_pages table resides in the msdb databaseand was introduced in SQL Server 2005. The suspect_pages table, which is used for maintaining information about suspect pages, is relevant to deciding whether a restore is necessary.
A page is considered "suspect" when the SQL Server Database Engine encounters one of the following errors when it tries to read a data page:
An 823 error that was caused by a cyclic redundancy check (CRC) issued by the operating system, such as a disk error (certain hardware errors)
An 824 error, such as a torn page (any logical error)
The page ID of every suspect page is recorded in the suspect_pages table. The Database Engine records any suspect pages encountered during regular processing, such as the following:
A query has to read a page.
During a DBCC CHECKDB operation.
During a backup operation.
The suspect_pages table is also updated as necessary during a restore operation, a DBCC repair operation, or a drop database operation.
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.
823 error caused by an operating system CRC error or 824 error other than a bad checksum or a torn page (for example, a bad page ID)
Restored (The page was restored after it was marked bad)
Repaired (DBCC repaired the page)
Deallocated by DBCC
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.
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).
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 also automatically update rows in the suspect_pages table.
DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS updates the suspect_pages table to indicate each page that it has deallocated or repaired.
A full, file, or page RESTORE marks the page entries as restored.
The following actions automatically delete rows from the suspect_pages table.
ALTER DATABASE REMOVE FILE
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.
The following example deletes some of the rows from the suspect_pages table.
' Select restored, repaired, or deallocated pages. DELETE FROM msdb..suspect_pages WHERE (event_type = 4 OR event_type = 5 OR event_type = 7); GO
The following example selects on the bad pages in the suspect_pages table.
' 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