Options
I need SQL Server to monitor SQL Server?
BrandonGalderisi
Posts: 22
This is an email I sent in for support but have yet to receive a response, so I figured it was time to post in the forums:
We originally purchased SQL Response and I am currently testing SQL Monitor for a possible upgrade. My question is this.
SQL Monitor uses SQL Server for a storage engine. I obviously don’t want the storage for my monitoring on a monitored server because if that server goes down I lose monitoring. Which means I need a SQL Server license in order to monitor my SQL Servers. SQL Server Express doesn’t work well because of the DB size limitation. While tracking down performance related issues I had trace running for a few days. This filled the DB to 10GB and SQL Monitor stopped responding. There doesn’t seem to be a way to control the retention of just trace data which meant that I had to, painfully, drop the purge date down to 1 day and wait before things would start working. I say painfully because I couldn’t disable trace, change maintenance, or do anything because the base monitor service was spiking CPU/MEMORY, probably due to the DB being full.
I think you need to take a step back and evaluate your storage solution (possibly doing a DB per server option and DB per trace option) and give more granular control over trace data. This will keep people from having to spend thousands of dollars on a SQL Server license just to monitor servers. We chose your solution because of the cost, but this makes it cost prohibitive to upgrade.
Brandon
We originally purchased SQL Response and I am currently testing SQL Monitor for a possible upgrade. My question is this.
SQL Monitor uses SQL Server for a storage engine. I obviously don’t want the storage for my monitoring on a monitored server because if that server goes down I lose monitoring. Which means I need a SQL Server license in order to monitor my SQL Servers. SQL Server Express doesn’t work well because of the DB size limitation. While tracking down performance related issues I had trace running for a few days. This filled the DB to 10GB and SQL Monitor stopped responding. There doesn’t seem to be a way to control the retention of just trace data which meant that I had to, painfully, drop the purge date down to 1 day and wait before things would start working. I say painfully because I couldn’t disable trace, change maintenance, or do anything because the base monitor service was spiking CPU/MEMORY, probably due to the DB being full.
I think you need to take a step back and evaluate your storage solution (possibly doing a DB per server option and DB per trace option) and give more granular control over trace data. This will keep people from having to spend thousands of dollars on a SQL Server license just to monitor servers. We chose your solution because of the cost, but this makes it cost prohibitive to upgrade.
Brandon
Comments
We’re currently working on the v2.3 release of SQL Monitor, and one of the features we’ll be adding is more control over the purge windows. Specifically, there will be a separate purge window for trace data, independent of the purge window for alerts. I’m hoping this will go some way to alleviate the problems you’re having. (Of course, the usual weasel words apply – until the release is out of the door I can’t promise this feature will happen in v2.3, but I’m not anticipating any problems.)
We’re also in the planning stages for SQL Monitor v3, and it’s likely that more sophisticated storage and purging options will be a part of that release. Your suggestion to span the storage across multiple databases is certainly a solution we’ll consider.
Redgate Software
Thanks for your post. We have internally already implemented different purge options for "Window and SQL Process", "Trace" etc. This is under test now. This will be released as part of 2.3 release.
We are hoping to release 2.3 before end of May. Please feel free to contact us if you have any more questions.
Regards,
Priya
Project Manager
Red Gate Software