Recently I had a customer that had a runaway data increase of their Activity Pointer Base table. It would grow about 4-5GB each weekend. We looked for the usual suspects such as inline images, amount of email being sent on the weekend, and nothing really seemed to stick out. I started doing email counts and noticed that the training environment wasn’t even receiving or sending email on the weekends, but was still showing growing storage usage. This led us to believe that there was an index at work here. I searched online and this was suggested by others, but no one could figure out why their index was growing out of control. We needed a method for taming runaway growth of Activity Pointer Base Table data, and so we went to the source…
Indexes and Descriptions
We opened a case with Microsoft I found out that if you put a Description field for an Activity into a column view you can get this very situation to happen. Each time that ndx_ ATuneActivityTypeCode index runs it will grab the full body of the Email messages and include that in the index, every week.
So, the way to fix this is first look at any Activity views and remove the description field from any view columns. Email is affected by this the most. Then you will need to open a case with Microsoft letting them know you found Description fields in your view columns. and they will need to run a mitigation script against the ndx_ ATuneActivityTypeCode index. ()
