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.

Nightly runtime5h → 45m
Peak CPU60% lower
Estimated monthly savings$1.5K–$4K

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.

  1. Baseline: Capture runtime, CPU, reads, waits, and plan behavior over several representative nights.
  2. Hotspots: Identify the queries and tables consuming the largest share of the reporting window.
  3. Dependencies: Map job overlap, downstream timing, and safe sequencing constraints.
  4. 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.

BeforeBroad and non-sargable
SELECT *
FROM Orders
WHERE CONVERT(date, OrderDate) = '2025-01-31'
  AND CustomerId IN (
      SELECT CustomerId
      FROM Customers
      WHERE Country = 'US'
  )
  AND Status <> 'Cancelled';
AfterFocused and index-friendly
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.

MeasureBeforeAfter
Nightly reporting runtime5–6 hoursApproximately 45 minutes
Peak CPU during heavy windowsOften 80–90%Approximately 40–50%
Report availabilityFrequently spilled into business hoursConsistently ready before business hours
SQL tier costOver-provisioned for unstable peaksEstimated $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.

Start a conversation