OpsMgr 2012 – Grooming deep dive in the OperationsManager database
<!--[if lt IE 9]>
<![endif]-->
Comments
Anonymous
January 01, 2003
@Jazeel Ahmed Siddiqui -
No - as evidenced in this blog post - the log shows that it runs at 5 or 6am which is UTC time in the database, but the workflow is called based on local time of the management server.- Anonymous
July 16, 2016
Thanks Kevin for your reply. i forgot that i have asked you a question 2 years back :) Any how i was checking the InternalJobHistory table and found two grooming failures in last 59 days record. How can i find out which exactly cause this failure?- Anonymous
July 18, 2016
If you only have two and they aren't current - I'd ignore it. Could be the server was rebooted, could be a space issue, hard to tell.I'd go back and look at the system and app event logs, and look for alerts around that time frame.
- Anonymous
- Anonymous
Anonymous
January 01, 2003
Question on the GroomingRunTime column.In my enviorment I see all of the objects returned with a date in the GroomingRunTime from the command:select * from dbo.PartitionAndGroomingSettingsare within the last 24 hours except for "MonitoringJobStatus" which shows almost 2 weeks ago, and hte DataGroomedMaxTime is ~7 days before that.I manually ran "EXEC p_PartitioningAndGrooming" and this did not increment the MonitoringJobStatus object's GrromingRunTime. I do believe we have some StateChange cleanup that is badly needed as per your entry http://blogs.technet.com/kevinholman/archive/2009/12/21/tuning-tip-do-you-have-monitors-constantly-flip-flopping.aspx, but can you think of why this one job doesn't seem to want to run?Anonymous
October 10, 2013
Kevin, excellent article thank you!Anonymous
February 06, 2014
Hi Kevin, I would like to know what are all the accounts used for Grooming the DB and DW in Opsmgr? Regards, SriniAnonymous
March 25, 2014
Hi Kevin
U R always the Best in SCOM ...Anonymous
May 30, 2014
We had an issue where an alert storm caused our OperationsManager database to run out of space, which at the same time caused the grooming task to fail (or not run at all at its scheduled time). Days later, we found the database ran out of space again due to the grooming task failing to run. Using the information here, I found that the p_PendingSdkDataSourceGrooming sproc was failing. The cause was this internal table is set to be groomed every day. Attempting to run the grooming task for this table with 5 days of data caused our transaction log to fill up (it got up to 10 GB from 3 GB!). Checking the amount of rows in the table PendingSdkDataSource showed about ~33k rows. Manually adjusting the DaysToKeep value in the table PartitionAndGroomingSettings for PendingSdkDataSource to a higher value (starting at the day of the oldest data = 6) and working our way back down to 1, running the p_PendingSdkDataSourceGrooming sproc each time ran successfully without filling up the transaction log. Once we got the command to work at a setting of 1, running the p_PartitioningAndGrooming sproc finally ran successfully.
Thank you for this blog entry and a special thanks to our awesome MSFT DBA Cris B.Anonymous
July 17, 2014
Dear Kevin,
Grooming is called once per day at 12:00am. Is this the UTC time?Anonymous
January 06, 2016
Hello Kevin,
if I changed operational manager database default grooming setting, how its work any back end job to understand this.Anonymous
May 03, 2016
Hi Kevin,I am seeing around 10 million of records in the MaintenanceMode table in DW DB. Can someone please let me know how the grooming of this table happens/What is the retention period of this data.How can I manually groom this data manually? Appreciate your help regarding this. Thanks you.Anonymous
July 15, 2016
Thanks Kevin for your reply. i forgot that i have asked you a question 2 years back :) Any how i was checking the InternalJobHistory table and found two grooming failures in last 59 days record. Can i find out which can cause this failure?