But if you have some problem preventing partitioning and grooming, you should get more details fast, so:
- Open SQL Server Management Studio with sufficient permissions to run a Stored Procedure against the OpsMgr database, connent to the instance that holds the OpsMgr database.
- Right-click the OpsMgr database > New Query. Type:
- Hit F5 to run this Stored Procedure.
- Within a few minutes you will se the result under Messages. If you see any errors you will probably be closer to understand what to fix...
More on this monitor on MPWiki:
For a more detailed explanation on the Partitioning an grooming process, take a look at Kevin Holmans blog on the topic: OpsMgr 2012 – Grooming deep dive in the OperationsManager database
In short he recommends:
If you ever have a problem with grooming - or need to get your OpsDB database size under control - simply reduce the data retention days, in the console, under Administration, Settings, Database Grooming. To start with - I recommend setting all these to just 2 days, from the default of 7. This keeps your OpsDB under control until you have time to tune all the noise from the MP's you import. So just reduce this number, then open up query analyzer, and execute EXEC p_PartitioningAndGrooming When it is done, check the job status by executing select * from InternalJobHistory order by InternalJobHistoryId DESC The last groom job should be present, and successful. The OpsDB size should be smaller, with more free space. And to validate, you can always run my large table query, found at: Useful Operations Manager 2007 SQL queries
Also, another recommendation from Scom Skills:
Check the size of the Operational Database transaction log free space, and ensure the file is large enough to handle not only regular grooming without issue, but a significant alert storm as a buffer insurance. It doesn't hurt anything to have a transaction log sized up to 50% of your operational database :)