1 of 1 people found this helpful
If the cause is a surfeit of events, then you will need to purge some, ePO has tasks for that process.
If, however it's because the DB transaction log is growing then some separate Sql maintenance is required.
You don't mention which version of ePO, however the ePO 4.5 Product guide has a section for regular maintenance:
Perform regular maintenance of SQL Server databases
Simple recovery mode is recommended because the transaction log is not essential in simple recovery mode and does not swell during backup. If you have multiple databases with different recovery models, you can create separate database maintenance plans for each recovery model. In this way you can include a step to back up your transaction logs only on the databases that do not use the simple recovery mode. In simple recovery, once a checkpoint is complete, the transaction logs for the time before the checkpoint are dropped from the active database. A checkpoint automatically occurs when the backup is made. We recommend having a database maintenance plan that performs a backup of the ePO database, together with "Simple Recovery." In this way, once a backup is successfully created, the portion of the transaction log in the active database is dropped; it is no longer needed because a backup file exists.
Ensure that the recovery model is set to simple. See the SQL documentation for information on simple recovery. If you choose not to use simple recovery, you need to regularly back up the transaction log.
Backup and restore ePolicy Orchestrator databases
McAfee recommends that you back up ePolicy Orchestrator databases regularly to protect your data and guard against hardware and software failure. If you ever need to reinstall the server, you might need to restore from a backup.
How often you back up depends on how much of your data you are willing to risk. Some possible approaches include:
• Back up your database at least once a week.
• If you have made many changes to your deployment, you might want to back up daily.
• To mitigate bandwidth demands during regular business hours, you might schedule automated nightly backups.
• To further balance the load, you might perform incremental daily or nightly backups, and a full weekly backup each week.
Save the backup copy to a different server than the one hosting your live database. If your database server crashes, you don’t want to lose your backup too.
Performing regular backups provides the ability to restore your database if that should ever become necessary because of software or hardware failure, or because of an upgrade to server or database server hardware.
For information on backing up and restoring your SQL database, see:
• Microsoft documentation for the management tool appropriate for the database you are using.
• McAfee KnowledgeBase article KB52126.
We had never setup a purge task in the past...
We now have an Event Log that increases by 80,000+ events every day, with a total of 8.8million records (according to our DB guys).
Is there an easier way of purging these events without going through ePO?
Just for info, we are using 4.0.
1 of 1 people found this helpful
Yes it's definitely possible to script this directly against the DB, but it's debatable that this is easier. (Quicker perhaps).
Anyway, please bear in mind that such Sql scripts are executed entirely at your own risk whereas purging through the ePO console is supportable.
Normally McAfee support would only suggest directly deleting data from the ePO DB after a support call has been opened, the correct data to be purged and scripting method has been identified and 'normal' methods are not deemed feasible. This will inevitably take some time i'm afraid.
80,000 events per day sounds an awful lot personally, unless perhaps you're managing 10,000+ machines. (Entirely feasible - ePO scales up 10x this and then some with the right hardware...)
As well as purging the data it would be good for you to look at what of events are being generated so this can be analysed.
Personally, it sounds like you should open a suport call if you have not already done so.
Identified the issue!
VMReporting on Access Protection Policy was enabled, causing our VCentre server to log this information 6 times every second...
Disabled this through policy so it is no longer growing.
Have setup a task to delete a weeks worth of logs every night at 2:00am... so should be back to normal in about 2 weeks!
Thanks for your help.
I'm glad you found the cause.