I will be as detailed as possible.
We have a high OLTP Publisher (SQL 2005 Ent.) publishing to 5 subscribers (SQL 2005 Std.). The DB on one of the subscribers was 50GB more in size than other 4 DB's. After little bit of investigation found that one of the table alone which was 500MB in total
size on all other servers was 50.5GB on one. Rebuild the index fixed the issue and the size came back to 500MB.
We are noticing that the size of this table increasing on a daily basis. Comparing the PK & NCIX indexes we found under INDEX PROPERTIES-FRAGMENTATION the ghost rows which is 0 in all servers is 40,000,000 on the effected server.
- Trace 661 is not turned to ON
- sp_configure compare is same on all servers
- MSFT has a fix for 2005 SP1 which does not apply in our case (http://support.microsoft.com/kb/932115)
- There are more than 2-3 million changes every hour
- The table has 5 INT & one DATETIME columns i.e. no BLOB or VARCHAR(max) columns
- The clustered index on this table is on a INT column i.e. all the 5 servers have the same schema (Table,PK,NCIX, FillFactor etc).
Updated Information: after referring to "http://www.sqlskills.com/blogs/paul/post/inside-the-storage-engine-ghost-cleanup-in-depth.aspx"
Running update stats on the table does help in decreasing the number of ghost rows, however its temporary i.e. the rowcount reduces by 100K from 40 million and then remains there. I tried running update stats again and it reduced by another 100K however remains
at that number even after waiting for 30 minutes.
I will need to run update stats thousands of times to clear all the records which is not what i prefer. I also checked that auto update stats is enabled on the DB