There is an issue where your SQL server hosting the OperationsManager database might consume large amounts of CPU for extended periods.
This is due to a security cache issue when a non-sysadmin creates a heavy workload on a TempDB database. Read more about this on the support team blog:
This SQL issue was first fixed in SQL Server 2008 R2 Cumulative Update 5 (CU5):
Thanks again Kevin for a great post,
We are about to install SCOM 2007 R2 CU4 and then upgrade to SQL 2008 R2 (currently on SQL 2008 SP2).
We could not do an inplace upgrade from SQL 2008 SP2 to SQL 2008 R2 when running SCOM 2007 R2 CU3 as the pre-requisit failed. We then saw a post of ours that said this upgrade failure should be resolved in SCOM 2007 R2 CU4
Thanks for the above, info your blog on SCOM is one of the very best on the internet
Thank you a lot for that info. I can really recommend this update. Our OpsMgr DB is running on a server with 16 cores, so it was never max out but it was running with an average of 10% - after we applied the CU5 it dropped to and average of 5%...so that is really nice.