Suspect Pages causes database backup to fail.

  • On one of my production machines , recently I got alerts regarding the full/differential database backup failure . On Investigation I found 2 pages are corrupt (checked msdb..suspect_pages) .However the log backup is running fine.

    .The instance /database details are :

    SQL SERVER 2005 Enterprise

    Database - 600 GB ( approx.)

    Tool used for backup - LiteSpeed

    I got the below alert message :

    SQL Server has returned a failure message to LiteSpeed for SQL Server which has prevented the operation from succeeding.The following message is not a LiteSpeed for SQL Server message. Please refer to SQL Server books online or Microsoft technical support for a solution:

    BACKUP DATABASE is terminating abnormally.

    A nonrecoverable I/O error occurred on file "VDI_113FE06A-4F59-4EA9-99EC-E7CE0EF40938_0:" 995(The I/O operation has been aborted because of either a thread exit or an application request.).

    BACKUP xxx detected an error on page (3:4544249) in file 'F:\x.ndf'.

    Msg 50000, Level 16, State 1, Server sss\eeee, Line 1

    Error performing LiteSpeed backup.

    Outcome: Failed

    We removed this database and restored another db on the same location but the new database again got corrupted (has the same problem again related to suspect pages).

    The storage has also been checked and no problem is found on the LUN assosiated with the x.ndf .

    Please advice.

  • Has the entire IO Subsystem been checked, not just the disks? Drivers, hardware, etc.

  • The entire I/O subsystem has been checked but no problems are reported. Can you advice steps from the DB perspective we can try to dig deep into this problem ..

  • Corruption is almost always an IO subsystem problem. Could be anything from IO drivers right down to the physical disks.

    What does CheckDB say?

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • @Gail - Will run the CheckDB during the maintenance window, but till now we havn't tried this option..

  • ??? You mean you're not running regular integrity checks? Why on earth not?

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Second vote here for DBCC CHECKDB. You cannot prevent corruption, so you need to run this regularly. If you can't do it every day, do it every week.

    The checking, was it done by storage people looking for errors? That isn't a check, or not much of one. They need to open a case with your storage vendor ASAP and check all drivers, firmware, and hardware with detailed diagnostics. As Gilamonster mentioned, this is almost always a hardware or software associated with the hardware, issue.

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply