SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 

Be Prepared with Baselines

By Steve Jones,

I visited a doctor recently, and he told me a measurement he'd made. I asked if it was good or bad, and he said he had no idea. The value varied too much from person to person, and without values from the past, he couldn't really evaluate the significance of it. He will be able to in the future, now that he has a value, but there's nothing that can be done now. At this point, he has a baseline (of sorts) and can now start to judge how things change over time.

After that visit, I started thinking about Page Life Expectancy (PLE). PLE is one of those counters that so many DBAs look at early in their career. Often they've read guidance that they should worry once this is below 300, which isn't true. There are calculations for this, but they are based on your system, and really, they're a rough rule of thumb. Really you need to measure this for your system, so that you know what a the value often is and then worry when it dips.

To do that you need a baseline. You need to measure various metrics about your system over time so that you understand what's a normal value. Plenty of experts, like Erin Stellato and Tim Radney have written about baselines, why they're important, and what you might want to capture. In fact, we have quite a few articles on baselines at SQLServerCentral.

If that sounds like a lot of work to you, I agree. I've built systems in the past that captured metrics on my instances and stored the data. I wrote reports to view data, alerts to let me know when something is breaking (or broken), and maintenance that kept data storage under control. I essentially had to be both the software developer and operations staff for my systems. That works, but I'd try to avoid repeating that effort from now on. As Tim mentions in his piece, there are better ways to do this. There are products, such as SQL Monitor and SQL Sentry, that capture this data for you, that won't have typos, mistakes, or holes in their operation.  Some will even show you the baseline visually to see if things are withing expected ranges.

The monitoring software does lots for you, though at a price. It's tested, and it does all the gathering, storage, basic analysis and alerting in a way that allows you to spend time on actually fixing issues, tuning queries, and providing value for your organization. I think it's worth the cost, since I know that my time is better spent on solving problems, not writing monitoring software. You may feel the same way or youj may not. You may prefer to write your own system, or you may not have a budget and be forced to build your own. Whichever route you go, make sure you set up a baseline. You'll appreciate having one the next time your phone rings with a call that the server is slow.

 
Total article views: 56 | Views in the last 30 days: 1
 
Related Articles
ARTICLE

Capturing Baselines on SQL Server: Wait Statistics

By capturing baseline data, a well-prepared DBA should get a good idea of what potential issues they...

ARTICLE

Back to Basics: Capturing Baselines on Production SQL Servers

If you have not been capturing baselines on your production servers, then today is the day you can s...

ARTICLE

5 Reasons You Must Start Capturing Baseline Data

It is widely acknowledged within the SQL Server community that baselines represent valuable informa...

ARTICLE

Comprehensive Baseline Collector Solution (Updated)

There are no more excuses for not having baseline data. This article introduces a comprehensive Free...

BLOG

The power of the baseline

There is one thing we all have in common, and a lot of us probably don’t even realize it, baselines!...

Tags
editorial    
monitoring    
 
Contribute