Queries

The Queries tab provides details on aggregated queries.

The Queries tab provides a performance overview of queries running on the instance you selected and over the time range you selected.

Active sessions

Screenshot of the Queries tab

Active Sessions (Aggregate) is a time series, sliced by wait types (CPU, memory, network), of currently active database sessions.

This time series indicates the overall level of activity and concurrency on the database within a specific timeframe. If the number of active sessions is relatively low, the server is not heavily loaded in terms of concurrent queries. A dominance of the purple bar in the graph (CPU) suggests that when sessions are active, they are often consuming CPU rather than waiting on I/O or locks.

Tip:

Actions you can take:

  • Since queries are sorted by total duration, you can immediately see which queries take the longest.
  • Monitor this tab to identify session spikes or unusual activity that may impact performance.
  • Toggle the visibility of wait types by selecting them in the legend.
  • Track CPU usage to detect resource bottlenecks and optimize workload distribution.
  • Track memory waiting to ensure that this instance has sufficient memory and to troubleshoot memory pressure issues.

Queries and stored procedures

The table at the bottom of the page displays what's running on the instance you selected and over the time range you specified, depending on which tab you select at the top of the table:

Queries

Screenshot of the Stored procedures tab

The Queries tab displays the top queries sorted in descending order of total duration, along with metrics like Executions, Total Duration, Avg. Duration, Total CPU time, Avg. active sessions, and a visual representation of Wait states. This table is crucial for identifying specific queries that are influencing performance.

  • Executions: Number of times the database engine ran this query in the time range you specified.
  • Procedure ID: Stored procedure ID, if applicable.
  • Procedure Name: Stored procedure name, if applicable.
  • Total Duration: The cumulative time spent by the database executing this query across all its runs in the selected time window. High total duration indicates a query that contributes significantly to the overall database workload time.
  • Avg. Duration: The average time it takes for a single execution of the query. High average duration indicates a slow query.
  • Total CPU time: The cumulative CPU time consumed by the query across all its runs. High CPU time indicates a CPU-intensive query.
  • Avg. active sessions: The average number of sessions that were active while this specific query was running. This can help identify queries that cause blocking or high concurrency issues, although in this view, it seems low for most queries.
  • Wait states: The visual bar shows the breakdown of time spent by the query in different states (CPU, waiting on I/O, network, locks, and so on). A long bar indicates a query taking a significant amount of time, and the color breakdown shows why it's taking time.
Tip:

Actions you can take:

  • View query details by selecting that query in the table. This opens a flyout containing more information about that query.
  • Copy a query by hovering over it and selecting its copy icon.
Stored procedures

Screenshot of the Stored procedures tab

The Stored Procedures tab displays the reusable, named database objects of type "procedure", which are collections of queries and logic that are stored directly within a database engine. A stored procedure serves as a discrete unit of execution for granular performance monitoring and observability.

Note: This tab is only available for Oracle Database and Microsoft SQL Server instances.
  • Stored Procedure: Stored procedure name.
  • Procedure ID: Stored procedure ID.
  • Executions: Number of times the database engine ran this stored procedure in the time range you specified. The accuracy of this count varies based on the procedure's pattern, especially for Oracle Database where stored procedure execution count is a "best effort" estimate.
  • Total Duration: The cumulative time spent by the database executing this query across all its runs in the selected time window. High total duration indicates a query that contributes significantly to the overall database workload time.
  • Avg. Duration: The average time it takes for a single execution of the query. High average duration indicates a slow query.
  • Total CPU time: The cumulative CPU time consumed by the query across all its runs. High CPU time indicates a CPU-intensive query.
  • Avg. active sessions: The average number of sessions that were active while this specific query was running. This can help identify queries that cause blocking or high concurrency issues, although in this view, it seems low for most queries.
  • Wait states: The visual bar shows the breakdown of time spent by the query in different states (CPU, waiting on I/O, network, locks, and so on). A long bar indicates a query taking a significant amount of time, and the color breakdown shows why it's taking time.
Tip:

Actions you can take:

Select a stored procedure to view a flyout containing details on the queries that are included in that procedure. In the flyout, the information displayed (execution times, explain plans, and so on) are specific to the queries themselves, not to the stored procedure as a whole.

Query details

Select a specific query in the query table to navigate to a flyout which provides details about that query:

Query statement

Query statement displays a normalized form of the query you selected.

A normalized query is the common pattern of a group of queries which differ only in their specific parameter values. By representing a group of queries by a single normalized query, Database Monitoring reduces the cardinality of unique queries, making it easier to track performance trends, identify slow or frequently executed query patterns, and prevent sensitive data from being exposed.

Explain plans
A screenshot of a query plan.

The Explain plans tab provides a detailed sequence of operations a database will perform to run a query, outlining how data will be accessed (for example, full table scan, index scan), the order and type of JOIN operations for multiple tables, and how filtering, sorting, and aggregation will be processed. Additionally, it includes estimated costs for each step and the overall query, representing the anticipated resource usage, along with the estimated number of rows the database expects to process at each stage.

Metrics
A screenshot of aggregated metrics for top queries.

The Metrics tab displays metrics aggregated for top queries but without the support for displaying top 10 queries.

Query samples
A screenshot of a query sample.

The Query samples tab displays samples collected when this query was running.

Traces
A screenshot of traces that contain a sample query.

The Traces tab lists the traces that contain this query. Traces come from sampled queries. Select a trace to navigate to the Splunk APM Trace Analyzer. This helps you to identify the sources of problematic queries.

Note: Traces that are less than 3 minutes old might be visible on the Traces tab but not yet visible on the Splunk APM Trace Analyzer. In this case the Trace Analyzer displays No trace found. Wait a few minutes and refresh the page.