Wait Events Statistics
The Wait Events Statistics section of the AWR report shows which wait events sessions experienced most frequently during the report period. It is the AWR equivalent of the ASH wait event distribution — but computed from snapshot-level aggregates rather than individual samples.
{screenshot: awr-wait-events-section}
Data Source
Wait event statistics are derived from ASH samples aggregated into the snapshot history tables. The counts represent the number of ASH samples observed with each wait event between the begin and end snapshots.
Wait Events Table
| Column | Description |
|---|---|
| Rank | Position by sample count |
| Wait Event Type | Category (Lock, IO, IPC, Client, Timeout, Other) |
| Wait Event | Specific event name |
| Samples | Number of ASH samples with this wait event |
| % of Total Waits | Proportion of all wait samples |
| % of DB Time | Proportion of total DB Time |
{screenshot: awr-wait-events-table}
Wait Event Categories
| Type | Description | Common Events |
|---|---|---|
| Lock | Waiting for a database lock | relation, transactionid, tuple |
| IO | Waiting for disk I/O | DataFileRead, WALWrite, BufFileRead |
| IPC | Inter-process communication | BgWriterHibernate, RecoveryConflict |
| Client | Waiting for client | ClientRead, ClientWrite |
| Timeout | Time-based waits | PgSleep, RecoveryApplyDelay |
| CPU | No wait — actively on CPU | (healthy state) |
Reading the Results
Predominantly CPU
If the majority of DB Time is attributed to CPU (no wait), the instance is CPU-bound. This is generally healthy for compute-intensive workloads, but may indicate missing indexes or suboptimal query plans if unexpected.
High Lock Waits
Lock waits indicate contention between concurrent sessions. Combine this with the Lock Contention section to identify the specific blocking queries.
High IO Waits
I/O waits on DataFileRead suggest data is being read from disk rather than the buffer cache. Consider increasing shared_buffers or reviewing index coverage.
High WALWrite Waits
Sessions waiting on WALWrite indicate the WAL subsystem is a bottleneck. This may be caused by slow disk I/O on the WAL volume or synchronous_commit = on under heavy write load.