4.5 Database Observability: The Databases App, Connection Pools & Storage Latency
Key Takeaways
- The official Associate learning path explicitly directs candidates to improve database performance and to use the Databases app, making database observability part of the scored Infrastructure Observability topic.
- Dynatrace models a database from two directions: as an infrastructure host or service running the engine, and as a database service consumed by application services through PurePath.
- Connection pool sizing must respect the database's own maximum connection limit; an oversized pool converts an application bottleneck into a database-wide outage.
- High disk latency is a primary cause of reduced database performance, and caching or a faster storage class is the standard remediation.
- Database problems that show low CPU on both the application host and the database host almost always point at lock contention, slow statements, or storage latency rather than compute capacity.
Databases sit exactly on the seam between infrastructure and application observability, and the Associate learning path treats them as part of Monitoring & Infrastructure Observability — its call-to-action instructs candidates to open the Databases app and capture the findings in a Notebook. Section 6.3 covers the service-side view: which SQL statement a PurePath executed and how long it took. This section covers the infrastructure-side view: whether the database tier itself is healthy.
Keeping the two straight is the whole exam skill. A slow query and a starved database host produce very similar application symptoms and require completely different fixes.
Two Views of the Same Database
| View | Entity in Dynatrace | Answers |
|---|---|---|
| Infrastructure view | The host running the engine, plus its processes | Is the machine starved of CPU, memory, or disk I/O? |
| Service view | A database service consumed by application services | Which statements are slow, how often are they called, and from where? |
The Databases app brings these together, presenting each monitored database with its throughput, response time, failure rate, top consumers, and the slowest statements — alongside the health of the host that runs it.
A crucial modelling point: Dynatrace detects a database service even when OneAgent is not installed on the database host. The instrumented client process reports the outbound call, so you get statement-level visibility into a managed cloud database such as Amazon RDS or Azure SQL that you cannot install an agent on. What you do not get in that case is host-level CPU, memory, and disk metrics for the engine — which is exactly why cloud integrations (Chapter 13) matter for managed database tiers.
Connection Pools: The Most Common Self-Inflicted Outage
An application connects through a connection pool — a fixed set of reusable connections. Two sizing questions matter, and the official guidance ties them together: when configuring an application's connection pool you must consider both the maximum number of connections the database can handle and the pool size the application needs to avoid a bottleneck.
Pool too small. Threads queue waiting for a free connection. In a PurePath this shows as time spent before the SQL statement executes — the statement itself is fast. The symptom is rising response time with a database that looks completely idle.
Pool too large. This is the dangerous direction. Suppose a database engine accepts 500 connections, and an application is scaled to 40 pods each configured with a maximum pool of 20. That is a potential 800 connections against a 500-connection ceiling. Under load the database begins refusing connections, and the failure hits every application sharing that database, not just the one that was over-provisioned. The exam framing is that an oversized pool converts a single application's bottleneck into a shared-tier outage.
The correct sizing rule is that the sum of all client pool maximums across every instance must stay below the database's connection limit, with headroom for administrative sessions and replication.
Storage Latency and Caching
Databases are the workload most sensitive to storage performance. High disk latency directly reduces database performance, and the standard remediations are to introduce or enlarge caching so that hot reads never reach disk, and to move the data volume to faster storage.
The diagnostic pattern to memorize:
- Application host CPU: normal
- Database host CPU: normal
- Database host disk write/read latency: elevated
- Statement execution times: uniformly inflated across many different queries
When many unrelated statements slow down together, the cause is the storage layer or a global lock, not any one query. When one statement slows down while others are unaffected, the cause is that statement — a missing index, a changed execution plan, or a data-volume growth threshold.
Lock Contention
Lock waits produce the counter-intuitive signature of a database that is slow while every hardware metric is comfortable. CPU is low precisely because sessions are blocked and doing no work. Dynatrace surfaces this as long database-service response times with low throughput, and the PurePath shows the calling thread parked inside the database call. The remediation is transactional — shorter transactions, appropriate isolation levels, or indexing to reduce the range a lock covers — never adding CPU.
A Worked Triage
An order service degrades from 220 ms to 1.9 s. Investigate in this order:
- Is time being spent in the database at all? Open the PurePath. If most of the elapsed time is in-process code, the database is innocent (Chapter 6.2).
- Is it one statement or many? One statement → statement-level problem. Many → tier-level problem.
- If tier-level, which resource? Check the database host's disk latency, available memory, and connection counts in the Databases and Infrastructure & Operations apps.
- If none of the hardware is constrained, suspect lock contention or connection-pool exhaustion — both present as waiting, not working.
This ordering matters on the exam because distractor answers usually offer a plausible fix at the wrong layer: adding database CPU when the problem is an unindexed query, or rewriting a query when the problem is a saturated connection pool.
A microservice is scaled to 40 pods, each configured with a maximum database connection pool of 20. The backing database engine accepts a maximum of 500 concurrent connections. During a traffic peak, several unrelated applications sharing that database begin receiving connection errors. What is the underlying problem?
A reporting database becomes slow. Dynatrace shows normal CPU and memory on both the application and database hosts, but many different, unrelated SQL statements have all roughly doubled in execution time. Which cause best fits this pattern?
An application team migrated to a fully managed cloud database with no ability to install OneAgent on the database servers. What database visibility does Dynatrace still provide?