Post reply

Corruption and PAGE_VERIFY CHECKSUM

  • June 12, 2013 at 9:45 am

    #278558

    Hi,

    We've been having sporadic cases of corruption. The tables vary but the message is consistent:

    [font="Courier New"]Msg 605, Level 21, State 3, Line 1

    Attempt to fetch logical page (5:537) in database 47 failed. It belongs to allocation unit 72057602025521152 not to 72057602063532032.[/font]

    When I inspect the tables using DBCC IND and DBCC PAGE I can see that, for example, page 5:537 does have an incorrect allocation unit in it's header (as compared to the IAM page).

    Yes, most sources state that most corruption is caused by I/O sub-system, but in our situation we need to prove this.

    On this ms page http://support.microsoft.com/kb/2015739 it reads:

    Ensure you have the PAGE_VERIFY=CHECKSUM database option turned on. While it is possible to still encounter a Msg 605 error with checksum enabled (Ex. "scribbler" problem or incorrect page provided from I/O system), enabling checksum can provide definitive proof that the page was modified incorrectly within the I/O system.

    Could anyone explain to me how this provides definitive proof? Definitive proof would be very helpful in our case!

    Thanks

  • June 12, 2013 at 10:35 am

    #1623421

    Do you have page verify set to CheckSum?

    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

  • June 12, 2013 at 10:38 am

    #1623424

    Yes I've verified that is the case.

    I can't find any 824 errors in the logs though. :ermm:

  • June 12, 2013 at 10:44 am

    #1623428

    Was the database created in SQL 2005/2008?

    If you check the page (via DBCC Page), what's the value for the m_flagBits setting?

    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

  • June 12, 2013 at 10:48 am

    #1623431

    m_flagBits = 0x220

  • June 12, 2013 at 10:49 am

    #1623433

    Sorry, created in SQL 2008 R2...

  • June 12, 2013 at 10:51 am

    #1623435

    Apparently there are some known bugs that cause this (error 605 with no 824). I was told to search google.

    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

  • June 12, 2013 at 10:54 am

    #1623437

    Interesting, thanks.

    I have seen the bug about inserting in to a Temp table but pretty much ruled that out.

    I'll see what I can find.

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

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