I have run into several customer databases that were very large, even though they did not have a tremendous amount of data. One of the common things that I see is a bloated INDEXUPDATES table. The INDEXUPATES table stores all changes to tables that are indexed for SpeedSearch. Incremental index schedules use this information to only update records in an index that have changed. The entire table can be deleted if you run a full index build, since incremental changes are no longer necessary.
It seems like SalesLogix could have designed something that would automatically delete entries when Full Indexes are run. Not a very efficient procedure, making customers remember to periodically manually truncate it.
In one recent database, I found this table had over 8 million rows and was occupying almost 4GB of space. The overall size of the client’s database after clearing this table went from +7GB down to under 3GB.
So if your database seems too big, check to see if this table is the culprit.
Excellent article! I just found a client with 54 million records in INDEXUPDATES.
Working on this now for our old old old SLX server. 246 million rows….200+ GB in size.