purge jobs expand log database

[Simon_Nomis]

Hello everyone,

I'm facing a strange issue on our ePO 5.10 Update 3 server (updated from 5.3 at February this year).

We've set up automatic jobs for "purge audit log" and "purge server task log" (also for the other purge jobs), running twice per month. The job is running without errors. The big thing is, it blows up the epo log database with around 4-5 GB each run...

ePO-Server: Win 2016

SQL: Win2008R2 with MS SQL2014

Shrinking the database on the SQL-Server helps but running the purge jobs will everytime bring the disk space to its limit.

Is there a known issue for this or an explanation, why jobs for "saving" disk space will do the opposite?

Thanks in advance

Simon 

[cdinet]

By default, epo creates the events database in full recovery mode.  See KB91176 (support.mcafee.com).  Regular backups of the transaction log need to occur in full recovery mode, which is sometimes every 15-30 minutes, depending on how busy your database is by the number of clients you are managing.  Check the main epo database recovery model also, whether it is in simple or full recovery mode. 

[Simon_Nomis]

Hello cdinet,

sorry for the late respones, and thanks for your answer.

I've checked the SQL settings for the events database:

Recovery type: full

backup type:    full

Actually we are running an environment with around 360 clients and servers.

Would you recommand to change recovery and backup type? And if so, should the epo Server be stopped (or just the Services) before changing the settings?

Kind regards and thanks in advance

Simon 

[cdinet]

Recovery type should be simple for both databases and backup full for both databases.  You don't need to restart any services.  Just have it backed up as a precaution before making any changes.  KB67184 is our kb for recommended maintenance for the database. 

[Simon_Nomis]

Hello cdinet,

changing the recovery model to simple didn't solve the problem. The database grew endless like before. I've determined that the dbo.OrionSchedulerTaskLog and  dbo.OrionSchedulerTaskLogDetail tables are concerned.
 
The only way which works for the moment is to remove the data with SQL-Query:
 
TRUNCATE TABLE dbo.OrionSchedulerTaskLog; 

After cleaning the tables I was able to run the cleanup job again. First the table had around 500KB, after ePO-server-task-cleanup-job it grew to around 4.5GB!?
I really would appreciate a solution to this behavior of ePO.
Could there be an incorrect Setting on our ePO-server?

Regards
Simon

[cdinet]

Are you running protection workspace extension?  If so, throttle the automatic response for it that runs too frequently.  You should also upgrade it to the latest, as it was changed to remove the automatic response rules and use an internal server task instead to avoid this.

[Simon_Nomis]

Hello cdinet,

we are not using protection workspace or McAfee MVISION. We have only ePO and VSE + VSE for storage and some of their extensions installed.

Regards

Simon

[cdinet]

If you look at the server task log entries, what are the bulk of the entries?  If you determine source of all the log entries, then maybe we can stop the source.