Found a database error and need advice

  • I was testing some backups on a test server and found that a database generated an error when running CHECKDB BDCC (N'<DB NAME>') WITH NO_INFOMSGS.

    "Msg 0, Level 11, State 0, Line 0

    A severe error occurred on the current command. The results, if any, should be discarded."

    Since this is a test server I tried it on the production version using , ALL_ERRORMSGS. So DBCC CHECKDB(N'<DB NAME>') WITH NO_INFOMSGS, ALL_ERRORMSGS is returing this:

    "Msg 8921, Level 16, State 1, Line 1

    Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.

    Msg 8966, Level 16, State 4, Line 1

    Unable to read and latch page (1:372048) with latch type SH. UtilDbccVerifyPageId failed.

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

    Msg 2579, Level 16, State 1, Line 1

    Table error: Extent (1:378648) in object ID 5, index ID 1, partition ID 327680, alloc unit ID 327680 (type In-row data) is beyond the range of this database.

    CHECKDB found 1 allocation errors and 0 consistency errors in table 'sys.sysrowsets' (object ID 5).

    CHECKDB found 1 allocation errors and 1 consistency errors in database '<DB NAME>'."

    This database just got moved to our server in October and I did a check the first backup we have of that database and its giving the exact same error as the current production.

    The application is still using this database without reporting any errors so Im not sure if its the user data that is causing the problem or a system object. I checked the tempdb location and there is plenty of drive space.

    So my questions are:

    What would be the best way to handle this database now?

    Why would SQL Server allow a database to get attached/restored if there is a problem with the database?

    I havent been running a CHECHDB CHECKDB automatically but that will change now.

    What would be the best schedule to run this? Daily, Weekly, Monthly?

  • Well after some googling searches I went ahead and exported all the user data out of the database into another one with the same schema.

    Ran a check on that database and it came back error free. I have the corrupted database offline for now until we're sure all data is the same. Then Ill remove that database.

    Scheduled a integrity check to run once a week for now, I might change it to a daily task during out slow period.

  • That's fatal corruption you found there (system table damaged). Only solutions are restore from backup or, as you did, script export and recreate the database.

    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
  • You should really run the integrity check nightly and have it email you if it fails. That way you have a good backup to restore from in the future and you will know when the corruption occurs.

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

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