Sysindexes DB corruptions

Question

Sysindexes DB corruptions

Dave Foster

SSC Veteran

Points: 235
More actions
March 30, 2006 at 6:59 am

#168896

I recieved the following error when I ran the Check DB command. In the past when I have had corruption in the sysindexes table, I have had to create a brand new DB and DTS the information from the corrupt db into the new one. I would hate to have to do this at this time, but running checkdb with repair_allow_data_loss on a system table does not sound like a great idea to me either. Any suggestions?
Server: Msg 8929, Level 16, State 1, Line 1
Object ID 2: Errors found in text ID 451608576 owned by data record identified by RID = (1:2213:19) id = 1207675350 and indid = 6.
Server: Msg 8965, Level 16, State 1, Line 1
Table error: Object ID 2. The text, ntext, or image node at page (1:5686), slot 1, text ID 451608576 is referenced by page (1:4662), slot 89, but was not seen in the scan.
DBCC results for 'sysindexes'.
There are 1758 rows in 64 pages for object 'sysindexes'.
CHECKTABLE found 0 allocation errors and 2 consistency errors in table 'sysindexes' (object ID 2).
April 3, 2006 at 8:00 am

This was removed by the editor as SPAM

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply

Rudyx - the Doctor SSC-Forever Points: 43695 More actions · Answer 1

I've only seen a corrupt sysindexes table once or twice in 20+ years. Unfortunately I do not have the answer. Both times I encountered thie error I called MS PSS because it was a production database. The first time, a 'repair' worked. The second time, it was restore the last known good backup and apply transactuion logs.

But you say that it has happened in the past (it sounds recent) maybe you have some underlying hardware issues relating to disk ? Have you checked the System and Application event logs ? The SQL Server errorlog ? If you are on a SAN, have you contacted your SAN admin to check things out there ? I ask specifically because when this happened to me it was caused by disk related hardware issues.

RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."

Dave Foster SSC Veteran Points: 235 More actions · Answer 2

Good point, disk issues have usually been the case in my experience as well. In the past replacing the disk will prevent the problem from reoccuring, but will not repair the damage. I do have a good backup, but the db is aboutr 50 GB. I would rather not have to restore. As I said before, I have had success recreating the database table structure and using the DTS wizard to transfer data, then applying the indexes. That always takes up quite a bit of time as well. I was hoping someone had a 'silver bullet quick fix'.

Thanks for your reply, it appears I may have to restore.

John Langston SSCommitted Points: 1977 More actions · Answer 3

Are there messages in the system event log that might be the hint of a hardware issue? It might be worth a look.

Dave -310292 SSC-Addicted Points: 440 More actions · Answer 4

No messages in the event log. I decided to DTS into a new database which seems to be my only option on this. The database is back up and running, and the Checkdb comes back fine. Thanks