SQL Server Performance Review
SQL Server Performance Review for Slow and Unstable Workloads
The SQL Server Performance Review is designed for teams experiencing timeouts, blocking, plan regressions, CPU spikes, TempDB pressure or unexplained slowdowns following releases, data growth or workload changes.
Performance changes over time
A SQL Server workload that performed well before may not perform well today
Data volumes grow. Statistics change. Indexes and application code change. SQL Server may choose different execution plans as parameter values and workload patterns shift. Infrastructure, concurrency and maintenance windows can change too.
Reactive investigation
Use the review to investigate an existing slowdown, blocking problem, timeout pattern or unexplained change in workload behaviour.
Before a known peak
Review current evidence before month-end, seasonal demand or another period where additional workload may expose existing weaknesses.
Evidence-led investigation
What the SQL Server Performance Review examines
The investigation follows the symptoms and available evidence rather than running a fixed checklist. Depending on the problem, the review can examine:
Query Store
Runtime history, regressions, plan changes and workload behaviour over time.
Execution plans
Estimates, join choices, memory grants, spills and other plan behaviour relevant to the reported problem.
Waits and concurrency
Blocking, workload contention and waits that help explain where work is spending time.
Server resources
CPU, memory, I/O and TempDB pressure where they contribute to workload performance.
Query-level measurements
STATISTICS IO, STATISTICS TIME and other available measurements that help quantify query behaviour.
Recent changes
Releases, indexes, statistics, compatibility level and relevant configuration changes that may explain altered behaviour.
Questions answered
Questions the Performance Review is designed to answer
The aim is not to produce a long list of observations. The review is intended to answer the questions that determine what should happen next.
Is the problem query design, indexing, statistics, configuration, concurrency or capacity?
Which queries or workloads are contributing most to the performance problem?
Which changes are most likely to produce measurable improvement?
Which changes can be made safely now, and which require further testing?
If the problem is intermittent, what evidence should be captured when it happens again?
Deliverables
What you receive
The output is designed to give your team a clear view of what is contributing to the performance problem, what should be addressed first and how proposed changes can be validated.
Prioritised findings
Findings are ranked by their likely contribution to the performance problem and the value of addressing them.
Supporting evidence
Significant findings are tied back to relevant Query Store data, execution plans, waits, blocking information or other available evidence.
Recommended actions
Recommendations explain what should be tested or changed, why it is being recommended and any important implementation considerations.
Validation steps
Where practical, recommendations include how to confirm whether a change produced the intended improvement.
Review discussion
The findings can be reviewed with your team to clarify priorities, answer technical questions and agree appropriate next steps.
Need help with the investigation?
Turn the evidence into a clear next step
If the symptoms are already affecting users or the cause remains unclear, a SQL Server Performance Review can help establish what is happening, what matters most and what should be tested next.
Discuss a Performance ReviewThe review process
How the SQL Server Performance Review works
The investigation follows the performance problem rather than a fixed checklist. Evidence is collected, correlated and prioritised before recommendations are made.
Define the problem
Establish what is slow, when it happens, what is affected and whether anything changed around the same time.
Collect the relevant evidence
Agree the least intrusive way to collect the SQL Server evidence required for the investigation, taking account of what is already available.
Analyse the workload
Correlate Query Store, execution plans, waits, blocking, resource pressure and recent changes with the reported symptoms.
Prioritise the findings
Rank findings by likely impact, confidence and practicality so effort is focused on the changes most likely to improve performance.
Review the recommendations
Review the evidence, priorities and recommended actions, including anything that requires further testing or additional evidence.
Choosing the right service
SQL Server Performance Review vs SQL Server Health Check
Both services examine SQL Server, but they start from different questions. The right choice depends on whether you are investigating a specific performance problem or looking for a broader assessment of the SQL Server environment.
Performance Review
Start with a known performance problem
Use a Performance Review when users are experiencing slow queries, blocking, timeouts, plan regressions or unstable workload behaviour and you need to understand why.
Health Check
Start with a broader SQL Server assessment
Use a Health Check when you want to identify configuration, maintenance, recoverability and operational issues across the SQL Server environment, whether or not a specific performance incident is occurring.
| Area | Performance Review | Health Check |
|---|---|---|
| Starting point | Known performance symptom or workload concern | Broader assessment of SQL Server condition |
| Primary question | Why is this workload slow or unstable? | What needs attention across the environment? |
| Query analysis | Deep where relevant to the reported problem | Broader identification of query-related issues |
| Blocking, waits and plans | Core investigation areas where relevant | Reviewed in the context of overall SQL Server health |
| Backups and recovery | Only where relevant to the performance issue | Core assessment area |
| Maintenance | Only where relevant | Core assessment area |
| Configuration | Performance-related configuration | Broader SQL Server configuration |
| Output | Evidence-backed findings and tuning priorities | Prioritised health, configuration and operational findings |
Choose a Performance Review when something is slow. Choose a Health Check when you want a broader assessment of what needs attention.
Looking for the broader assessment? View the SQL Server Health Check.
Next steps
What happens after the Performance Review?
The review is focused on diagnosis, evidence and prioritised recommendations. What happens next depends on the findings and how your team wants to proceed.
Implement internally
Some recommendations may be straightforward for your own team to test, approve and implement through your normal change process.
Test before changing
Other recommendations may require further testing, application involvement, change control or additional evidence before they should be introduced into production.
Further assistance
If you would like DatAIbase to help implement or validate recommended changes, that work can be scoped separately.
No production change is assumed as part of the Performance Review. Recommendations should be tested and introduced through your normal change-management process.
Frequently asked questions
SQL Server Performance Review FAQ
Common questions about scope, access, evidence and what to expect from the review.
What is a SQL Server Performance Review?
A SQL Server Performance Review investigates a known or suspected performance problem using evidence from the workload and SQL Server environment. The aim is to identify likely causes, contributing factors and the changes most likely to improve performance.
What is the difference between a Performance Review and a Health Check?
A Performance Review starts with a performance symptom such as slow queries, blocking, timeouts or workload instability and investigates why it is happening. A SQL Server Health Check takes a broader look at configuration, maintenance, recoverability and operational issues that may need attention.
Do you need access to our production SQL Server?
Not necessarily. The appropriate collection method depends on the problem, the evidence already available and your security requirements. The required access and data-collection approach are agreed before the investigation begins.
Can you investigate an intermittent SQL Server performance problem?
Yes, although the quality of the diagnosis depends on the evidence available from the period when the problem occurred. Query Store, monitoring data, waits, blocking information and execution plans may provide useful historical evidence. If the available evidence is insufficient, the review can identify what should be captured during the next occurrence.
Does the Performance Review include making changes to production?
No production changes are assumed as part of the review. The service focuses on investigation, evidence and recommendations. If DatAIbase assistance is required to implement or validate changes, that work can be scoped separately.
What information is useful before the Performance Review starts?
Useful context includes what users or applications are experiencing, when the problem occurs, which systems are affected, whether the behaviour is repeatable, and any application, infrastructure or SQL Server changes made around the time the problem began.