I built a zero-login Docker lab to safely induce and decode Oracle wait events. Feedback wanted.
Most DBAs learn wait events backwards—from a dry list of definitions, or from an AWR report after a fire.
The concept finally clicked for me when I started causing them on purpose to watch their signatures live in v$session_event. I packaged these drills into a lightweight, throwaway lab environment so anyone can test cause-and-effect locally.
How it works:
- Runs on the community Oracle Database Free Docker image.
- No Oracle account or licensing required.
- Each script flushes the buffer cache.
- Runs a workload engineered to trip one specific wait.
- Prints the session's live
v$session_eventdelta. - Safe to run without a Diagnostics Pack license.
Current drills included:
db file sequential read(single-block index/rowid reads)db file scattered read(buffered multi-block full scan)direct path read(large scan bypassing cache into PGA)log file sync(row-by-row commit loop performance hit)
The logic check:
On fast local NVMe, wait times are tiny. The goal here is proving the structural shape and wait count behavior of the queries. For example, the commit drill runs 50,000 single-row inserts to show how high log file sync is a commit-frequency problem, not a slow disk issue. Moving the commit outside the loop collapses the wait count instantly.
I am genuinely curious where this setup might be too simplified, what edge cases it misses, and which specific wait event you think trips people up the most in production.
(GitHub link posted in the comments below to avoid spam filters).