Baseline vs. Guessing

Why “SQL Server is slow” means nothing without historical data

Too often “it’s slow” is a guess, not a diagnosis. Without historical performance data, you have no baseline to compare against. A single moment in time doesn’t tell you whether your current state is normal, trending worse, or an outlier event.

4 Metrics Every SQL Server Should Track

To build a reliable baseline, make sure you’re capturing at least these core counters regularly:

1) CPU Utilization - High CPU could be steady load, runaway queries, or underlying hardware limits.

2) Wait Statistics - Know what resource waits are accruing. They tell you what subsystem is stressed.

3) I/O Latency (Reads/Writes) - Slow storage is a common bottleneck. Historical latency profiles help you spot regressions.

4) Memory Metrics - Track buffer cache hit ratios, memory grants, and paging. Changes here often signal plan or workload shifts. Page Life Expectancy does not have a “best practice” as it is a measurement, not a setting. 300 seconds is marketing nonsense. See what yours is during normal traffic over multiple measurements, and THAT is your baseline to compare against.

These metrics give you a multidimensional view of performance instead of a snapshot that might mislead.

What a 60-Second Snapshot Can Tell You

A quick, automated 60-second sample can:

• Reveal dominant wait types

• Show current CPU pressure

• Detect blocking

• Surface I/O slowdowns

Tools like sp_BlitzFirst from Brent Ozar capture this well. It’s a lightweight way to start baseline collection without heavy infrastructure.

What “Normal” Looks Like for SMB Environments

Every environment is unique, but a few general patterns tend to hold in small-to-medium setups:

• CPU spiky but short-lived, not pegged flat-out night and day

• Wait categories fluctuate around a norm, not constantly atop one type

• I/O latency rarely hits multi-hundreds of ms under typical load (20ms is my preferred max. YMMV)

• Memory usage stabilizes, not constantly paging or flipping

If your environment consistently deviates from its own historical patterns — that’s your cue to dig deeper.

How to Build a Lightweight Weekly Baseline Habit

1. Automate a 60-second capture during “normal” traffic. Once during the day, once overnight if you have overnight processing

2. Store the results in a small table you control

3. Compare current data against last week’s

4. Highlight anomalies (CPU, waits, I/O)

5. Review with stakeholders as necessary

This cadence helps you spot regressions before users do.

The Bottom Line:

If you are not capturing baseline metrics on your SQL Servers, you are guessing and your job is likely very much a “reactive” or “firefighter” mode. If you are a DBA, your job is to prevent as many fires as possible!

SQL TidBit: Erik Darling’s New Monitoring Tool

Erik Darling recently announced a free, open-source SQL Server performance monitoring tool called SQL Server Performance Monitor. It’s designed to collect and visualize performance data (wait stats, CPU trends, blocking, deadlocks, etc.) without expensive licensing or sending your data offsite. This is available in both server-installed and standalone “Lite” editions.

This tool makes it easier to capture the kind of historical data that turns guesses into baselines, especially for solo DBAs, consultants, or smaller teams who want meaningful metrics without enterprise-scale cost.

Caution: I have not even downloaded this tool yet. Test first and use at your own risk.

Advertisement

Do you need SQL Server help, faster than other support methods, and with only a credit card instead of a contract?

Dallas DBAs now offers up to 4 hours of Ad Hoc support for $500 prepaid flat fee.

Learn More