I'm guessing that your ePOEvents table is the one that is rather large, is that correct? If so, take a look at the following KB articles in the system for assistance on purging that table. NOTE: The article is specific to ePO 4.0 but it also should work for ePO 4.5 too. The ePO service names piece is really the only thing different there. This process can be done for other larger tables too.
The article in question is KB51873.
I would recommend to skip step #6 in KB51873 and refer to the section titled "Shrink Database and why it is NOT recommended:" in KB67184 as to the reason for skipping that step.
John, thank you for the information and for your time. We had already read the first KB article you linked to and I've suggested to our DBA that we use the OSQL commands as recommended.
According to the second linked KB article it seems that the main reason not to shrink the database doesn't really apply if you're deleting massive amounts of data like we propose to do. I'll post back our solution once we've looked at this some more.
1 of 1 people found this helpful
You can't use the TRUNCATE command on the ePOevents table because there are constraints on it. You could either drop the constraints, truncate the table, and then recreate the constraints, which would be the preferred approach if the table was truly enormous: alternatively, you can simply do "DELETE FROM ePOevents" which will take longer, but will have the same effect and will work within the constraints. (Note that this option will cause the transaction log to grow during the course of the delete, but it will correct itself when the process is over.)
Whichever you choose, both of these procedures should be performed with the ePO services stopped.
Just an update to close this thread;
We finally just ran numerous Purge Threat Event tasks from the ePO console's Server Tasks, doing older than 12 months, then another older than 11 months and so on until it was cleared right down. The purges took a long time to run but we've cleared the database down to a manageable level again and confirmed that the adjusted filtering is doing as intended. The database is growing at a much more reasonable level now and I've configured scheduled purges to run daily that removes anything over 6 months old.
Thanks again Joe