Slow periods keep returning
Reports, jobs, pages, imports, or whole workload windows keep slowing down without one clear cause.
Consulting / SQL Server performance
SQL Server performanceconsultant
I review SQL Server performance issues when slow queries, blocking, deadlocks, waits, or plan changes keep coming back without a clear diagnosis.
Use this when the system is still running, but performance work has turned into guesses about indexes, storage, CPU, tempdb, code, or recent releases.
Fit
When SQL Server performance consulting fits
Blocking or deadlocks are hurting work
Users see timeouts, failed work, or repeated delays while the real blocker or transaction pattern is still unclear.
The cause keeps changing
Indexes, storage, CPU, tempdb, code, and recent releases have all been blamed, but the next change still feels like a guess.
A release or workload change made things worse
A deployment, data change, schedule change, or new workload shifted performance enough that the old explanation no longer fits.
Technical questions
The performance questions I would check first
- What is slow: query, report, job, import, page, or whole workload?
- Is the symptom constant, periodic, or tied to a workload window?
- Are waits, blocking, deadlocks, Query Store, or plans available?
- Did a release, data change, index change, patch, or workload change happen recently?
- Are tempdb, storage, CPU, memory, or log writes involved?
Business questions
The decisions behind the performance work
- Who is affected?
- When does the slowdown hurt most?
- What has already been changed?
- Which workloads cannot be interrupted?
- Does this need one review or regular DBA help?
Review scope
What I check in a SQL Server performance review
Waits
Wait stats and active waits
Current waits, historical wait patterns where available, active waiting tasks, workload timing, and waits that match the symptom.
WaitsTimingSessions
Blocking
Blocking and deadlocks
Head blockers, lock waits, transaction scope, blocked-process output, deadlock graphs, and recurring contention windows.
LocksBlockersDeadlocks
Plans
Query plans and Query Store
Execution plans, plan changes, Query Store runtime data, parameter-sensitive behavior, regressions, and high-cost operators.
PlansQuery StoreRegressions
Indexes
Indexes and statistics
Missing, duplicate, unused, wide, or write-heavy indexes, stale statistics, and indexing changes that may hurt other work.
IndexesStatsWrites
Storage
Tempdb and storage
Tempdb pressure, spills, version store, file latency, file growth, log growth, and storage delays during busy periods.
TempdbFilesLatency
Workload
Workload timing and jobs
SQL Agent overlap, reporting windows, imports, ETL, maintenance jobs, application timing, and recent workload changes.
JobsOverlapChanges
Output
What usually comes out of the review
What to check first
The waits, plans, blockers, jobs, or workload windows that best match the reported slowdown.
What is likely not the cause
Noisy findings that may look suspicious but do not explain the performance complaint.
What needs a safe change
Query, index, statistics, transaction, workload, tempdb, or configuration changes worth planning carefully.
What needs more samples
Intermittent symptoms that need better capture before changing production behavior.
Choosing the right start
Performance consulting or another service
| Situation | Better start | Reason |
|---|---|---|
| Slow periods, blocking, waits, or deadlocks are the main concern | Performance consulting | The symptom needs to be connected to waits, plans, workload timing, and recent change history. |
| The job is already a narrow performance-review scope | Performance review | Start there when the problem is clearly a focused review of waits, blocking, plans, tempdb, or workload timing. |
| Several SQL Server areas are unclear at once | Existing environment review | Backups, jobs, alerts, ownership, recovery, and performance need a wider review. |
| The main issue is restore or DR planning | Recovery readiness | Start with backup chain, restore sequence, RPO/RTO, and failover behavior. |
| The main issue is a version change | Upgrade support | Start with compatibility, test run, rollback, and validation. |
First step
How the work starts
Start with the symptom. I will tell you whether this should be performance consulting, a narrower performance review, or another SQL Server service.
First message
Symptom, urgency, production impact.
After fit check
Waits, plans, blocking, Query Store, job history.
Output
Findings, recommendations, next steps.
Step
1. Send the symptom
+
Step
1. Send the symptom
The first message only needs what is slow, how urgent it is, and whether production is affected.
Step
2. I decide whether performance consulting fits
+
Step
2. I decide whether performance consulting fits
If the work is better handled as a narrow performance review, health audit, upgrade support, or monthly DBA support, I will say that plainly.
Step
3. We agree what to check
+
Step
3. We agree what to check
Wait stats, query plans, Query Store data, blocked-process output, deadlock graphs, job history, monitoring data, recent-change notes, and access details come after the fit check.
Step
4. I review the SQL Server details
+
Step
4. I review the SQL Server details
The review stays tied to performance: waits, blocking, plans, indexing, statistics, tempdb, workload timing, and recent changes.
Step
5. You get usable findings
+
Step
5. You get usable findings
You get findings, recommended next steps, what I would check first, and what can wait.
Not the right fit
When this is not the right fit
- You only need a known query change implemented.
- You need 24/7 monitoring or permanent staffing.
- The problem is mainly an upgrade, recovery, or audit question.
- Nobody can arrange access or provide SQL Server details after first contact.
Better fit
When this review is useful
- Slow periods, blocking, waits, deadlocks, or plan changes need review.
- The company has tried several fixes without a stable diagnosis.
- A release, workload change, or data growth changed performance.
- The company may need monthly DBA support but wants the first review to focus on performance.
Related pages
Related SQL Server pages
Performance review
Performance review
For slow periods, blocking, waits, deadlocks, query plans, tempdb pressure, and workload timing.
See performance review
Main service
SQL Server consulting
The main page for performance, recovery, upgrades, current setup reviews, and ongoing DBA help.
See consulting
Remote help
Remote SQL Server consultant
For review, troubleshooting, planning, and DBA help that can be handled remotely.
See remote consulting
Blocking
SQL Server blocking guide
For head blockers, lock waits, transaction shape, and timeouts during live workload.
Read blocking guide
Waits
SQL Server waits guide
For reading wait patterns and connecting waits back to workload behavior.
Read waits guide
Ongoing help
Monthly DBA support
For companies that need regular SQL Server review, troubleshooting, and planned-change help.
See support
Contact
Need a SQL Server performance issue reviewed?
Send a short note about what is slow, when it happens, and whether production is affected. I will tell you whether performance consulting is the right start.
A short description is enough for the first message.
FAQ
What does a SQL Server performance consultant check?
+
I check the symptom, waits, blocking, deadlocks, query plans, Query Store, indexes, statistics, tempdb, jobs, workload timing, resource pressure, and recent changes.
Is this the same as a performance review?
+
The performance review is the narrower service when the scope is already clear. Performance consulting is better when the symptom is real but the diagnosis, scope, or next step is still unclear.
Can this be done remotely?
+
Yes. Most SQL Server performance review work can be done remotely when someone can arrange access, screen-share, or provide the right SQL Server details after the first fit check.
Do you tune queries and indexes?
+
Yes, when the diagnosis supports it. I do not start with tuning for its own sake; I first check whether queries, indexes, plans, statistics, blocking, tempdb, or workload timing explain the symptom.
What should I send first?
+
Send what is slow, when it happens, how urgent it is, whether production is affected, and what changed recently if you know.
Can this lead to monthly DBA support?
+
Yes. If the review shows performance needs regular follow-up, monthly DBA support may be the better fit.