2

Hey everyone I am having an issue with my database. Below is a copy of CHECKDB. When I attempted to do a restore from a backup the restore had the same errors. It appears that my details table is corrupt and the corrupt table was backed up. After that failed I tried to do an index rebuild on that table but it failed as well. Im all out of ideas for this one.

Any suggestions would be greatly appreciated.

Warnings: --->
W (1): CHECKDB found 0 allocation errors and 10 consistency errors 
not associated with any single object.
    W (2): CHECKDB found 0 allocation errors and 24 consistency errors 
in table 'details' (object ID 1853926372).
    W (3): CHECKDB found 0 allocation errors and 34 consistency errors 
in database 'NIX'.
    W (4): repair_allow_data_loss is the minimum repair level for the 
errors found by DBCC CHECKDB (PHOENIX).
           <---
  Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 
359574662873088 (type Unknown), page (3584:587202560). Test (IS_OFF 
(BUF_IOERR, pBUF->bstat)) failed. Values are 12716041 and -14.
  Msg: 8939, Level: 16, State: 98, Procedure: , Line: 1

  Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 
24488610741813248 (type Unknown), page ID (1:233390215) contains an 
incorrect page ID in its page header. The PageId in the page header = 
(78:4784160).
  Msg: 8909, Level: 16, State: 1, Procedure: , Line: 1

  Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 
27866160140386304 (type Unknown), page ID (1:233390212) contains an 
incorrect page ID in its page header. The PageId in the page header = 
(100:6488096).
  Msg: 8909, Level: 16, State: 1, Procedure: , Line: 1

  Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 
28147708131803136 (type Unknown), page ID (1:233390207) contains an 
incorrect page ID in its page header. The PageId in the page header = 
(2816:2052).
  Msg: 8909, Level: 16, State: 1, Procedure: , Line: 1

  Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 
28147914284990464 (type Unknown), page ID (1:233390134) contains an 
incorrect page ID in its page header. The PageId in the page header = 
(78:5111881).
  Msg: 8909, Level: 16, State: 1, Procedure: , Line: 1

  Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 
31244194867511296 (type Unknown), page ID (1:233390211) contains an 
incorrect page ID in its page header. The PageId in the page header = 
(79:5374022).
  Msg: 8909, Level: 16, State: 1, Procedure: , Line: 1

  Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 
5620492349504225280 (type Unknown), page (83:796). Test (IS_OFF 
(BUF_IOERR, pBUF->bstat)) failed. Values are 12716041 and -1.
  Msg: 8939, Level: 16, State: 98, Procedure: , Line: 1

  Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 
6341348650819518464 (type Unknown), page (76:4522067). Test (IS_OFF 
(BUF_IOERR, pBUF->bstat)) failed. Values are 12716041 and -1.
  Msg: 8939, Level: 16, State: 98, Procedure: , Line: 1

  Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 
7133761184305512448 (type Unknown), page (0:525312). Test (IS_OFF 
(BUF_IOERR, pBUF->bstat)) failed. Values are 12716041 and -1.
  Msg: 8939, Level: 16, State: 98, Procedure: , Line: 1

  Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 
7205835271219183616 (type Unknown), page (28160:1728080128). Test 
(IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12716041 and -1.
  Msg: 8939, Level: 16, State: 98, Procedure: , Line: 1

  Object ID 1853926372, index ID 1, partition ID 72059003269808128, 
alloc unit ID 72059273826074624 (type In-row data): Page (1:233390133) 
could not be processed.  See other errors for details.
  Msg: 8928, Level: 16, State: 1, Procedure: , Line: 1

  Table error: Object ID 1853926372, index ID 1, partition ID 
72059003269808128, alloc unit ID 72059273826074624 (type In-row data). 
Page (1:233390133) was not seen in the scan although its parent 
(1:233383837) and previous (1:233390132) refer to it. Check any previous 
errors.
  Msg: 8976, Level: 16, State: 1, Procedure: , Line: 1

  Object ID 1853926372, index ID 1, partition ID 72059003269808128, 
alloc unit ID 72059273826074624 (type In-row data): Page (1:233390134) 
could not be processed.  See other errors for details.
  Msg: 8928, Level: 16, State: 1, Procedure: , Line: 1

  Table error: Object ID 1853926372, index ID 1, partition ID 
72059003269808128, alloc unit ID 72059273826074624 (type In-row data). 
Index node page (1:233383837), slot 98 refers to child page 
(1:233390134) and previous child (1:233390133), but they were not 
encountered.
  Msg: 8980, Level: 16, State: 1, Procedure: , Line: 1

  Object ID 1853926372, index ID 1, partition ID 72059003269808128, 
alloc unit ID 72059273826074624 (type In-row data): Page (1:233390135) 
could not be processed.  See other errors for details.
  Msg: 8928, Level: 16, State: 1, Procedure: , Line: 1

  Table error: Object ID 1853926372, index ID 1, partition ID 
72059003269808128, alloc unit ID 72059273826074624 (type In-row data). 
Index node page (1:233383837), slot 99 refers to child page 
(1:233390135) and previous child (1:233390134), but they were not 
encountered.
  Msg: 8980, Level: 16, State: 1, Procedure: , Line: 1

  Table error: Object ID 1853926372, index ID 1, partition ID 
72059003269808128, alloc unit ID 72059273826074624 (type In-row data). 
Page (1:233390136) is missing a reference from previous page 
(1:233390135). Possible chain linkage problem.
  Msg: 8978, Level: 16, State: 1, Procedure: , Line: 1

  Object ID 1853926372, index ID 1, partition ID 72059003269808128, 
alloc unit ID 72059273826074624 (type In-row data): Page (1:233390206) 
could not be processed.  See other errors for details.
  Msg: 8928, Level: 16, State: 1, Procedure: , Line: 1

  Table error: Object ID 1853926372, index ID 1, partition ID 
72059003269808128, alloc unit ID 72059273826074624 (type In-row data). 
Page (1:233390206) was not seen in the scan although its parent 
(1:233383837) and previous (1:233390205) refer to it. Check any previous 
errors.
  Msg: 8976, Level: 16, State: 1, Procedure: , Line: 1

  Object ID 1853926372, index ID 1, partition ID 72059003269808128, 
alloc unit ID 72059273826074624 (type In-row data): Page (1:233390207) 
could not be processed.  See other errors for details.
  Msg: 8928, Level: 16, State: 1, Procedure: , Line: 1

  Table error: Object ID 1853926372, index ID 1, partition ID 
72059003269808128, alloc unit ID 72059273826074624 (type In-row data). 
Index node page (1:233383837), slot 171 refers to child page 
(1:233390207) and previous child (1:233390206), but they were not 
encountered.
  Msg: 8980, Level: 16, State: 1, Procedure: , Line: 1

Thanks

5
  • What was minimum repair suggested by DBCC CHECKDB. Do you have clean backup before restoring run restore verifyonly.Parallely try restoring with clean backup on same server so that if checkdb repair methods fail(one suggested by Sean) you would have your database and you would not have to start from scratch.
    – Shanky
    Jul 22 '14 at 12:40
  • I have an older backup from a weekish ago. Would I loose all of the new transactions? Jul 22 '14 at 12:44
  • Only full backups no differential or transaction log backup ? if answer is only full backup then yes you would loose data if you restore with one week old backup.
    – Shanky
    Jul 22 '14 at 12:46
  • Alright :-/ one issue is that the transaction log was not being backed up to the backup server. Thank you for your help it sounds like I'll have to get a person to come in and look at it to rebuild the data. Jul 22 '14 at 12:52
  • Try method which Sean suggested about running repair in transaction then check data loss and then appropriate action. You need to weigh that data loss by repair option is greater or by restoring week old backup
    – Shanky
    Jul 22 '14 at 12:55
2

The problem lies in your clustered index (Index id of 1) which is the table data. This is why a rebuild is not going to fix it.

If this is truly a huge deal (for example financial history or data) then I would suggest contacting a consultant who deals with corruption as they will be able to find the issues and mark down what may or may not be lost or recoverable with some more advanced techniques that I won't go through here.

If this isn't a big deal or the data can be entered in again from other records (such as agents, paper trails, or the data just doesn't matter at that point) then I would tell you to get an idea on how much data you're going to potentially lose by restoring a copy of the database to a separate server and running repair_allow_data_loss in a transaction. This will let you inspect all of the changes that checkdb is going to make and you can still investigate/rollback to try different things.

The fact that the corruption is pervasive throughout the backups means it's been there a while, which is quite honestly scary. In tandem with the corruption in the database I would also be tasking someone to investigate the server and why corruption even happened in the first place.

2

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.