Azure SQL Locks shows lock information for an Azure SQL database. Use it to investigate blocking, blocked sessions, and concurrency contention.
What You Can Review
- Locked resources.
- Database, object, index, and schema context.
- Lock mode and status.
- Session ID and request count.
Workflow
- Open Locks for the Azure SQL database.
- Review locked resources and sessions.
- Compare with Activity blocking and blocked tabs.
- Check Deadlocks for recurring conflicts.
- Use Query Store to identify related statements.
How To Investigate Azure SQL Locking
Start by identifying the blocking session and the locked object. A blocked session is the symptom, while the blocker is usually the first session to understand. Review the blocker SQL, transaction duration, lock mode, object name, and whether the pattern repeats.
Locking problems can be caused by missing indexes, long transactions, inconsistent object access order, isolation level choices, or application behavior. Use Query Store to identify repeated statements and Indexes to check whether the workload is scanning more data than necessary.
Azure SQL Locks FAQ
Are locks always bad?
No. Locks are normal. Long blocking chains, user-visible delays, and recurring deadlocks are the problems.
What permission helps Mini DBA show locks?
The monitoring user needs database performance visibility, especially VIEW DATABASE PERFORMANCE STATE.
What should I do before killing a session?
Confirm business impact, the query, transaction context, and whether the session is safe to terminate under your operational process.
Next Steps After Finding Locks
Lock evidence is most useful when it identifies the blocker, the blocked session, and the statement or object involved. Capture the time window and compare it with application activity, deployments, maintenance jobs, and long-running transactions. If the same lock pattern repeats, review transaction scope, indexing, isolation level, and retry behavior with the application team.