Showing posts with label corrupt. Show all posts
Showing posts with label corrupt. Show all posts

Thursday, January 15, 2015

suspect pages errors

USE msdb

GO

SELECT * FROM dbo.suspect_pages


Event_type column gives different values

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.
Error descriptionevent_type value
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) 1
Bad checksum2
Torn page3
Restored (The page was restored after it was marked bad)4
Repaired (DBCC, AlwaysOn, or mirroring repaired the page)5
Deallocated by DBCC7
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).

  • ---To clean up the suspect_pages table run the following

    delete s

    from msdb.dbo.suspect_pages s

    where event_type in (4,5,7)

    Wednesday, June 11, 2014

    Recovery database from suspect mode

    The database was in suspect mode, inaccessible Ran the following query Then restored from the latest full back up

    EXEC sp_resetstatus client_367
    ALTER DATABASE client_367 SET EMERGENCY
    use client_367
    DBCC checkdb
    ALTER DATABASE client_367 SET SINGLE_USER WITH ROLLBACK IMMEDIATE
    DBCC CheckDB ('client_367', REPAIR_ALLOW_DATA_LOSS)
    ALTER DATABASE client_367 SET MULTI_USER