Timeline for Two corrupted indexes found by DBCC CheckTable
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 12, 2013 at 20:19 | comment | added | Remus Rusanu | @JonSeigel: yes, you are right. Rebuild will use the same index as source and will keep the corruption, since is a cross key issue. Aushin, try drop and create... | |
| Mar 12, 2013 at 18:38 | comment | added | Aushin | Yes the issue returned shortly after. I have our sysops people running diagnostics on the (possibly) faulty hardware, tickets open with the IO Vendor, and, just in case, a ticket with Microsoft. | |
| Mar 12, 2013 at 17:06 | comment | added | Jon Seigel | In my (admittedly limited) experience with corruption, I've always had to drop and recreate nonclustered indexes, as the rebuild plan uses an index scan (of the corrupt index) because it's cheaper than scanning the base table -- the corruption has always remained every time I've tried this. | |
| Mar 12, 2013 at 16:32 | history | migrated | from stackoverflow.com (revisions) | ||
| Mar 12, 2013 at 14:37 | vote | accept | Aushin | ||
| Mar 12, 2013 at 14:33 | history | answered | Remus Rusanu | CC BY-SA 3.0 |