Skip to content

10 Reasons Your SQL Server Is Crawling (and How to Find Long Running Queries with Database Health Monitor)

It’s an unremarkable Tuesday afternoon: until the emails start hitting your inbox. "The application is lagging." "The reports won't load." "The database feels like it's stuck in molasses."

We’ve all been there. As the owner of Stedman Solutions, I've spent over 30 years working with SQL Server, and if there is one thing I’ve learned since 1990, it’s that a "slow" database is rarely caused by just one thing. Usually, it's a combination of small configuration issues and a few "heavy lifter" queries that are hogging all the resources.

When your SQL Server is crawling, your first instinct might be to start writing complex DMV (Dynamic Management View) queries to see what’s going on. But if you’re under pressure, you don't want to spend twenty minutes debugging your own diagnostic scripts: you want answers now.

Today, let’s look at the ten most common reasons your SQL Server is performing poorly and how you can use our proprietary tool, Database Health Monitor, to find long-running queries in SQL Server in seconds rather than hours.

1. Resource Constraints: The Hardware Ceiling

Sometimes, the simplest explanation is the right one: your server is just out of breath. If your CPU is constantly pegged at 90% or your Page Life Expectancy (PLE) is dropping into the double digits, your hardware simply can't keep up with the workload.

We often see this in virtualized environments where the "Balanced" Windows Power Plan is still active, or where the SQL Server hasn't been allocated enough RAM. If SQL Server has to go to the disk every time it needs data because it can't keep it in memory, everything slows down.

2. I/O Subsystem Bottlenecks

Your SQL Server is only as fast as your storage can deliver data. If you have slow disks or high latency on your SAN, your queries will spend most of their time waiting for "PAGEIOLATCH" waits. We’ve seen cases where antivirus software or backup filter drivers were scanning database files in real-time: effectively cutting I/O performance in half.

3. Missing Indexes

This is the classic performance killer. Without the right indexes, SQL Server has to perform a "Table Scan": reading every single row in a table just to find one record. It’s like trying to find a name in a phonebook that isn't alphabetized.

SQL Server index fragmentation vs optimized indexing for faster database performance
Caption: Indexing is the foundation of a fast database.

4. Poorly Written Queries (The "SELECT *" Trap)

We’ve all done it, but SELECT * is one of the worst things you can do for performance. It forces SQL Server to pull every column, which increases I/O and memory usage. Even worse are queries with non-sargable (Search ARGument-able) clauses: like using a function on a column in a WHERE clause: which prevents SQL Server from using an index effectively.

If you want to dive deep into how SQL Server actually processes these requests, I highly recommend checking out our SQL Performance Tuning Class. It’s designed to help you understand execution plans so you can spot these issues instantly.

5. Blocking and Deadlocking

Performance isn't always about speed; sometimes it's about traffic jams. Blocking occurs when one process holds a lock on a piece of data and another process has to wait for it. If you have a long-running report locking a table that your transactional app needs, the app will appear to "crawl" when it's actually just standing still.

6. Outdated Statistics

SQL Server’s Query Optimizer uses statistics to decide the fastest way to run a query. If those statistics are out of date, the Optimizer might choose a "Nested Loop" join when a "Hash Match" would have been ten times faster. If you haven't updated your stats recently, your server is essentially flying blind.

7. Parameter Sniffing

This is a tricky one. Parameter sniffing happens when SQL Server creates an execution plan based on the specific parameters used the first time a stored procedure is run. If that first set of parameters was an outlier: say, a small search: but the next search is massive, the "small" plan might be incredibly inefficient for the "large" search.

8. Implicit Conversions

Have you ever joined a VARCHAR column to an NVARCHAR column? If so, you've likely triggered an implicit conversion. SQL Server has to convert the data types on the fly for every single row to make the comparison. This creates massive CPU overhead and, once again, often prevents the use of indexes.

9. TempDB Contention

TempDB is the "scratchpad" for your entire SQL Server instance. If you have a lot of temporary tables, complex joins, or sorting going on, TempDB can become a massive bottleneck. If your TempDB isn't configured with multiple data files (one per logical core, up to 8), you might be suffering from allocation contention.

10. The "Kitchen Sink" Stored Procedure

We see this a lot in older applications: a single stored procedure with 15 optional parameters and a massive block of IF/ELSE logic. These are nightmares for the Query Optimizer. They lead to "bloated" plans that take up massive amounts of memory and run significantly slower than smaller, targeted queries.


How to Find Long Running Queries with Database Health Monitor

Knowing why a server is slow is only half the battle. You need to know which specific query is causing the pain.

While you could use SQL Server Profiler (which is deprecated and heavy) or Extended Events (which can have a steep learning curve), we built Database Health Monitor to give you a "one-look" dashboard of your entire instance.

Step 1: Check the Real-Time Dashboard

When you connect Database Health Monitor to your instance, the first thing you see is the Dashboard. This gives you a bird's-eye view of CPU, Memory, and I/O. If you see the "Wait Stats" chart spiking, you know exactly what category of problem you’re dealing with.

Step 2: Use the "Long Running Queries" Report

Inside Database Health Monitor, we have a specific report dedicated to finding the "top offenders." Unlike manual scripts that only show you what is running right now, our tool looks at the plan cache to show you:

  • Queries with the highest total CPU time.
  • Queries that are doing the most logical reads (I/O heavy).
  • Queries that have the longest average execution time.

Database Health Monitor dashboard to find long running queries in SQL Server
Caption: The Long Running Queries report in Database Health Monitor helps you pinpoint the exact code causing the slowdown.

Step 3: Drill Down into the Execution Plan

Once you've identified a long-running query, you can click into it to see the execution plan. We’ve made it easy to see where the "cost" is. Is it a Missing Index? An Expensive Sort? Database Health Monitor highlights these suggestions so you don't have to be a Query Store master to find the fix.

Why Use a Tool Instead of Manual Scripts?

As a SQL Server performance tuning consultant, I still use scripts occasionally, but for day-to-day monitoring, tools are superior for three reasons:

  1. Visualization: It’s much easier to see a trend in a chart than in a grid of 5,000 rows of DMV data.
  2. Historical Context: Database Health Monitor helps you see what happened an hour ago, not just what is happening this second.
  3. Speed to Resolution: When your boss is standing over your shoulder, you don't want to be typing JOIN sys.dm_exec_query_stats. You want to click a button and say, "Here is the query causing the block."

Let Us Take the Burden Off Your Shoulders

If your SQL Server is constantly crawling and you find yourself fighting these fires every week, it might be time for a different approach. At Stedman Solutions, we specialize in SQL Server managed services.

Our team: a group of experts with well over 100 years of combined experience: provides 24/7 monitoring using Database Health Monitor and our own internal toolsets. We don't just tell you there's a problem; we find it, fix it, and optimize your environment so it doesn't happen again.

Whether you need a one-time performance tuning engagement or ongoing support, we are here to help. You don't have to be a "Junior DBA" trying to figure this out on your own: let the experts handle the heavy lifting.

Take Action Today:

  • Download the Tool: Get the free version of Database Health Monitor and see what's actually happening under the hood.
  • Get a Checkup: Not sure if your configuration is right? Look into our SQL Daily Checkup to get a professional review of your environment.
  • Talk to Me: If you're facing a critical slowdown and need help right now, reach out for a free 30-minute consultation. We can take a look at your server together and see what's really going on.

Don't let a slow SQL Server impact your business productivity. With the right tools and a little bit of expert guidance, you can move from "crawling" back to "lightning fast" in no time.

Getting Help from Steve and the Stedman Solutions Team
We are ready to help. Steve and the team at Stedman Solutions are here to help with your SQL Server needs. Get help today by contacting Stedman Solutions through the free 30 minute consultation form.

Contact Info for Stedman Solutions, LLC. --- PO Box 3175, Ferndale WA 98248, Phone: (360)610-7833
Our Privacy Policy