Ok, now I want to tell you what I have done yesterday.
A colleague of mine recognized the dbcc error 09E8 thrown by the backup software. He catched the message on one of our test environments. So, finally my time had come to prove myself. Why? Because I never had to deal with a dbcc error before. First at all, I had no idea what error code 09E8 means. So I just ran a dbcc checkdb with no_infomsgs, all_errormsgs and got the following:
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 517576882, index ID 7: Page (3:3975) could not be processed. See other errors for details.
Server: Msg 8976, Level 16, State 1, Line 1
Table error: Object ID 517576882, index ID 7. Page (3:3975) was not seen in the scan although its parent (3:1975) and previous (3:3834) refer to it. Check any previous errors.
Server: Msg 8944, Level 16, State 1, Line 1
Table error: Object ID 517576882, index ID 7, page (3:3975), row 189. Test (columnOffsets->offTbl [varColumnNumber] <= (nextRec – pRec)) failed. Values are 178 and 13.
Server: Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 517576882, index ID 7. Page (3:4139) is missing a reference from previous page (3:3975). Possible chain linkage problem.
CHECKDB found 0 allocation errors and 4 consistency errors in table ‚JournalHeader‘ (object ID 517576882).
CHECKDB found 0 allocation errors and 4 consistency errors in database ‚faultydb‘.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (faultydb )
Ok, there was a good hint. Then I tried select * from sysindexes where id = 517576882 and guess what? Too much information. If you´re in hurry you may pick the wrong information. It happened to me, so keep eyes open.
So I did it in a better way 2nd time :
select indid, name from sysindexes where id = 517576882 and indid = 7
I picked up a non-clustered index. Last step was ease Drop index, create index. I know, other dba´s would hit me now, because I still do not know what caused the linkage problem. I´ll try to do it better next time.