locked
Looking for best way to monitor SQL Servers with more than 50 DB each RRS feed

  • Question

  • I was hoping someone could point me to a resource with recommendations on monitoring through SCOM 2012 some SQL Servers that have more than the 50 Databases recommended for Best Practices in the SQL MP guide.  I am working with a group that has a few servers that have databses in the thousands, one with over 2500.  They need these servers monitored, but other than increasing the time between polling intervals and increasing the timeout interval, what else can be done?  When adding the "high cost" DEV server (1068 databases), it originally brought down DEV monitoring as there wasn't any discussion as to "this is a massive database server", so the DEV SCOM environment had to then be rebuilt.  Doing so again would be rather time consuming, so any steps I can take to limit that possibility is kind of awesome.

    the MP guide states:

    "We recommend that you monitor no more than 50 databases and 150 database files per agent to avoid spikes in CPU usage that may affect the performance of monitored computers."

    Thanks in advance for your help.


    • Edited by vyndel Monday, March 18, 2013 2:04 PM
    Monday, March 18, 2013 2:03 PM

Answers

  • The recommendation is just their bc the mp fires up scripts which use resources. it's not about the SCOM server side, it's about the "Monitored server" that might be impacted (an enumarate of 50 db's takes a lot less computing time than 1000+). Tuning of SQL discoveries and if possible monitors (timed scripts) to run less often will help with the impact on the monitored server.

    You say it brought down your dev SCOM environment, i can only think of (db) sizing issues (running into dbfile size or disklimits maybe). So make sure you SCOM environment is well sized.


    Rob Korving
    http://jama00.wordpress.com/

    • Marked as answer by Yog Li Tuesday, March 26, 2013 8:50 AM
    Monday, March 18, 2013 2:43 PM
  • Disk I/O is definitely important on the SCOM server side. Again good sizing is important.

    Dev environments tend to be on minimal resources and a vdisk on a shared san might just be not enough :) (the sizing helpers for scom also mention the SQL best practices, which for most environments is enough).


    Rob Korving
    http://jama00.wordpress.com/

    • Marked as answer by Yog Li Tuesday, March 26, 2013 8:50 AM
    Monday, March 18, 2013 3:54 PM

All replies

  • The recommendation is just their bc the mp fires up scripts which use resources. it's not about the SCOM server side, it's about the "Monitored server" that might be impacted (an enumarate of 50 db's takes a lot less computing time than 1000+). Tuning of SQL discoveries and if possible monitors (timed scripts) to run less often will help with the impact on the monitored server.

    You say it brought down your dev SCOM environment, i can only think of (db) sizing issues (running into dbfile size or disklimits maybe). So make sure you SCOM environment is well sized.


    Rob Korving
    http://jama00.wordpress.com/

    • Marked as answer by Yog Li Tuesday, March 26, 2013 8:50 AM
    Monday, March 18, 2013 2:43 PM
  • Thanks! It wouldn't surprise me if it was an I/O issue as well.  It brought things down hard, too. We tried to do a restore from backup for the DW and Operational Warehouse, but ended up having to rebuild as the server was added before a good backup was done.  This is why I am grateful for DEV environments.
    Monday, March 18, 2013 3:22 PM
  • Disk I/O is definitely important on the SCOM server side. Again good sizing is important.

    Dev environments tend to be on minimal resources and a vdisk on a shared san might just be not enough :) (the sizing helpers for scom also mention the SQL best practices, which for most environments is enough).


    Rob Korving
    http://jama00.wordpress.com/

    • Marked as answer by Yog Li Tuesday, March 26, 2013 8:50 AM
    Monday, March 18, 2013 3:54 PM