Tuesday, August 07, 2012 1:17 AM
My DBA is complaining that there is too much polling from SCOM to his database. He mentioned that every second there are 5 to 6 request per second. Is there a way to reduce SCOM polling interval? If so where is the place to change it?
Tuesday, August 07, 2012 6:19 AMModerator
SCOM doesn't poll - SCOM Management Servers sends data continuously to both databases. Alert data and state data is then synchronised every 3 minutes.
SCOM should have its own SQL Servers and if you have virtualised these then you should take care as to placement with other guests so as not to have resource contention. Disk IO is key here.
Tuesday, August 07, 2012 6:45 AM
Tuesday, August 07, 2012 6:54 AMModerator
I don't understand what your DBA is complaining about. This is the way SCOM works. It collects data. It writes it to the databases. It might well be that SQL is not configured well or that the underlying Disk I\O is too high for the underlying storage.
These links might help:
A collection of a few blogs that look at hardware requirements and SQL IOPS:
For performance reasons, I'd move the RMS away from SQL but if your users are happy with performance of the console \ notifications then SCOM is working fine.
Are both OperationsManager databases on the same SQL Server that are with the RMS?
How to move the databases is listed here:
And some real world guidance here:
Tuesday, August 07, 2012 7:09 AM
Yes, my Operational manager database is also on the same physical server. All my SCOM components expect for agents are in the same physical server.
For the time being, we have to look for a work around. My question who be how to reduce this? Will monitoring less servers help ?
Anyway, that server is using 3.8G/4.0GB and I agree that disk I/O is high.
Tuesday, August 07, 2012 8:27 AMModerator
How many agents do you have? With only 4 GB of RAM and having SQL and RMS on the server then there will be performance issues.
If you can't increase the specification of the server or move the components to seperate servers then your only option is really to monitor less:
- remove agents you don't need to monitor
- remove management packs that you don't need
But I suspect that the server you have will always struggle. As you mention the RMS, I assume you are on SCOM 2007 R2 (rather than 2012) so the sizing guide might help:
Deployment Scenarios - http://technet.microsoft.com/en-us/library/bb735402
Tuesday, August 07, 2012 7:56 PM
Tuesday, August 07, 2012 8:00 PMModerator
For that many agents you should be fine. I'm struggling to understand your DBAs concerns - SCOM is functioning as it should.
1) Is the SQL Server \ RMS virtualised or a physical server?
2) Are there any other databases (other than the SCOM databases) on the SQL Server?
3) What is the problem with the RMS writing to the database?
If you want to reduce Disk IO then you can either remove the agents or remove the management packs but you are monitoring so little, I suspect that it won't have much affect unless you have some custom monitoring that is generating excessive data.
Tuesday, August 07, 2012 9:02 PM
Tuesday, August 07, 2012 10:01 PMModerator