Finding Slow Database Queries in Java Services with Dynatrace OneAgent

You don’t always need a profiler to find a slow query

When a Java service starts lagging, the first instinct is often to add logging or attach a profiler. But if you’re already running Dynatrace OneAgent, you have a quieter option. OneAgent instruments Java bytecode as it loads, and every PurePath trace automatically includes database call boundaries. You don’t need to instrument JDBC, Hibernate, or your data access layer by hand.

How OneAgent surfaces slow SQL in PurePath

As a request flows through your service, OneAgent captures the full call stack. When a SQL statement executes, the trace records the statement text (or a placeholder), the elapsed time, and the underlying JDBC call. In the Dynatrace UI, statements that exceed a configurable duration threshold appear with a “slow” badge. You can click through to see the PurePath, filter by service, operation, or even the exact SQL text, and compare response times across invocations.

A worked example: tracing a slow query from symptom to root cause

1. Deploy OneAgent if not already present. On a Debian/Ubuntu host:

   sudo apt-get install -y dynatrace-oneagent

   Ensure the Java process is restarted so OneAgent can inject bytecode.
2. Run a representative request that triggers the suspected slow query. Example:

   curl -X GET https://your-service.example.com/orders?status=active

3. Open the PurePath in Dynatrace. Navigate to the Java service dashboard, select “View PurePath” for the request, and look for the “SQL” or “Database” section. Statements with above-average duration will be highlighted.
4. Inspect the slow statement. Click the highlighted SQL to view the query text (or a bind-variable placeholder if deep capture is disabled), duration, and the underlying host/metrics context. You can also open the “Problem” view to see if Davis AI has already flagged the slowdown.
5. Cross-check with the database. Run EXPLAIN ANALYZE <your query> directly on the DB to validate that the duration Dynatrace reports aligns with what the database actually executed. This confirms OneAgent’s timing isn’t skewed by network latency or client-side queuing.

Trade-offs and limits to keep in mind

Bytecode instrumentation isn’t free. On a busy production JVM, enabling high-detail PurePath capture can add measurable CPU overhead. If your environment has strict data-privacy rules, deep bind-variable capture may be disabled by default; Dynatrace will surface placeholders like ?1 = 'value' instead of the actual parameter values. Additionally, the exact UI path, sensor rule syntax, and default retention for detailed SQL traces vary between SaaS and managed deployments, and between Dynatrace versions. Custom or obscure data-access frameworks (e.g., myBatis-specific wrappers, JDBI extensions) may not be auto-detected and could require a manual sensor rule.

If you’re troubleshooting a Java service’s latency and already have OneAgent running, start by opening the PurePath for a representative request. Filter for SQL statements exceeding your baseline threshold, and use the built-in correlation to infrastructure metrics via Davis AI. For teams that need bind-variable visibility, check your environment’s data collection settings and consider a staged rollout to a non-production cluster first. The goal isn’t to replace database profiling, but to surface the slowest queries fastest—without touching a single line of code.