Azure SQL Monitoring Made Easy

Azure SQL Monitoring Made Easy: Utilization, Long Queries & Performance (High Level Overview)

In this blog, I’ll walk you through how I personally analyze Azure SQL Database and the key metrics that matter when diagnosing performance issues or preparing high-level utilization reports.

This guide is simple, practical, and works whether your apps run on Azure VMs, App Services, or Kubernetes.

1. Checking Azure SQL Utilization

The first thing I check is Azure SQL’s resource consumption. These metrics help identify whether the database is under stress due to CPU, storage, or IO pressure.

Navigate to Azure Portal → SQL Database → Monitoring → Compute Utilization → Add Metric

1.1 CPU %

Where: Add metric → CPU percentage

CPU% shows how much compute your workload consumes

CPU % in Azure SQL Database is calculated based on the compute you have provisioned under Compute & Storage. For example, if the CPU utilization shown in the above image is 46%, and the database is allocated 10 vCores, then the workload is effectively using the equivalent of about 4.6 vCores.

When CPU % Becomes a Problem

CPU %	Meaning
0–60%	Healthy and normal workload
60–80%	Getting busy; monitor slow queries
80–90%	Warning zone; potential throttling soon
100%	CPU capped — queries will slow down

How to Fix High CPU

Add proper indexes
Update statistics
Rewrite queries to be more efficient
Avoid SELECT *
Reduce unnecessary joins
Enable Query Store and analyze top CPU consumers
Scale up temporarily if needed

Checking CPU % via Query

At backend dm_db_resource_stats is the table from where CPU % is collected

SELECT end_time, avg_cpu_percent FROM sys.dm_db_resource_stats ORDER BY end_time DESC;

Below is the output of the above query once its executed. Please note - if the database is newly created or idle the query will result nothing

1.2 I/O Metrics: Log IO & Data IO

Azure SQL Database I/O metrics help you understand how your database handles read and write operations. There are two key metrics:

Log IO: Measures transaction log activity (writes of INSERT, UPDATE, DELETE operations).
Data IO: Measures read/write operations on database data files (table reads, index scans, data writes).

Difference: Log IO focuses on transaction log usage, affecting commit latency, while Data IO measures actual data file access, affecting query and read performance.

1.2.1 Log IO

Where: Add metric → Log IO percentage

High Log IO can lead to delayed commits and transaction latency.

Log IO %	Meaning
0–50%	Normal write workload
50–70%	Moderate write activity; monitor transactions
70–90%	High writes; potential delays in commits
90–100%	Transaction log heavily used; DB may hit limits

How to Control High Log IO

Batch multiple small inserts/updates
Avoid unnecessary indexes on write-heavy tables
Minimize triggers or cascading updates
Use proper transaction sizes
Optimize temp/staging tables for heavy writes
Scale DB if write volume is high

SELECT end_time, log_write_percent FROM sys.dm_db_resource_stats ORDER BY end_time DESC;

Note: New or idle databases may return no rows.

1.2.2 Data IO

Where: Add metric → Data IO percentage

Data IO reflects the rate at which your database reads/writes data files, impacting query performance.

Data IO %	Meaning
0–50%	Normal read/write activity
50–70%	Moderate activity; monitor queries
70–90%	High activity; potential query latency
90–100%	DB reaching I/O limits; consider scaling or optimization

How to Control High Data IO

Optimize queries to reduce unnecessary reads

Ensure proper indexing for frequent queries

Reduce large table scans

Partition large tables if necessary

Use caching where possible

Scale DB if read/write volume is consistently high

SELECT end_time, avg_data_io_percent FROM sys.dm_db_resource_stats ORDER BY end_time DESC;

Again, new or idle databases may return no rows.

2. Identify Long-Running Queries

Navigate to Azure Portal → SQL Database → Intelligent Performance → Query Performance Insight → Long running queries

Inside this bashboard, I always look for:

High Duration
Slow queries

Execution Count
Number of times query is called

High Reads/Writes
Storage-heavy queries

Long-running queries often cause high CPU, Log IO, or Data IO. Detecting them quickly helps optimize database performance. I use long running queries dashboard most frequently because this dashboard shows the Query ID, Log IO and Data IO consumed by query and its number of executions all at one place

Azure Portal Dashboard:

Use Query Performance Insight to find queries with high duration, CPU usage, or read/write activity. Below is an example of a query running for ~3 hours:

Now you can also get the actual query from the query id, by simply entring below command in your SQL DB

SELECT query_sql_text FROM sys.query_store_query_text WHERE query_text_id = (SELECT query_text_id FROM sys.query_store_query WHERE query_id = [query_id]);

Conclusion

In this blog, we explored some of the most crucial aspects of monitoring Azure SQL, including CPU usage, log I/O, data I/O, and long-running queries. These metrics provide a solid foundation for understanding database performance and identifying potential bottlenecks. However, Azure SQL offers a wide array of monitoring capabilities beyond what we’ve covered here. My goal was to focus on the key and primary metrics that have the most immediate impact, while leaving room for further exploration and deeper insights into the platform’s monitoring tools. Keeping an eye on these essential metrics is a great starting point for maintaining optimal performance and ensuring your database runs smoothly.

Search This Blog

Ranveer Codes & Writes !