An Azure SQL resource percentage tells you that a limit is being approached; it does not tell you why. High DTU, CPU, data I/O or log I/O can be caused by a single inefficient statement, a burst of concurrency, blocking, plan regression, maintenance work or a service tier that no longer fits the workload.
The goal of an effective investigation is to connect the Azure resource signal to the database activity that produced it. That gives you a choice between tuning the workload, changing its timing, correcting contention or scaling capacity—with evidence for the decision.
Understand what the service model is showing
In the DTU purchasing model, compute, data I/O and log I/O contribute to a bundled capacity measure. A high DTU percentage can therefore represent different underlying constraints at different times. In the vCore model, CPU and storage-related signals are more explicit, but a high percentage is still a symptom rather than a diagnosis.
Start with the exact database, time window and resource that reached pressure. Record whether the event was brief, sustained or repeated. Then compare it with the same database's normal workload rather than using an arbitrary threshold in isolation.
The Mini DBA Azure database monitoring page shows how Azure SQL resource metrics, waits, queries, alerts and history can be investigated in one browser workflow.
Separate CPU, data I/O and log I/O pressure
Each resource points to a different first set of questions:
- CPU pressure: Which queries consumed CPU? Did execution counts, parallelism or compilation rise? Did a plan change increase the work per execution?
- Data I/O pressure: Which statements performed large reads? Was a scan expected? Did cache churn, missing indexes or a reporting workload increase physical access?
- Log I/O pressure: Did transaction volume, batch size, index maintenance or a long transaction increase log generation? Were applications committing unusually frequently?
When several percentages rise together, do not assume several independent problems. One badly estimated query can consume CPU, read far more pages than expected and generate tempdb or log activity at the same time.
Find the queries active during the spike
Rank queries by the resource that was constrained, then inspect execution count and duration. A query that is moderately expensive but runs thousands of times can matter more than the single longest execution. Conversely, a reporting statement or maintenance operation may dominate a short incident even with a low execution count.
Compare SQL text and execution plans with an earlier healthy period. Look for changed join strategies, scans, spills, missing-index evidence, inaccurate estimates and parameter-sensitive behaviour. The Azure SQL queries view provides the workload detail needed to connect the platform metric to a statement.
Check waits and blocking before scaling
A database can feel slow without exhausting its purchased compute. Lock waits, blocked sessions and transaction contention can delay work while headline resource percentages remain moderate. Equally, blocking can create a queue that produces a resource surge when it clears.
Use Azure SQL wait analysis to identify whether the workload was waiting on CPU scheduling, storage, locks, log flushes or another resource. Review blocking chains and long-running transactions during the same interval. This prevents a scale-up from masking a concurrency problem that additional capacity will not solve.
Include elastic-pool context
For databases in an elastic pool, investigate both the database and the pool. One busy database can consume shared capacity and affect quieter neighbours. Check whether pressure aligns with activity elsewhere in the pool, whether workload schedules overlap and whether per-database limits are contributing.
A recurring pool-level incident may be resolved by workload scheduling, moving an outlier, changing pool capacity or tuning the database that drives the peaks. The right answer depends on the history, not just the current percentage.
Use history to distinguish a regression from growth
Compare the incident with the previous day and the same business period in earlier weeks. A sudden step change after a deployment suggests a plan or application regression. A gradual increase may reflect data growth, higher concurrency or a service tier approaching its intended limit. A predictable daily peak may be a reporting or maintenance schedule.
Useful comparisons include:
- resource percentage and absolute workload volume;
- top queries and their execution plans;
- wait distribution;
- blocking and transaction duration;
- database size, log generation and I/O;
- deployments, jobs and known business events.
Choose between tuning and scaling
Tune first when a small number of statements, a plan regression, avoidable scans, blocking or poor workload timing explains the incident. Scaling is reasonable when an efficient workload has genuinely outgrown the available capacity, when a temporary business event needs headroom or when tuning cannot meet the required response time within the operational window.
Scaling and tuning are not mutually exclusive. Temporary scaling can protect service while a durable query or application fix is prepared. Record the reason, expected outcome and review date so temporary capacity does not become an unexplained permanent cost.
Create alerts that lead to an investigation
Alert on sustained pressure and meaningful recurrence rather than every brief peak. Preserve enough query, wait and metric context to understand what was active when the threshold was crossed. The Azure SQL alert documentation covers the monitored alert workflow.
Mini DBA keeps Azure SQL history alongside query and wait evidence. Its AI Assistant can explain the selected metrics, alerts and execution-plan context and recommend practical diagnostic steps. Explore the online demo to see the investigation flow without installing software.