What are wait events?
In the Oracle world, if you want to know why your database is slow, you don't look at what it's doing—you look at what it’s waiting for.
Wait Events are the breadcrumbs Oracle leaves behind every time a process has to pause. Whether it’s waiting for a piece of data to arrive from the disk, a lock to be released by another user, or even just waiting for the network to send a message, Oracle logs that "pause" as a Wait Event.
Oracle breaks down a session's total time into a very simple equation:
Total Time = CPU Time + Wait Time
CPU Time: The database is actively "thinking" (calculating, sorting in memory, parsing code).
Wait Time: The database is "idling," waiting for an external resource to become available.
If your database is slow but CPU usage is low, you are likely suffering from high Wait Time.
Not all waits are bad. We categorize them into two groups:
These mean the database is waiting for "more work" to do. They are generally ignored during performance tuning.
Example: SQL*Net message from client. This just means the database is waiting for the user to type their next command.
These are the "Red Flags." They indicate a bottleneck that is preventing work from finishing.
Example: db file sequential read. The database is waiting for the hard drive to find a specific block of data.
If you look at a performance report (AWR or ASH), you will almost always see these three:
| Wait Event | What it means | Common Root Cause |
| db file sequential read | A single-block read from disk. | Usually a search using an Index. If this is high, your indexes are working, but maybe your disk is slow. |
| db file scattered read | A multi-block read from disk. | Usually a Full Table Scan. The database is "scattering" blocks into memory. |
| log file sync | Waiting for the Redo Log to write to disk. | You are committing too often (e.g., inside a loop) or your transaction logs are on slow disks. |
You can see wait events in real-time or in history using these Dynamic Performance Views:
V$SESSION_WAIT: Shows what every user is waiting for right this second.
V$SYSTEM_EVENT: A "Scoreboard" showing every wait event that has occurred since the database started.
V$SESSION_EVENT: Shows wait events accumulated for a specific user session.
Wait events turn "guessing" into "science."
If you see enq: TX - row lock contention: Don't buy a faster server. Talk to your developers about why two users are trying to update the same row at the same time.
If you see buffer busy waits: You have multiple people fighting for the same "hot" block in memory. You might need to spread your data across more blocks.
If you see latch: library cache: Your application isn't using Bind Variables, and the database is struggling to keep up with all the unique SQL statements.
Wait events are the language of the database. Instead of saying "it's slow," a professional DBA says, "We are seeing a 40% increase in db file sequential read latency." This level of detail allows you to target the exact hardware or code path that is causing the delay.
In 2026, with the speed of modern NVMe drives and massive RAM, many traditional "Disk" wait events are disappearing, only to be replaced by "Memory" and "Concurrency" waits. Understanding these events is the only way to stay ahead of the performance curve.