How can we help you today? How can we help you today?
rcinator
Activity overview Badges (0) Posts (0) Comments (3)

Activity overview

Latest activity by rcinator

This is blatantly false information. Both WMI and Performance counters can be used without administrator permissions just by adjusting Group Policy or Local Security Policy settings. Administrator accounts are almost never needed to access this type of information if you configure things correctly. Here is the information for how to do so for WMI: http://technet.microsoft.com/en-us/libr ... 71551.aspx Here is the information for Performance Counters: http://technet.microsoft.com/en-us/libr ... 49115.aspx / comments
  1. Community
  2. SQL Monitor Previous Versions
  3. Trimming monitor service account permissions...
This is blatantly false information. Both WMI and Performance counters can be used without administrator permissions just by adjusting Group Policy or Local Security Policy settings. Administrato...
0 votes
You're not getting it, Chris. It doesn't matter one lick if your tool is responsive if it is causing issues in the databases it was intended to monitor. The fact that you are DEFENDING your product having deadlocks has made me reconsider the product entirely. You've lost a customer today. / comments
  1. Community
  2. SQL Monitor Previous Versions
  3. SQL Monitoring creating deadlocks
You're not getting it, Chris. It doesn't matter one lick if your tool is responsive if it is causing issues in the databases it was intended to monitor. The fact that you are DEFENDING your produc...
0 votes
Chris, we have the same issue, and frankly, I think you have misunderstood the role of your product. It's a monitoring tool. It should be as free of side-effects as possible, but instead, it is generating deadlocks in what is effectively a shared resource (tempdb). Those deadlocks are bleeding over into non-SQLMonitor databases because of the tempdb contention. On our production instances, the deadlocks caused by SQL Monitor managed to cripple our servers and we had to disable monitoring of those servers. Our customers noticed. We got a lot of egg on our faces. Frankly, it's a monitoring tool. Me having to wait a few extra seconds (or even minutes) for us to know what our top queries are isn't going to cause any issues. Not getting a graph updated in precise realtime isn't going to cause any issues. You guys have prioritized the wrong features. I don't care nearly as much about your UI or your product being 100% realtime as I care about your product not interfering with my databases and my applications and my servers. Your product is by far the least important database on my server as far as I am concerned. It doesn't make me any money and isn't directly related to supporting my customers as long as everything is running smoothly. It should know its place and avoid impacting anything else on the server at all costs, even at the cost of the speed and responsiveness of your tool. I have currently had to uninstall the monitoring from our production instances because it flat out broke our servers. Even on heavily loaded servers, that should never be necessary. At the very least, allow us to disable the "high overhead" things on production instances. I only care about those things as a forensic tool anyway. For production, I just want to be made aware of space issues, deadlocks, and critical items and that's it - I only look at top queries on a periodic basis, and frankly don't consider them to be things that SHOULD be alerted on. / comments
  1. Community
  2. SQL Monitor Previous Versions
  3. SQL Monitoring creating deadlocks
Chris, we have the same issue, and frankly, I think you have misunderstood the role of your product. It's a monitoring tool. It should be as free of side-effects as possible, but instead, it is ge...
0 votes
Total activity
5
Last activity
Member since
Following
0 users
Followed by
0 users
Votes
0
Subscriptions
2