DBCC - Could not repair this error.

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQL Server 2005 » Data Corruption » DBCC - Could not repair this error.

13 posts, Page 1 of 2

1 2 »»

DBCC - Could not repair this error.

Rate Topic

Display Mode

Topic Options

Author

Message

sqlmate

Posted Friday, August 31, 2012 1:40 PM

SSC Rookie

Group: General Forum Members
Last Login: Yesterday @ 5:08 AM
Points: 36, Visits: 90

Hi guys,
one of my customer's hard drive failed. They were able to safe most of the data and create bit copy of the failed disk but few corrupted sectors were at MDF file. And guess what ... 'we have no backups'. So I run DBCC checkdb and it reported corruption of clustered index, tried to run dbcc checktable (alldocs,repair_allow_data_loss) and got this

DBCC results for 'AllDocs'.
Repair: The Nonclustered index successfully rebuilt for the object "dbo.AllDocs, Docs_IdLevelUnique" in database "WSS_Content_04a315e0-42c4-40d5-a432-65590fe560b0".
Msg 8945, Level 16, State 1, Line 1
Table error: Object ID 69575286, index ID 1 will be rebuilt.
Could not repair this error.
Msg 8976, Level 16, State 1, Line 1
Table error: Object ID 69575286, index ID 1, partition ID 72057608226996224, alloc unit ID 72057608630173696 (type In-row data). Page (1:2728879) was not seen in the scan although its parent (1:2723806) and previous (1:2728878) refer to it. Check any previous errors.
The error has been repaired.
Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 69575286, index ID 1, partition ID 72057608226996224, alloc unit ID 72057608630173696 (type In-row data). Page (1:2728896) is missing a reference from previous page (1:2728879). Possible chain linkage problem.
The error has been repaired.
Msg 8945, Level 16, State 1, Line 1
Table error: Object ID 69575286, index ID 2 will be rebuilt.
The error has been repaired.
There are 51682 rows in 3233 pages for object "AllDocs".
CHECKTABLE found 0 allocation errors and 2 consistency errors in table 'AllDocs' (object ID 69575286).
CHECKTABLE fixed 0 allocation errors and 2 consistency errors in table 'AllDocs' (object ID 69575286).
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

I think I ran out of options ... any thoughts? w00t

Post #1353074

GilaMonster

Posted Friday, August 31, 2012 2:01 PM

SSC-Dedicated

Group: General Forum Members
Last Login: Today @ 2:57 AM
Points: 38,070, Visits: 30,365

Please run the following and post the full and complete output.

DBCC CHECKDB (<Database Name>) WITH NO_INFOMSGS, ALL_ERRORMSGS

Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
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

Post #1353080

sqlmate

Posted Friday, August 31, 2012 2:12 PM

SSC Rookie

Group: General Forum Members
Last Login: Yesterday @ 5:08 AM
Points: 36, Visits: 90

Thank you for your help, here you are:

Msg 2576, Level 16, State 1, Line 1
The Index Allocation Map (IAM) page (0:0) is pointed to by the previous pointer of IAM page (1:102602) in object ID 0, index ID -1, partition ID 0, alloc unit ID 72057608649768960 (type Unknown), but it was not detected in the scan.
CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.
Msg 8976, Level 16, State 1, Line 1
Table error: Object ID 69575286, index ID 1, partition ID 72057608226996224, alloc unit ID 72057608630173696 (type In-row data). Page (1:2728879) was not seen in the scan although its parent (1:2723806) and previous (1:2728878) refer to it. Check any previous errors.
Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 69575286, index ID 1, partition ID 72057608226996224, alloc unit ID 72057608630173696 (type In-row data). Page (1:2728896) is missing a reference from previous page (1:2728879). Possible chain linkage problem.
Msg 2576, Level 16, State 1, Line 1
The Index Allocation Map (IAM) page (0:0) is pointed to by the previous pointer of IAM page (1:1293) in object ID 69575286, index ID 1, partition ID 72057608245936128, alloc unit ID 72057594043760640 (type LOB data), but it was not detected in the scan.
CHECKDB found 1 allocation errors and 2 consistency errors in table 'AllDocs' (object ID 69575286).
CHECKDB found 2 allocation errors and 2 consistency errors in database 'WSS_Content_04a315e0-42c4-40d5-a432-65590fe560b0'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (WSS_Content_04a315e0-42c4-40d5-a432-65590fe560b0).

Post #1353083

GilaMonster

Posted Friday, August 31, 2012 2:31 PM

SSC-Dedicated

Group: General Forum Members
Last Login: Today @ 2:57 AM
Points: 38,070, Visits: 30,365

Hell, a sharepoint DB...
Because of the way sharepoint stores the structure of the site in the tables, repairing a sharepoint DB with repair_allow_data_loss can result in an unusable site.

You did take a backup before starting to repair?
I'd honestly suggest restore that pre-repair backup, see if sharepoint will load and then export any and all libraries from sharepoint that will export and then recreate the site.

Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
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

Post #1353089

Nalini D

Posted Friday, August 31, 2012 3:13 PM

Forum Newbie

Group: General Forum Members
Last Login: Friday, August 31, 2012 3:20 PM
Points: 6, Visits: 21

Did you try re-creating the indexes on the table?

Post #1353100

opc.three

Posted Friday, August 31, 2012 3:22 PM

SSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 1:24 PM
Points: 6,826, Visits: 11,950

Are you thinking of a nonclustered index? I think index ID 1 means it is the clustered index, i.e. the actual pages making up the table so the only way to recover from that is to restore from backup or do a repair with data loss, but that may invalidate the database from SharePoint's perspective as Gail has said.

__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato

Believe you can and you're halfway there. --Theodore Roosevelt

Everything Should Be Made as Simple as Possible, But Not Simpler --Albert Einstein

The significant problems we face cannot be solved at the same level of thinking we were at when we created them. --Albert Einstein

1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples. --Giordy

Post #1353104

GilaMonster

Posted Friday, August 31, 2012 3:56 PM

SSC-Dedicated

Group: General Forum Members
Last Login: Today @ 2:57 AM
Points: 38,070, Visits: 30,365

Nalini D (8/31/2012)

Did you try re-creating the indexes on the table?

Won't work. The repair fixed the damage to the nonclustered index and some damage to the clustered index, but the remaining is also in the clustered index. There's no duplicate copy of the data to work from.

Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
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

Post #1353109

sqlmate

Posted Monday, September 03, 2012 4:31 AM

SSC Rookie

Group: General Forum Members
Last Login: Yesterday @ 5:08 AM
Points: 36, Visits: 90

Thanks everybody for their time.

Luckily with my colleague (SharePoint geek) we were able to salvage document streams, their name, path and version... Well it costs us many hours of work which would not be necessary JUST if there would be water-tight backup. (There were NONE!) MDF had +/- 20GB, LDF 300 GB so guess what ...

Do backup, monitor backup, verify backup .. easy Wink

Post #1353431

arunkumarco

Posted Monday, September 03, 2012 6:21 AM

Grasshopper

Group: General Forum Members
Last Login: Tuesday, October 16, 2012 11:45 PM
Points: 18, Visits: 99

re-create indexes for those tables.

Post #1353489

GilaMonster

Posted Monday, September 03, 2012 7:07 AM

SSC-Dedicated

Group: General Forum Members
Last Login: Today @ 2:57 AM
Points: 38,070, Visits: 30,365

arunkumarco (9/3/2012)

re-create indexes for those tables.

GilaMonster (8/31/2012)

Nalini D (8/31/2012)

Did you try re-creating the indexes on the table?

Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
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

Post #1353501

« Prev Topic | Next Topic »

13 posts, Page 1 of 2

1 2 »»

Permissions