January 27, 2009 at 12:42 pm
This is our customer db. SQL 2005 SP2.
When they did a checkdb, they got:
DBCC results for 'xxxxxx'.
Msg 2515, Level 16, State 1, Line 1
The page (3:10), object ID 7, index ID 1, partition ID 458752, allocation unit ID 458752 (type In-row data) has been modified, but is not marked as modified in the differential backup bitmap.
There are 18466 rows in 200 pages for object "sysallocunits".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'sysallocunits' (object ID 7).
Msg 7995, Level 16, State 1, Line 1
Database 'xxxxxx': consistency errors in system catalogs prevent further DBCC checkdb processing.
CHECKDB found 0 allocation errors and 1 consistency errors in table 'ALLOCATION' (object ID 99).
CHECKDB found 0 allocation errors and 2 consistency errors in database 'xxxxxx'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (xxxxxx).
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Anybody knows what could be the possible reasons for this to happen? Also, is it possible that an application could have caused this (by doing SQL) or is it more likely a problem of the db server?
Thanks a lot.
January 27, 2009 at 1:16 pm
James Zhang (1/27/2009)
Anybody knows what could be the possible reasons for this to happen? Also, is it possible that an application could have caused this (by doing SQL) or is it more likely a problem of the db server?
Most likely it's a problem with the IO subsystem. SQL won't corrupt its own databases. Maybe stale reads, dunno. Check the windows event log and any drive logs that you have, see if there's anything else
Do you have a clean backup? Since checkDB can't finish checking (consistency errors in system catalogs prevent further DBCC checkdb processing), I highly doubt it's going to repair.
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 27, 2009 at 2:54 pm
Thanks for the notes.
I, too, do not think any SQL operations could have caused this kind of corruption. Will focus on IO, etc.
thanks.
January 27, 2009 at 4:45 pm
Yup - CHECKDB can't get past this. If you don't have a backup, you'll need to extract out to a new database (plus do root cause analysis).
Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply