Database blocking queries and deadlocks in Dynatrace

• Latest Dynatrace
• Explanation
• Published Aug 26, 2026

Overview

Lock contention, blocking queries, and deadlocks are among the most common causes of database performance degradation. Databases surfaces lock and wait metrics from monitored database instances so you can detect contention early, identify the queries involved, and resolve issues before they affect application performance.

Key terms

To interpret the lock and wait metrics in Databases, it helps to understand how sessions compete for resources and where they end up waiting.

Blocking query

A session that holds a lock on a resource (row, page, or table) that another session needs. The waiting session is blocked until the lock is released or times out. A single long-running transaction can block many sessions at once, degrading throughput.

Deadlock

Two or more sessions each hold a lock the other needs, so none can proceed. The engine detects the cycle and terminates one session (the deadlock victim), which must retry. Blocking is a queue; a deadlock is a cycle.

Wait event

An engine signal that records why a session paused. Lock waits are one category; others include I/O, CPU scheduling, network, and latch contention. Analyzing wait events alongside blocking and deadlock metrics shows where the database spends time waiting rather than executing.

Alerts for lock contention

Create health alerts on lock and wait metrics to be notified when contention reaches a threshold. Use the Alert templates tab in Databases, or configure custom detectors in the . The Queries alert category covers queries that can cause blocking; DB instance activity covers downstream effects such as connection counts and availability.

For details, see Health alerts and warning signals.

Monitoring gaps

If lock or wait metric data is missing for a database instance, the Recommendations tab in Databases flags this under Check for monitoring gaps. Use this view to identify incomplete visibility and review what configuration changes are needed, for example, enabling the waitEvents feature set for Oracle or enabling Performance Schema instrumentation for MySQL or MariaDB.