What Is Runtime Analysis?
Runtime analysis compares SQL Server execution times and workload evidence to explain slow queries, procedures, and jobs.
Runtime analysis investigates how long SQL Server work takes and why that time changes. The work might be a query, stored procedure, or scheduled job; elapsed time alone rarely explains the cause.
Definition
Teams compare execution duration with a relevant history, then examine supporting evidence such as execution counts, query plans, waits, blocking, and resource usage. The goal is to separate a one-off slow run from a repeatable change that needs action.
How to investigate
- Identify the query, procedure, or job and the time window of the slowdown.
- Compare runs with similar parameters, data volume, and workload periods.
- Check whether duration, frequency, or both changed.
- Inspect plans, waits, blocking, and competing workloads before changing code or infrastructure.
Operational example
A reporting procedure rises from 20 seconds to two minutes after a release. Comparing runs shows that only one parameter value is affected. The team checks the plan and row estimates for that value before deciding whether the release, statistics, or data distribution caused the change.
Common pitfalls
An average can hide a few costly outliers, while a single slow run may simply coincide with maintenance. Use percentiles or run-level history where possible, and keep the comparison window and workload mix visible.
SQL Cockpit context
SQL Cockpit brings runtime history and operational context into one view so teams can spot unusual executions and investigate them alongside the rest of their SQL Server activity.
FAQ
Is runtime analysis the same as monitoring?
Monitoring shows that a run is slow. Runtime analysis uses history and related signals to explain the slowdown.
What is a useful first comparison?
Compare the same work against a stable period with similar load and parameters, then inspect the largest change.