Don Ferguson
My feedback
10 results found
-
5 votesDon Ferguson
shared this idea
·
-
5 votesDon Ferguson
shared this idea
·
-
4 votesDon Ferguson
shared this idea
·
-
4 votes
An error occurred while saving the comment Don Ferguson
supported this idea
·
-
70 votes
Daniel Rothig
responded
Thanks Phil – we are considering reworking the upgrade process. If this suggestions gains more traction, we’ll prioritise it higher
Don Ferguson
supported this idea
·
-
60 votes
An error occurred while saving the comment Don Ferguson
commented
Now that that a separate web server install requires domain credentials in order to connect to the base monitor's database, this is really needed.
To make matters worse, an upgrade to the web host just reinstalls replacing domain credentials with local account and it doesn't even prompt for domain credentials in the web host upgrade process. Must be done post upgrade each and every time.
Also, please stop wiping out the base monitor configuration with the upgrade. It should leave that alone, especially since multiple base monitor installs are now available.
Don Ferguson
supported this idea
·
-
29 votes
An error occurred while saving the comment Don Ferguson
commented
For those of us who have many monitors, updating to latest version is a time consuming chore. It would most definitely be nice to have a way to speed up the upgrade process.
Don Ferguson
supported this idea
·
-
1 voteDaniel Rothig
responded
Hi, we’re monitoring a few of those out of the box and the rest can be covered via the custom metrics feature – check out sys.dm_os_performance_counters
Don Ferguson
shared this idea
·
-
6 votesDon Ferguson
shared this idea
·
-
172 votes
currently under investigation
An error occurred while saving the comment Don Ferguson
commented
Thanks for the additional instructions. I now see that some of the alerts can be configured at the database level. Unfortunately the alerts that I am getting flooded with are not on that list. If I could suppress blocking, deadlocks, & long running queries at a database level, that would be more helpful.
An error occurred while saving the comment Don Ferguson
commented
Thanks Priya, being able to suppress an alert at the database level would help. Unfortunately, I am not seeing this option. I do see the option to suppress at the instance level, but not at the database level. What am I missing?
An error occurred while saving the comment Don Ferguson
commented
Being new to SQL Monitor I am finding it very difficult to suppress the noise over the alerts that I really want to get. It would be nice to be able to suppress specific alerts without affecting the settings for other alerts of the same type that might occur elseware.
While there are instance level options for alert suppression, I would like to see a finer level of control of reccurring alerts. I would suggest that any alert should be able to be excluded based on any combination of instance, database, application, userid, specific query, time of day, etc.
Don Ferguson
supported this idea
·
An error occurred while saving the comment Don Ferguson
commented
Thanks Priya, specifically I am referring to the sql_handle column in the sys.dm_exec_query_stats DMV.
An error occurred while saving the comment Don Ferguson
commented
Too many established long running queries show up as as long running query alerts. Should be able to customize the alert thresholds for specific queries based on their query hash available in the sys.dm_exec_query_stats DMV.
This would be very useful. It seems that active queries are not captured in the Server Overview page until they are complete. Adding detail such as query and execution plan of active long running queries during any time slice it's running (similar to what sp_whoisactive @get_plans=1 captures, http://whoisactive.com/) on this page would improve this tool dramatically.