Skip to content

Oracle Performance Tuning Checklist — Step-by-Step Methodology

A systematic approach to Oracle database performance tuning. Follow this checklist to identify and resolve performance bottlenecks methodically.


Before tuning, capture the current state of the database.

Scripts to run:

What to record:

  • Top 5 wait events and their average wait times
  • Buffer cache hit ratio (target: >95%)
  • PGA memory usage vs. target
  • Active session count during peak hours
  • Average response time for key queries

Wait events tell you where Oracle is spending time.

Scripts to run:

Common wait events and actions:

Wait EventLikely CauseAction
db file sequential readPoor indexing or full table scansCheck execution plans, add indexes
db file scattered readFull table scansVerify query predicates, consider partitioning
log file syncCommit-heavy workloadBatch commits, check redo log I/O
buffer busy waitsHot blocksReverse-key indexes, hash partitioning
enq: TX - row lock contentionApplication lockingReview application logic
latch: shared poolHard parsingUse bind variables

Related errors:


Poor SQL is the most common cause of performance issues.

Scripts to run:

Tuning priorities:

  1. Highest CPU consumers — SQL using the most CPU time
  2. Most I/O intensive — SQL generating the most physical reads
  3. Most frequently executed — Even small improvements multiply across millions of executions
  4. Longest running — Long-running queries that block other operations

Common fixes:

  • Add missing indexes based on WHERE clause predicates
  • Replace SELECT * with specific column lists
  • Use bind variables to reduce hard parsing
  • Rewrite correlated subqueries as joins
  • Add hints only as a last resort

Ensure SGA and PGA are properly sized.

Scripts to run:

Key metrics:

  • Buffer cache hit ratio > 95%
  • Library cache hit ratio > 99%
  • Dictionary cache hit ratio > 95%
  • Shared pool free memory > 5% of total

Scripts to run:

Target: Memory sort ratio > 99% (sorts should happen in memory, not on disk)

Related errors:


Identify I/O bottlenecks and optimize storage access patterns.

Scripts to run:

What to check:

  • Average read time per datafile (target: < 10ms)
  • Even I/O distribution across files and disks
  • Redo log write latency (target: < 5ms)
  • Temp tablespace I/O (sort operations spilling to disk)

Related errors:


Identify locking issues causing application waits.

Scripts to run:

Resolution steps:

  1. Identify the blocking session
  2. Determine what SQL the blocker is running
  3. Contact the application owner or kill the session if appropriate
  4. Review application design for lock reduction opportunities

Related errors:


Prevent space-related outages proactively.

Scripts to run:

Related errors:


Document findings with AWR and ASH reports.

Scripts to run:

Recommended cadence:

  • Daily: Review top wait events and top SQL
  • Weekly: Generate AWR reports for peak periods
  • Monthly: Full performance review with trend analysis
  • Quarterly: Capacity planning review

Performance problem reported
├── Is it a specific query?
│ ├── Yes → Check execution plan (ep.sql) → SQL tuning
│ └── No → Continue
├── Check wait events (vsysev.sql)
│ ├── I/O waits dominant → Step 5 (I/O Tuning)
│ ├── Lock waits dominant → Step 6 (Lock Analysis)
│ ├── Memory waits dominant → Step 4 (Memory Tuning)
│ └── CPU waits dominant → Step 3 (SQL Tuning)
└── Check space (ddbspacea.sql)
└── Tablespaces near full → Step 7 (Space Management)