Stephen
My feedback
8 results found
-
176 votes
currently under investigation
An error occurred while saving the comment Stephen
supported this idea
·
-
3 votesStephen
shared this idea
·
-
4 votesStephen
shared this idea
·
-
22 votesStephen
supported this idea
·
-
153 votes
Adam
responded
We’ve made some improvements in this area but will leave it open so you can continue to give us your suggestions
An error occurred while saving the comment Stephen
commented
Our Production SQL Monitor DB is north of 90GB, skinnied down to near minimal data retention, (making the tool less useful for historical analysis). Please consider this as more of the norm for larger customers.
We, too, had to either use Azure, incurring the SQL Server license bump, or hunt for a spare license, which wasn't available without hurting a paying customer. Open source DB would be preferable to the 8K for Standard, likely to go up in price with Microsoft's mooted core licensing for Standard edition...
Stephen
supported this idea
·
An error occurred while saving the comment Stephen
commented
Thanks for the clarification, Fiona. I wonder this wasn't mentioned over a year ago when we purchased the product...
We will happily use SQL2008R2 Express with its 10GB limit and would welcome you posting the edits either here or as a sticky on the SQL Monitor 3 Forum itself (or both). We would prefer to keep the purge window small and NOT reduce the collection frequency.
Thanks.
An error occurred while saving the comment Stephen
commented
Using hosted servers, we have a SQL cluster that is our Production machine. The inability to install the Base Monitor on that cluster requires us to purchase an additional SQL Server and license it at in excess of $8K for the SQL Std license plus ongoing monthly charges.
This makes an inexpensive, quality product much more expensive...
We have Web Servers to handle IIS7 but the Base Monitor is the issue.
-
5 votesStephen
shared this idea
·
-
12 votes
An error occurred while saving the comment Stephen
commented
Custom Metrics are OK for low-volumes of Jobs and servers, but as each and every Custom Metric of this kind cites ONE and ONLY ONE Job, and the Alert must, therefore, be named coincident with the Metric, it is not a long term viable option.
I have used a technique SIMILAR to what Fiona describes but using an excessive DURATION and, while it does work, it's not something I look forward to maintaining/reproducing across instances/jobs.
Please consider, as Steve requested, ENHANCING SQL Monitor so there is a built-in Alert that one can pick the Job Name and state EITHER the duration(s) from the Start-time after which a Low, Medium or High Alert must be emitted, or the exact time that the Job must be complete by.
SQL Monitor Forum Post http://www.red-gate.com/MessageBoard/viewtopic.php?p=57950#57950 details the scenario and query.
Stephen
supported this idea
·
-
30 votes
Daniel Rothig
responded
Custom metrics on sys.dm_io_virtual_file_stats are the best way to get this today
Stephen
supported this idea
·
An error occurred while saving the comment Stephen
commented
As an accidental DBA, this, to me, seems quite important... Is it? If so, is there a reason why it doesn't appear in the Alert-set for SQL Monitor? Planned inclusion, perhaps?
Helpful insight within SQL Monitor would assist folks like me to act upon what seems a serious condition.
Comments, Red-Gate folks...? (I don't know enough about this kind of Alert to know one way or the other whether to take note or ignore - need guidance)
Stephen
shared this idea
·
Overrides at lower levels, especially "select" email addresses or group-lists ARE still an UTTER PAIN to locate with any degree of productivity. I have only 24 servers. Tier-1, 2, 3 are distributed differently. The may also be customer-centric specialists. Our email domain just changed. How on earth to locate and change all these configurations is NOT something SQM supports. Even the RG-originated SQL Query, and "use the API" didn't address the issue. So, in answer to the most recent post, SOMETHING FAR BETTER IS MOST DEFINITELY NEEDED, imo.