Users are waiting
The application still works, but pages, reports, jobs or imports are slow enough that the team needs a proper diagnosis.
Services / SQL Server performance review
SQL Serverperformance review
I review SQL Server performance problems when slow queries, blocking or deadlocks keep coming back without a clear explanation.
Use this for blocking, deadlocks, wait stats, slow queries, plan changes, tempdb pressure or workload slowdowns that need evidence before the next fix.
Input
Symptoms, timing, affected workload, recent changes, and whatever evidence already exists.
Review
Waits, blocking, deadlocks, plans, indexes, statistics, tempdb, jobs, and workload timing.
Output
Likely cause, evidence, safe first changes, and what to collect if the problem returns.
Fit
When a SQL Server performance review fits
The review is for performance problems that are real enough to affect work, but still unclear enough that another quick change would be a guess.
If the issue is broad operational risk, start with the health audit. If the pain is SQL performance, start here.
Blocking or deadlocks keep returning
The same kind of incident keeps appearing, but the evidence still does not explain the head blocker, transaction pattern or plan choice.
Several theories already exist
Indexes, waits, CPU, storage, parameter sniffing, and tempdb have all been mentioned. The next change needs better evidence behind it.
A release or workload change made SQL slower
The problem started after a deploy, data growth, reporting change, schedule change or new integration, and the old baseline no longer helps.
Review
What I review in a SQL Server performance review
Performance work starts with the symptom. Waits, plans, indexes, and server settings only matter when they explain what users actually see.
Symptom
The actual performance complaint
Which users, jobs, reports or application paths are slow, when it happens, and whether the pain is constant, periodic or tied to one workload.
Waits
Wait stats and blocking chains
Current waits, historical waits where available, blocking chains, head blockers, long transactions, lock waits, and deadlock patterns.
Plans
Query plans and Query Store
Plan changes, regressions, parameter-sensitive behavior, expensive operators, memory grants, spills, and query patterns that changed over time.
Indexes
Indexes and statistics
Missing, unused, duplicate, and over-wide indexes, stale statistics, key lookups, scans, and index maintenance that does not match the workload.
Tempdb
Tempdb and spill pressure
Tempdb layout, contention signs, version-store pressure, sort/hash spills, snapshot isolation side effects, and file growth behavior.
Platform
CPU, memory, I/O, and settings
CPU pressure, memory grants, max server memory, MAXDOP, cost threshold, storage latency, log writes, and basic instance settings.
Timing
Jobs and workload overlap
SQL Agent schedules, reporting windows, ETL, maintenance, backups, imports, and batch work that collide with normal application use.
Capture
Monitoring and next evidence
Whether the current monitoring can explain the next incident, and what evidence should be collected before more tuning guesses happen.
Technical checks
SQL Server performance checks
The exact list depends on the symptom and the evidence available. These are the usual places I expect to check before recommending production changes.
Blocking and deadlocks
- Head blockers, blocked session chains, isolation level, transaction length, and lock escalation signs.
- Deadlock graphs, victim choice, access order, indexes involved, and retry behavior.
- Application transaction shape where the database evidence points outside SQL Server.
Waits and resource pressure
- Wait stats by time window, not only a lifetime aggregate.
- CPU, memory, I/O latency, log write pressure, and parallelism signals.
- Whether waits match the complaint or only describe background noise.
Queries and plans
- Query Store, execution plans, plan regressions, high-cost operators, spills, and memory grants.
- Parameter sniffing signs, compile behavior, row-estimate mistakes, and plan instability.
- Top resource consumers by duration, CPU, reads, writes, and execution count.
Indexes and statistics
- Missing-index requests checked against the actual workload, not applied blindly.
- Duplicate, unused, wide or write-heavy indexes that slow the system down elsewhere.
- Statistics age, sampling, skew, filtered indexes, and maintenance side effects.
Tempdb and configuration
- Tempdb file count, size, autogrowth, waits, spills, and version-store pressure.
- Max server memory, MAXDOP, cost threshold, and configuration values that affect the symptom.
- Database file growth, log growth, free space, and slow storage warning signs.
Workload timing and evidence
- SQL Agent jobs, reporting windows, backups, imports, and maintenance overlap.
- Monitoring history, alerts, error logs, Extended Events, and Query Store coverage.
- A short evidence list for the next recurrence if the issue is intermittent.
Output
What you get with a SQL Server performance review
You get a diagnosis tied to evidence, a clear fix order, and fewer random production changes.
The symptom in plain words
What is actually happening, when it happens, and which SQL Server signals support that view.
Evidence behind the diagnosis
Important findings point back to waits, blocking chains, plans, Query Store, jobs, tempdb, storage or monitoring history.
What to change first
Safe first changes, later changes, follow-up analysis, and watch items are separated so production is not tuned by guesswork.
What to collect next time
For intermittent problems, the output includes the evidence to collect next time so the team is not starting from zero again.
Process
How the SQL Server performance review works
The first message only needs the symptom and whatever evidence already exists. A perfect packet is not required.
Scope depends on urgency, evidence quality, production access, and whether the issue is constant or intermittent.
Step
1. Send the symptom
Send what users see, when it happens, recent changes, SQL Server version, and any waits, plans, blocked-process output, deadlock graphs or monitoring screenshots.
Step
2. I review the evidence
I check the evidence that matches the complaint: waits, blocking, plans, Query Store, indexes, statistics, tempdb, jobs, and resource pressure.
Step
3. We check what actually explains it
Some scary-looking numbers do not explain the symptom. Some boring details matter a lot. The discussion sorts that out.
Step
4. You get the fix order
You get the likely cause, the evidence, the safe first changes, and what to collect if the problem is intermittent or not fully reproduced yet.
Proof and reading
Useful background before you send the performance problem
Related
SQL Server performance issues
How to approach slow periods, waits, blocking, tempdb pressure, and workload timing.
Open guide
Related
SQL Server blocking guide
How to separate waiting sessions from head blockers, transaction scope, and job overlap.
Open guide
Related
SQL Server tempdb guide
How to check file setup, growth, spills, version store, waits, and workload timing.
Open guide
Fit check
Not the right service when the problem is wider
A broad SQL Server environment review
Use the health audit when the real concern is backups, jobs, monitoring, configuration, access, and general operational risk.
See health audit
A pure restore or DR proof question
Use recovery readiness when the main question is restore timing, backup chain quality, failover behavior or recovery runbooks.
See recovery readiness
A pure upgrade project
Use upgrade support when the core work is version change, compatibility, test run, rollback, and validation.
See upgrade support
A wider SQL Server support need
Use the consulting parent page when performance is only one part of a larger SQL Server problem.
See SQL Server consulting
Before you send it
Send the rough symptom, not a polished incident report. Timing, affected workload, and recent changes are enough to start.
If you have waits, plans, Query Store screenshots, deadlock graphs, blocked-process output, job history or monitoring charts, include them.
The first useful decision is whether this needs a performance review, a wider health audit or urgent production help.
Request a SQL Server performance review
I will look at the symptom and evidence, then tell you the sane next step. Sometimes that is a focused review. Sometimes the issue is wider than performance.
FAQ
What is included in a SQL Server performance review?
+
The review checks the symptom, waits, blocking, deadlocks, query plans, Query Store, indexes, statistics, tempdb, jobs, workload timing, resource pressure, and the monitoring evidence available for the problem.
Is this the same as SQL Server performance tuning?
+
It can lead to tuning work, but the first job is diagnosis. I want to understand what is slow, why it is slow, and which first changes are safe enough to make.
Do you need production access?
+
Not always. I can start from Query Store exports, execution plans, deadlock graphs, blocked-process reports, wait snapshots, monitoring screenshots, and job history. Direct read-only access can make the work faster.
What should we send first?
+
Send the symptom, timing, affected users or jobs, SQL Server version, recent changes, and any evidence around waits, plans, blocking, deadlocks, CPU, I/O, tempdb or Query Store.
Can this be done remotely?
+
Yes. Remote review is the default when the team can share enough evidence or access for a proper diagnosis.
How is the performance review priced?
+
Scope depends on urgency, available evidence, whether the issue is active or intermittent, and how much follow-up testing is needed after the first review.
What happens after the review?
+
You get a fix order. Some items can usually be changed safely. Some need testing, a deployment window, application changes or better evidence before anyone touches production.