Monitor, Configure, and Optimize Database Resources
Where the numbers come from
- Query Store records query text, plans, runtime statistics, and waits. It is on by default for Azure SQL and is a prerequisite for Automatic Tuning (CREATE INDEX, DROP INDEX, FORCE LAST GOOD PLAN) and automatic plan correction.
- DMVs:
sys.dm_db_resource_stats(roughly 15-second samples for the last hour),sys.dm_user_db_resource_governance(your tier's caps),sys.dm_exec_requestsand blocking chains,sys.dm_db_wait_stats. - Azure Monitor: platform metrics (CPU percent, DTU/vCore percent, log write percent, storage), diagnostic settings to Log Analytics, and metric alerts for proactive paging.
Reading the signal
Identify the dominant wait type first. High CPU with SOS_SCHEDULER_YIELD or PAGEIOCP points at compute; PAGEIOLATCH_* points at storage; LCK_* points at blocking; RESOURCE_SEMAPHORE points at memory grants. On Azure SQL, throttling waits such as log-rate limits usually mean you have hit the service tier ceiling, not that the query is wrong.
Traps
- DMV counters reset on service restart and on failover; capture a baseline before diagnosing.
- Query Store set to READ_ONLY silently stops collecting, so Automatic Tuning quietly does nothing.
- Index maintenance thresholds: reorganize between 5 and 30 percent fragmentation, rebuild above 30 percent. Rebuilding tiny tables nightly is wasted work.
Rule of thumb
Pinned CPU plus scheduler waits → scale up or fix the top query. Storage waits with a modest data file → check the tier's IOPS and log-throughput limits before rewriting code.