We do not support changing the execution time of grooming or purging.... That's why these were not exposed via override.
Partitioning and grooming is hard coded to 12:00am, and Purging happens two hours later at 2am. These are not designed to run at the same time. We partition, then we groom, then, we purge what was groomed. If you don't mess with these times, and either is failing, then I'd review the logs.... select * from InternalJobHistory order by InternalJobHistoryId DESC If these are failing, it is almost always a SQL performance issue, or a massive amount of data - meaning it is trying to groom/purge too much, because there is too much noise. From: [email protected] [mailto:[email protected]] On Behalf Of Gareth Miles Sent: Wednesday, May 24, 2017 7:29 AM To: [email protected] Subject: [msmom] SCOM DB locks at specific time Hi I'm getting massive locking on the OperationsManager DB at 02:00 local time. I have both the 'Discovery Data Grooming' and 'Partitioning and Grooming' set to run at 02:00. I've run both p_DataPurging and p_PartitioningAndGrooming manually and both run through successfully without any issues. I've attached the locking history from 00:00 this morning to 04:00. You can see the main locking starts at 02:01 with the proc p_AlertDataPurging. I don't see it listed in this post so I don't know if it's part of grooming or not? The PID 370 from p_AlertCreateProcess which runs a select from the Alert table and attempts to create the proc p_AlertCreateProcess This is the main lock for the period of the locking, until we shut down all management server services at 02:48. If you filter the column 'Query' in the spreadsheet on p_AlertCreateProcess you'll see what I mean. I've also run p_AlertGrooming, this runs in a few seconds without issue. Any help would be appreciated. Kind Regards Gareth Miles
