Generally the tables that grow quickly are the event tables threat and client (not sure if they're 2 tables or 1 generic table).
If you've got ePO 4.6 then there's a handy downloadable dashboard https://community.mcafee.com/docs/DOC-2995 that will give you an insight to where the events are comming from.
You can then purge them and maybe lower the logging level to prevent them accumulating again.
Thanks for linking this new dashboard.
Thank you for this dashboard. It helped me track down 82,000,000 events that could be purged from our DB.
Out of Interest what were the events ?
One of the processes running on our servers was violating the "Prevent termination of McAfee processes" access protection rule. A lot. Like multiple times per second on all our servers. Somehow this all slipped past my event monitoring dashboard.
We adjusted the AP rule to allow this particular process through since it doesn't actually terminate McAfee's processes and our SQL guys worked some DB magic to delete the garbage data.
Deleting all 82 million events through the ePO console was a very bad plan. The DB guys tell me that it looks like each line of the table was getting deleted one at a time. So that's one SQL query sent from ePO to the SQL server for every row. It severely impacted performance on our SQL cluster. The DB admin was able to delete 10,000 rows at a time, dramatically faster than the ePO console sending individual queries.
The DB guys tell me that it looks like each line of the table was getting deleted one at a time. So that's one SQL query sent from ePO to the SQL server for every row.
Just for accuracy, that's not strictly correct: ePO effectively sends one query to SQL, saying "delete all events of type x that are older than date y" (depending on how you have the task configured), and then SQL decides how to do this. Because we're deleting records based on criteria - such as event type and date - rather than simply saying "delete everything in the table in one go" - then SQL has no option but to delete each record one at a time. Because of the way that SQL works this means that you get one entry in the transaction log for each row deleted, which can make the transaction log very large if you're deleting a huge number of events.
Whilst strictly speaking this is an SQL issue, I believe we're looking at ways of improving the performance of large event deletes in future versions of ePO.