Final update: I've identified that the version_ghost_record_count values are increasing in all tables in all databases on the SQL Server instance, not just the table with the XML data. ...

I have now confirmed that this is a ghost record cleanup issue. Running a select on sys.dm_db_index_physical_stats for that object returns over 1 million version_ghost_records associated with the...

Update: I can reproduce this with READ_COMMITTED_SNAPSHOT turned ON, but not with it OFF.

The results are inconsistent; sometimes it goes up and never goes down... other times it seems...

ALTER INDEX PK_BadTable ON BadSchema.BadTable REBUILD;

The command completed successfully.

The size of the data is unchanged. (Currently 66MB)

Quick update.

After switching out the table for a newly created one (double-checked the clustered index), the initial size was 3MB but it has been growing since then and is now...

Good question! I already switched the table out in production but I should be able to restore a backup and try...

Just a heads up, I followed your advice despite my assertion that the table is not a heap, and the size is now 3 MB.

I am continuing to investigate this...

More evidence that it is not a heap

SELECT * FROM sys.indexes WHERE object_id = OBJECT_ID(N'BadSchema.BadTable');

object_idnameindex_idtypetype_descis_uniquedata_space_idignore_dup_keyis_primary_keyis_unique_constraintfill_factoris_paddedis_disabledis_hypotheticalallow_row_locksallow_page_lockshas_filterfilter_definition

981578535PK_BadTable11CLUSTERED110100000110NULL

981578535AK1_BadTable22NONCLUSTERED110100000110NULL

Eirikur Eiriksson (4/30/2014)

---

SQLdude412 (4/30/2014)

---

Thanks for your...

Thanks for your reply.

The value returned...

Lowell (4/30/2014)

---

my first guess: the table is a heap, and does not have a clustered index.

in the case of a heap, if you update data, or delete and reinsert individual...