Anonymized SQL Server performance engagement
How a 5–6 hour reporting workload became a predictable 45-minute run.
The platform did not need to be replaced. It needed a careful baseline, a clear diagnosis, and targeted changes to the workload creating the delay.
01 • Situation
The nightly job had become a morning problem.
A SQL Server reporting workload regularly needed 5–6 hours to finish. As data volume and query complexity grew, jobs began spilling into business hours. Reports arrived late, downstream teams waited, and larger compute was being used to compensate for a workload nobody had fully measured.
Business impact
- Reports were not consistently ready before the workday.
- Downstream processes inherited late or partial data.
- Support teams spent mornings checking job status.
Technical symptoms
- CPU frequently reached 80–90% during the reporting window.
- Several queries performed broad scans and repeated work.
- Schedules overlapped and amplified resource pressure.
02 • Diagnosis
Start with evidence, not guesses.
The investigation used runtime history, wait patterns, execution plans, table access patterns, job sequencing, and resource utilization. That separated the visible symptoms from the small number of workload paths creating most of the delay.
- Baseline: Capture runtime, CPU, reads, waits, and plan behavior over several representative nights.
- Hotspots: Identify the queries and tables consuming the largest share of the reporting window.
- Dependencies: Map job overlap, downstream timing, and safe sequencing constraints.
- Cost: Compare current compute with the resources the tuned workload would actually require.
03 • Changes
Fix the workload before replacing the platform.
The result came from several coordinated changes. There was no magic index and no single query rewrite that accounted for the entire improvement.
Query and index work
- Removed non-sargable filters from key date predicates.
- Returned only the columns the report needed.
- Reduced repeated subquery work and unnecessary scans.
- Added focused indexes for validated access patterns.
Workload and operations
- Batched large operations to reduce resource spikes.
- Realigned schedules to avoid avoidable overlap.
- Added runtime and failure monitoring.
- Created rollback guidance and operational handoff notes.
04 • Simplified query pattern
Make the predicate usable, then return only what is needed.
The following SQL is a simplified illustration of patterns addressed during the engagement. It is not the client’s production code.
SELECT *
FROM Orders
WHERE CONVERT(date, OrderDate) = '2025-01-31'
AND CustomerId IN (
SELECT CustomerId
FROM Customers
WHERE Country = 'US'
)
AND Status <> 'Cancelled';
SELECT o.OrderId,
o.OrderDate,
o.CustomerId,
o.Status
FROM dbo.Orders AS o
JOIN dbo.Customers AS c
ON c.CustomerId = o.CustomerId
WHERE o.OrderDate >= '2025-01-31'
AND o.OrderDate < '2025-02-01'
AND c.Country = 'US'
AND o.Status <> 'Cancelled'
AND o.Status IS NOT NULL;
- The date range can use an appropriate index on
OrderDate. - The select list avoids moving and processing unused columns.
- The direct join makes the relationship and access pattern explicit.
- The status predicate preserves the intended handling of null values.
05 • Validated outcome
The real improvement was predictability.
| Measure | Before | After |
|---|---|---|
| Nightly reporting runtime | 5–6 hours | Approximately 45 minutes |
| Peak CPU during heavy windows | Often 80–90% | Approximately 40–50% |
| Report availability | Frequently spilled into business hours | Consistently ready before business hours |
| SQL tier cost | Over-provisioned for unstable peaks | Estimated $1.5K–$4K monthly reduction |
Reports were ready before the workday, support staff had useful monitoring, and the environment no longer needed excess compute as insurance against an unpredictable reporting window.
Important context
- Client, schema, and workload details are intentionally anonymized.
- The SQL example is simplified to demonstrate the tuning pattern without exposing production code.
- Cost savings depend on platform, region, pricing model, tier, and the ability to right-size safely.
- These results describe one engagement and are not a guarantee of identical results in another environment.
Is the nightly workload becoming tomorrow morning's problem?
Start with the symptoms. I will help determine whether a focused diagnostic makes sense.