January 29, 2013 at 12:37 pm
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?
January 30, 2013 at 9:10 am
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.
January 30, 2013 at 9:47 am
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
January 31, 2013 at 6:32 am
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