Users are waiting
Pages, reports, jobs, or imports are slow enough to interrupt normal work, but the cause is still unclear.
Services / SQL Server performance review
SQL Server performance review
I review recurring SQL Server slowdowns, blocking, deadlocks, and plan changes to find what is affecting the workload and what should be tested first.
I check wait stats, blocking chains, execution plans, Query Store, indexes, tempdb, resource pressure, and workload timing. You receive concise written findings and a call to review the recommended changes.
20+ years working with SQL Server
SQL Server 2005 to 2025
Direct work with the consultant doing the review
01 / Start
Start with a short description of the slowdown and when it affects normal work.
02 / Review
I check the SQL Server data that matches the problem instead of tuning from one metric.
03 / Receive
You receive written findings, recommended changes, and a call to review them.
When this performance review makes sense
This review is useful when SQL Server is slowing down application work, reports, imports, or scheduled jobs and the cause is still unclear.
It stays focused on performance. Choose the health audit when backups, recovery, jobs, configuration, and access all need checking.
Blocking or deadlocks return
The same incident returns and you need to identify the head blocker, transaction pattern, access order, or plan involved.
There are several possible causes
Indexes, CPU, storage, parameter sniffing, and tempdb have all been suggested. You need to know which one matches the slowdown before changing production.
Performance dropped after a change
The problem started after a deploy, data growth, reporting change, schedule change or new integration, and the old baseline no longer helps.
What I check in a SQL Server performance review
I start with the affected workload, then use the SQL Server data that matches the timing and symptoms. The exact checks depend on what is slow and what data is available.
Blocking and deadlocks
01- 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 when the database data points outside SQL Server.
Waits and resource pressure
02- Wait stats over the incident window, compared with longer-term totals.
- CPU, memory, I/O latency, log write pressure, and parallelism waits.
- Whether waits match the complaint or only describe background noise.
Queries and plans
03- 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
04- Missing-index requests checked against the actual workload before any index change.
- 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
05- 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 monitoring
06- SQL Agent jobs, reporting windows, backups, imports, and maintenance overlap.
- Monitoring history, alerts, error logs, Extended Events, and Query Store coverage.
- The data to capture during the next recurrence if the issue is intermittent.
What you get with a SQL Server performance review
You receive concise written findings before the review call. The findings explain the likely cause, recommended urgency, and the changes I would test first.
01
Written findings
A concise explanation of the affected workload, the likely cause, and the SQL Server data behind important findings.
02
Recommended urgency
The findings separate changes worth testing soon from later improvements and items that only need monitoring.
03
What to change first
You get the changes I would test first, along with any deployment, application, or monitoring work they depend on.
04
Review call
We go through the findings together, answer questions, and confirm which follow-up work needs a separate scope.
How the performance review works
Start with what is slow, when it happens, and whether production is affected. I will request the relevant technical details after confirming that the review fits the problem.
The sequence is simple: scope confirmation, technical review, written findings, and a review call.
Confirm the scope
Start with a short message about what is slow, when it happens, and whether production is affected. I will ask for the relevant technical details after confirming fit.
Review the SQL Server data
I review the agreed Query Store exports, plans, deadlock graphs, wait-stat snapshots, monitoring history, or read-only production data.
Receive the findings
You receive the written findings before the review call. We then discuss the recommended changes and any separately scoped follow-up work.
How remote access works
I use the least intrusive access that still allows a proper review. Shared files, screen sharing, and read-only production access can each support the work.
Shared SQL Server data
Query Store exports, execution plans, deadlock graphs, blocked-process reports, wait-stat snapshots, job history, and monitoring exports.
Screen sharing
We can review the affected workload and SQL Server data together when files or direct access are unsuitable.
Read-only access
Read-only production access can make the review faster when it is suitable and agreed in advance.
How the review is scoped and quoted
I confirm the price and expected delivery date after a short conversation. The quote depends on urgency, the SQL Server data already available, the access method, and whether the problem is active or intermittent.
What happens after the review
The performance review covers diagnosis and recommendations. Production changes, application changes, index implementation, extended monitoring, and follow-up testing receive a separate scope when they are needed.
Related SQL Server performance guides
01
SQL Server performance issues
How to approach slow periods, waits, blocking, tempdb pressure, and workload timing.
Open guide
02
SQL Server blocking guide
How to separate waiting sessions from head blockers, transaction scope, and job overlap.
Open guide
03
SQL Server tempdb guide
How to check file setup, growth, spills, version store, waits, and workload timing.
Open guide
Choose another service for wider SQL Server work
01
SQL Server health audit
Use the health audit when the real concern is backups, jobs, monitoring, configuration, access, and general operational risk.
See health audit
02
Recovery and disaster-recovery review
Use recovery readiness when the main question is restore timing, backup chain quality, failover behavior or recovery runbooks.
See recovery readiness
03
SQL Server upgrade support
Use upgrade support when the core work is version change, compatibility, test run, rollback, and validation.
See upgrade support
04
Broader SQL Server consulting
Use the consulting parent page when performance is only one part of a larger SQL Server problem.
See SQL Server consulting
Questions before contacting me
What is included in a SQL Server performance review?
+
I check the affected workload and the SQL Server data that can explain it. This can include waits, blocking, deadlocks, execution plans, Query Store, indexes, statistics, tempdb, resource pressure, workload timing, and monitoring history.
What do I receive after the review?
+
You receive concise written findings with the likely cause, the SQL Server data behind important findings, recommended urgency, and the changes I would test first. A review call is included.
Do you need production access?
+
I can often start with Query Store exports, execution plans, deadlock graphs, blocked-process reports, wait-stat snapshots, monitoring screenshots, and job history. Read-only production access may make the review faster when it is appropriate.
Can you review an intermittent problem?
+
Yes. I use the monitoring history and SQL Server data already available, then specify what to capture during the next incident when important details are missing.
Can this be done remotely?
+
Yes. Remote delivery is the default. Files, screenshots, screen sharing, monitoring exports, and read-only access can all be used depending on the agreed scope.
How are price and delivery timing confirmed?
+
I confirm the price and expected delivery date after a short conversation. The quote depends on urgency, the available SQL Server data, access, and whether the problem is active or intermittent.
Are production changes included?
+
The performance review covers diagnosis and recommendations. Production changes, application changes, index implementation, extended monitoring, and follow-up testing are scoped separately.
What should I send in the first message?
+
Tell me what is slow, when it happens, and whether production is affected. I will ask for versions, plans, monitoring exports, or access after confirming that the review is a good fit.
Request a SQL Server performance review
Send a short description of the slowdown and its effect on production. I will confirm whether a focused performance review fits and what information is needed to quote it.