mst
My feedback
1 result found
-
54 votes
An error occurred while saving the comment mst
supported this idea
·
An error occurred while saving the comment mst
commented
This is a "me, too" comment...specifically speaking to the point raised by Theresa. I created a metric that grabs the time it takes to run all my daily full backups on all instances. They are scheduled at 11pm and my custom metric runs once a day. Unfortunately since I created it at 3pm I don't see the data point for yesterday's backups until 3pm today.
It looks like it might change that time of day if I turn off collection and turn it back on at the desired time. (And as she notes-- I'd rather not get up at 1am to do so)
But please confirm-- that doesn't also mean that if SQL Monitor gets stopped for any reason-- that all the collection frequencies set for custom metrics will initialize to start at whatever time of day SQL Monitor gets restarted?
Hi Theresa...
Well, I've bumped THIS one up to 3 votes... and would throw the rest of my votes in here if I could.
That's unfortunate-- and really limits the usefulness of the custom metric, to my way of thinking. If I want all alerts from my custom metrics to show up in email at the start of the day I cannot reliably do that. The gold standard would be for Redgate to implement a scheduler with all the flexibility of the SQL scheduler.
You indicate you run it in SSIS instead; is that a completely "roll-your-own" implementation? A *partial* solution might be to turn off alerting but continue collecting data. This wouldn't solve the server load on restart (or timing for less frequently collected metrics), but if we could find where the custom metric data is stored in RedGateMonitor, we might be able to reference that (while waiting for a real scheduler) for alerting/reporting via TSQL or SSIS or whatever, assuming doing so doesn't violate terms of use.