Freeze baseline

deldrum

Hi,
as I understand it, the default behaviour of baselining in SQL Monitor is that you have access to any part of a rolling window of the most recent 28 days and that metrics can be averaged into regions. My concern is that with this approach recent comes to mean the same thing as normal - exceptional or deteriorating performance gets absorbed into the averaged baseline regions. What used to be normal - the original baseline - will get purged according to the SQL Monitor purge configuration.
Is there a way, either through standard SQL Monitor functionality or with a (simple?) script against the monitoring database, to capture a few weeks of baseline data long term (and have this available as a baseline within SQL Monitor)? In this way it would be possible to compare current performance with that of a year ago (say), without having to store a full 12 months of metrics.

Thanks

Alex B

Hi Deldrum,

This is how the baseline feature was intended to be used - from the product page here:

SQL Monitor takes the latest performance data into account, so you're always looking at real life performance, not a baseline that's tied to a single period in the past.

If this is a feature you feel would still be beneficial please raise it in the uservoice forum. Here is the original uservoice request for the baseline feature.

kind regards,
Alex

EdCarden

deldrum wrote:

Hi,
as I understand it, the default behaviour of baselining in SQL Monitor is that you have access to any part of a rolling window of the most recent 28 days and that metrics can be averaged into regions. My concern is that with this approach recent comes to mean the same thing as normal - exceptional or deteriorating performance gets absorbed into the averaged baseline regions. What used to be normal - the original baseline - will get purged according to the SQL Monitor purge configuration.
Is there a way, either through standard SQL Monitor functionality or with a (simple?) script against the monitoring database, to capture a few weeks of baseline data long term (and have this available as a baseline within SQL Monitor)? In this way it would be possible to compare current performance with that of a year ago (say), without having to store a full 12 months of metrics.

Thanks

You're not the only one who sees data captured by SQL Monitor as being useful (for historical comparison/analysis). For some reason RedGate (along with at least 1 major competitors app) takes the stance that the information captured has no valid use outside the current day/week and so the whole thing is geared around working with just that information you are receiving or just received. If you do decide to retain the data just know that this will eventually lead to other issues namely purging. The system assumes data retention is short and so the purge process is not built to deal with purging large amounts of data. If like us you have data for SQL Monitor outside a few months you will eventually hit a breaking point where you can't purge (using the programs purge functionality) because the whole thing crashes before it can complete the purge. The process used to purge was not designed to work for anything but small amounts of data and that is presumably because the assumption was that no one would ever want to keep this information outside a short period. We went through a change in hardware while using SQL Monitor and I was able to easily show (the executives and my boss) that the improved hardware I recommended was producing better response times because I had the old metrics from SQL Monitor to compare to the new ones.

We were using SQL Monitor 4 as our primary SQL monitoring app but eventually had to switch when VMware became a factor (against my preferences) and SQL Monitor wasn't designed to take into account the differences between a virtual and non-virtual environment when it comes to something like I/O. I loved SQL Monitor aside form the fact that its not designed for data retention beyond the short term but I had to prove there was a hardware issue and SQL Monitor couldn't do that because we were in a virtual environment. We still use SQL monitor for monitoring of a smaller (less significant) SQL Server instance but I do hope that one day they realize there is value in this data that they are so quick to discard.