Ok, I'm confused!
I have a table called CREDITORS. This Table has a Primary Key with a NONCLUSTERED INDEX on CRED_ID. This means that there is only 1 Index on the Table.
If I execute this command; DBCC SHOWCONTIG (CREDITORS)
I get fragmentation info for an IndexID of 0. What is this Index? There is only 1 Index on the Table and it has an IndexID of 2 which happens to be the NONCLUSTERED INDEX in the Primary Key for CRED_ID.
If I execute this command, I get the correct fragmentation info for the Index CREDITORS_PK which is the NONCLUSTERED INDEX in the Primary Key for CRED_ID.
Can someone please explain?
It's a little buried in BOL for DBCC SHOWCONTIG, but Index ID 0 refers to a heap table, i.e., one without a clustered index.
A given table will always have one entry in sysindexes for either IndID = 0 or IndID = 1. Of course, it can have other entries for every non-clustered index as well.
so therefore, there really is 2 Indexes to this table? 1 for the Heap and 1 for the Primary Key(NONCLUSTERED INDEX)?
Having said that, if the heap Index is fragmented, do you defrag it like you would with a normal Index?
It is not accurate to say that the table has two indexes in this case. Unlike a table with a clustered index (IndID = 1) which is well-ordered based on the index key, a heap table has no logical order. It is simply a conglomeration of data. Your table has just one index -- the non-clustered one you created.
As such, for a heap table there is no concept of defragmenting the table. The standard methods of DBCC INDEXDEFRAG and such do not work.
There can be issues with heap tables, see for example, Kalen Delaney's explanation at http://www.windowsitpro.com/SQLServer/Articles/ArticleID/25198/pg/2/2.html. My understanding is that the only way to compact a heap table is to either reload it (move data out, truncate, move back in ) or to shrink the database itself. I may have missed a method or two here, however.
See if this helps: