Stack Dump in errorlog after corruption in GAM

  • Hi,

    A few days ago, stack dumps appeared in the errorlog after DBCC CHECKDB discovered following corruption:

    DBCC generated following error:

    Msg 8905, Level 16, State 1, Line 1

    Extent (3:1430120) in database ID 8 is marked allocated in the GAM, but no SGAM or IAM has allocated it.

    CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.

    CHECKDB found 1 allocation errors and 0 consistency errors in database 'Staging_wild'.

    repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Staging_wild).

    After correction using DBCC CHECKDB (staging_wild, REPAIR_ALLOW_DATA_LOSS, stack dumps occur even more regular while DBCC CHECKDB doesn’t give me errors anymore.

    We are running SQL2008R2 and have traceflags 1204 and 1222 to log deadlock informative activated.

    Can somebody explain me what went wrong?

    Thanks

    Geert

  • What do the new stack dumps 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
  • does this tell you more?

    ***Stack Dump being sent to X:\MSSQL10_50.MSSQLSERVER\MSSQL\LOG\SQLDump0018.txt

    SqlDumpExceptionHandler: Process 114 generated fatal exception c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server is

    terminating this process.

    * *******************************************************************************

    *

    * BEGIN STACK DUMP:

    * 06/08/11 09:01:07 spid 114

    *

    *

    * Exception Address = 0000000002019BB2 Module(sqlservr+00000000012D9BB2)

    * Exception Code = c0000005 EXCEPTION_ACCESS_VIOLATION

    * Access Violation occurred reading address 0000000000000048

    * Input Buffer 120 bytes -

    * set fmtonly on exec sp_execute 7 set fmtonly off

  • That's not a corruption stack dump. Something's causing access violations (reads of parts of memory that aren't permitted)

    Make sure you're up on patches, if the problem persists, call Microsoft CSS. They have to tools to read these kind of dumps, we don't.

    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

Viewing 4 posts - 1 through 3 (of 3 total)

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