We’ve got a demo of SQL Monitor available that takes data from the actual SQLServerCentral systems and presents it publicly. The data is slightly delayed, but it’s the real data and it shows the performance of our system.

I actually use this at times when the site isn’t responding well. It’s quicker for me to hit monitor.red-gate.com than log into VPN and check the real instance.

I was reading a report for a customer recently and they mentioned they used the baseline feature to track performance of the system when they make changes, using this to decide if they think the changes were positive or negative.

Note: they rarely roll back, instead using this data to determine if they need to dig into more specifics and then create a new deployment (roll forward) that can address issues.

Baselines

There has been a lot written about baselines, but essentially these are a way of capturing what is “normal” for your system. If current performance deviates from normal, you might have cause for concern.

Of course, this is a gross way of looking at a system and you have to apply some of your own knowledge to determine if you have issues, or some transient workload is altering performance during your sample period.

You can see a demo of baselines online and play with the ranges. It looks similar to this image below, in which case I can see the last 24 hours of my CPU time, and then compare that with the 24 hours before that.

Using this type of diagram, I can quickly visualize issues that might be occurring without resorting to complex analysis.

This doesn’t give me the exact problem. I’d still need to dig into the code being run, look at execution plans and other detailed data (much of which I can get from SQL Monitor as well), but this does let me make an initial judgment on where to focus my time.

I would highly encourage you to run, keep, and update baselines on your system. At the very least, you should have an idea of what types of performance should exist on critical systems.