OpsMgr 2012 – Grooming deep dive in the OperationsManager database


<!--[if lt IE 9]>

<![endif]-->

Comments (12)
  1. Kevin Holman says:

    @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.

    1. Jazeel Ahmed says:

      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?

      1. Kevin Holman says:

        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.

  2. Anonymous says:

    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.PartitionAndGroomingSettings
    are 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?

  3. Andrew says:

    Kevin, excellent article thank you!

  4. Srini says:

    Hi Kevin, I would like to know what are all the accounts used for Grooming the DB and DW in Opsmgr? Regards, Srini

  5. Hossein Afshar says:

    Hi Kevin
    U R always the Best in SCOM …

  6. David Morgan says:

    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.

  7. Jazeel Ahmed Siddiqui says:

    Dear Kevin,

    Grooming is called once per day at 12:00am. Is this the UTC time?

  8. Hello Kevin,
    if I changed operational manager database default grooming setting, how its work any back end job to understand this.

  9. Ajeet says:

    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.

  10. Jazeel Ahmed says:

    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?

Comments are closed.

Skip to main content