Results 1 to 6 of 6
  1. #1
    Join Date
    Aug 2010
    Posts
    25

    Unanswered: How to fix suspect pages

    Error :824

    SQL Server detected a logical consistency-based I/O error: torn page (expected signature: 0x55555555; actual signature: 0x55555155). It occurred during a read of page (1:63382148) in database ID 2 at offset 0x000078e4508000 in file 'H:\mssql\data\firm _Data.MDF'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBC (Source: MSSQLServer, Error number: 824)


    Any help is appreciated.

    Thanks

  2. #2
    Join Date
    Nov 2003
    Location
    Mars
    Posts
    115
    try this

    EXEC sp_resetstatus 'yourDBname' ;
    ALTER DATABASE yourDBname SET EMERGENCY
    DBCC checkdb('yourDBname ')
    ALTER DATABASE yourDBname SET SINGLE_USER WITH ROLLBACK IMMEDIATE
    DBCC CheckDB ('yourDBname' , REPAIR_ALLOW_ DATA_LOSS)
    ALTER DATABASE yourDBname SET MULTI_USER

    Reff: db file got corrupted - SQL Server Performance

  3. #3
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    Is the database in full/bulk logged recovery mode? Do you do regular transaction log backups? If answers are YES, then read RESTORE DATABASE ... PAGE='fileage' in BOL. Additionally, and prior to jumping into RESTORE, run DBCC CHECKDB to identify exactly what object this page is associated with. You may or may not even be able to restore the page, if it's associated with a system object, or, as MS calls it "critical pages". It is also possible to avoid page restore all together, if it holds nonclustered index records. Dropping and rebuilding such index would do the trick.
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

  4. #4
    Join Date
    Aug 2010
    Posts
    25
    Quote Originally Posted by rdjabarov View Post
    Is the database in full/bulk logged recovery mode? Do you do regular transaction log backups? If answers are YES, then read RESTORE DATABASE ... PAGE='fileage' in BOL. Additionally, and prior to jumping into RESTORE, run DBCC CHECKDB to identify exactly what object this page is associated with. You may or may not even be able to restore the page, if it's associated with a system object, or, as MS calls it "critical pages". It is also possible to avoid page restore all together, if it holds nonclustered index records. Dropping and rebuilding such index would do the trick.
    Thanks for the replies

    Simple backup mode,this is 2nd hot backup server,so log is not imp.

  5. #5
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    In this case you won't be able to do a page restore. If the corrupted page contains system object, then a full restore will be your only answer. If it's a heap or a clustered PK/unique constraint, - following aadil's advice will result in data loss, literally. Let us pray
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

  6. #6
    Join Date
    Aug 2010
    Posts
    25
    Thanks for the reply

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •