# Databases Queries Performance

**Purpose:** The slowest queries in the estate. A ranked chart of the top thirty by average elapsed time, over a grid carrying execution counts and total, last, and average elapsed time per query.

![Databases Queries Performance chart of the top thirty queries by average elapsed time above a detail grid with execution counts and elapsed times](https://visualoneintelligence.com/wp-content/uploads/2026/08/voi-docs-db-queries-performance.png)

## When to use it

- Find the queries consuming the most database time
- Distinguish a slow query from a frequently-run moderate one
- Give a DBA a starting point backed by measured elapsed time
- Check whether a tuning change moved the average

## Key areas and metrics

- **Chart.** Top thirty by average elapsed time in seconds, one bar per query name, with an export menu.
- **Grid.** Device Name, Instance Name, Database Name, Device Type, Query Name, Execution Count, Total Elapsed Time (Sec), Last Elapsed Time (Sec), Average Elapsed Time, and Join Count. Record counts run into the tens of thousands.

## Total time matters more than average

The chart ranks by average elapsed time, which finds individually slow statements. It does not find the queries costing the estate the most time overall. A statement averaging half a second and running a million times a day consumes far more database time than one averaging five minutes and running twice.

Sort the grid by Total Elapsed Time instead. That is the ranking that identifies where tuning effort pays back, and it frequently surfaces queries that never appear in the chart at all. Use Execution Count alongside it to tell a genuinely expensive statement from a frequently-run cheap one.

## Long-running system procedures crowd the chart

Some platform-internal procedures are designed to run for a long time. Mail and queue readers, agent pollers, and similar background routines sit blocked waiting for work, and their elapsed time reflects a polling interval rather than a performance problem.

Because they wait by design, they can occupy most or all of a top-thirty-by-average chart, pushing every real finding off it. A chart showing the same procedure name repeated across nearly every bar, all at a similar round-numbered duration, is this pattern rather than an estate-wide crisis. Filter the known system procedures out before reading the chart, or work from the grid sorted by total elapsed time.

## Common actions

- **Sort the grid by Total Elapsed Time descending** as the default view rather than trusting the chart order.
- **Filter out system and agent procedures** so application queries are visible.
- **Read Join Count on the worst offenders.** A high join count with long elapsed time points at a query structure problem rather than a missing index.
- **Group by Database Name** to attribute database time to an application.

## Tips

> These figures come from the platform's own query statistics, which reset on restart. Note instance uptime before comparing totals across instances, because a recently restarted server will look far healthier than one up for months.

## Related screens

[Missing Indexes](https://visualoneintelligence.com/docs/databases-missing-indexes/) often explains a slow query, and carries the optimizer's own suggested fix. [Index Fragmentation](https://visualoneintelligence.com/docs/databases-index-fragmentation/) covers the case where the index exists but has degraded. [Health Alerts](https://visualoneintelligence.com/docs/databases-health-alerts/) raises wait-time conditions from the same underlying data.

---

Source: https://visualoneintelligence.com/docs/databases-queries-performance/