AWR is often treated as a static report. Strong teams use it as a decision engine for Requests Per Second (RPS) planning.
1. Start with the Time Window
Always capture:
- snap begin
- snap end
- elapsed window
Without time context, RPS and throughput conclusions are weak.
2. Identify Primary Bottleneck
Use CPU vs wait composition first:
- CPU-bound profile
- I/O-bound profile
- mixed profile
The AWR Analyzer summarizes this quickly.
3. Quantify SQL Concentration Risk
Check whether top SQL statements dominate DB time.
A common high-risk pattern:
- top 1 SQL > 30% DB time
- top 3 SQL > 40% DB time
4. Investigate SQL_IDs with Context
Use:
This helps correlate AWR SQL_IDs with query text and investigation checklists.
5. Feed Back into RPS Planning
After database bottlenecks are understood, recalculate service capacity:
- target RPS
- safe RPS
- expected concurrency
Use RPS Calculator and API Throughput Calculator to update planning assumptions.
This creates a closed-loop workflow: observe -> diagnose -> tune -> re-estimate RPS.