Oracle Waits shows wait information for a monitored Oracle server. Use it to understand what the workload is waiting on and where tuning effort should focus.
The Oracle Waits page includes the Mini DBA Time Range selector. Use Live for current wait evidence, or switch to Last Hour, Last 12 Hours, Last Day, Last Week, or Custom to review historical wait events and class summaries. Mini DBA loads and caches the selected historical waits dataset for the current console session and server context, so comparing the loaded wait period with activity, query, and memory evidence stays quick. Use Back to Live to resume live updates, then choose another historical range when you need a different incident window.
Oracle waits help explain why work is delayed. A slow request may be waiting for storage, locks, network activity, commit processing, memory-related operations, or another resource. The Waits page helps narrow the investigation so the next step is based on evidence instead of guesswork.
Look for wait classes or events that are dominant during the user-reported time window. If one SQL statement is tied to the waits, review it in Oracle Queries. If many sessions share the same wait pattern, investigate shared resources such as storage, contention, memory, or application concurrency. If the waits are current, use Oracle Activity to identify sessions and programs involved.
Waits are not automatically bad. Every active Oracle workload waits. The important questions are whether the wait pattern changed, whether it matches the incident, and whether it affects critical users or jobs.
No. Waits are normal. They become important when they dominate response time, increase unexpectedly, or align with application complaints.
They show whether a SQL statement is delayed by CPU alternatives, storage reads, locks, commits, or other resources, which guides the tuning approach.
Some wait patterns are influenced by cache, memory configuration, or workload shape. Oracle Memory provides supporting evidence.