GilaMonster (1/2/2013)

---

opc.three (1/2/2013)

---

Are you thinking of reorganize?

No.

I thought a rebuild would re-scan the clustered same as a drop+recreate which would work since all inconsistencies were found in the nonclustered index.

Nope. A rebuild of a nonclustered index can read the old index to build the new (there are a number of options available). Far more efficient than reading the table (all the columns for the new index are present in the old one, and in the correct logical order), but it means that if there's corruption in the index rebuilding it will likely fail (or worse, preserve the corruption in the new index).

http://www.sqlskills.com/blogs/paul/teched-demo-nonclustered-index-corruption/

Rebuilding Indexes

Rebuilding an index drops and re-creates the index. This removes fragmentation, reclaims disk space by compacting the pages based on the specified or existing fill factor setting, and reorders the index rows in contiguous pages. When ALL is specified, all indexes on the table are dropped and rebuilt in a single transaction. FOREIGN KEY constraints do not have to be dropped in advance. When indexes with 128 extents or more are rebuilt, the Database Engine defers the actual page deallocations, and their associated locks, until after the transaction commits. For more information, see Dropping and Rebuilding Large Objects.

In earlier versions of SQL Server, you could sometimes rebuild a nonclustered index to correct inconsistencies caused by hardware failures. In SQL Server 2008, you may still be able to repair such inconsistencies between the index and the clustered index by rebuilding a nonclustered index offline. However, you cannot repair nonclustered index inconsistencies by rebuilding the index online, because the online rebuild mechanism will use the existing nonclustered index as the basis for the rebuild and thus persist the inconsistency. Rebuilding the index offline, by contrast, will force a scan of the clustered index (or heap) and so remove the inconsistency. As with earlier versions, we recommend recovering from inconsistencies by restoring the affected data from a backup; however, you may be able to repair the index inconsistencies by rebuilding the nonclustered index offline. For more information, see DBCC CHECKDB (Transact-SQL).