Shrinking the ACTION_DEFS table?

(imported topic written by taltrade91)

Apologies if this has already been discussed, but what is the proper way to get the ACTION_DEFS table to shrink? Due to performance issues, we typically delete our actions that are older than 2 weeks, and that certainly helps BigFix run smoother. However, our DBAs say that the ACTION_DEFS table has consistently grown in size. I would have thought that deleting actions within BigFix would shrink the ACTION_DEFS table. Any help at all is appreciated!

(imported comment written by BenKus)

Hi taltrade,

Deleting actions in the console is very helpful for performance because the BES Console doesn’t load the info anymore, which saves load time and memory… However, the information isn’t deleted from the database because it might be needed later (what if someone wanted to see what happened on some BES Clients on specific times/days?)

It is true that the ACTION_DEFS table will grow indefinitely, but we don’t expect this will cause performance problems because the database should be able to handle the load in this table easily (the structure of the table makes it simple to exclude the deleted actions when loading without a significant performance penalty). We ahve some customers that have been running with 150,000+ agents for 3+ years and we have never cleared these tables (even though there are tens of millions of entries)…

If you are having performance issues, it is probably from other areas… Perhaps you can consider our Remote Optimization Service: and one of our engineers will look through your system and help it perform better.


(imported comment written by taltrade91)

It’s not so much a performance issue now. Our DBAs simply want to cut back on the size of this ever-growing database for diskspace reasons. Nonetheless, thank-you for the explanation; it’s much appreciated. I will see if we can’t just add some more drives.

(imported comment written by jessewk)

Hi taltrade,

Even on the largest deployments most BigFix Databases will not be more than a few GB. I think the largest I’ve ever seen is 30 GB (over 200,000 endpoints).

The key is that you should make sure your transaction log is set to simple: