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.
Align the AWR snapshot with the stable part of the load test, not the ramp or an unrelated batch window. Record the application release, traffic mix and instance count so the database evidence can be compared with the client-side result.
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.
DB time is accumulated foreground database work. A DB time rate above elapsed wall-clock time is possible because sessions run or wait concurrently. Compare DB CPU, host CPU headroom and foreground wait composition before calling a system CPU-bound.
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
These percentages are investigation cues, not universal pass/fail thresholds. A single dominant statement may be expected in a narrow benchmark. The important questions are whether its elapsed time per execution changed, whether executions match the traffic model and which wait or resource explains the cost.
4. Investigate SQL_IDs with Context
Use:
This helps correlate AWR SQL_IDs with query text and investigation checklists.
For each SQL_ID, capture executions, elapsed time per execution, buffer gets, physical reads and plan identity when available. A lower execution count with higher elapsed time can mean something very different from a volume-driven increase.
5. Compare Against a Baseline
Load an incident or test AWR alongside a normal-period report with similar duration and workload. Compare rates rather than raw totals. Look for new top SQL, wait-event percentage shifts, reduced CPU headroom and changes in parsing or I/O efficiency. The analyzer marks missing evidence so a partial extraction is not mistaken for a complete diagnosis.
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.
Reproducible handoff
Export the analyzer's standalone HTML report and attach the test inputs: achieved RPS, latency percentiles, error rate and exact snapshot IDs. The export contains extracted evidence and prioritized hypotheses; it does not replace an Oracle diagnostic review or prove root cause.
Important Limits
AWR is licensed Oracle diagnostic data in many editions and environments; confirm your organization's entitlement. The browser analyzer works locally and uses heuristics over report structure. Custom formats, RAC-wide reasoning, ASH timelines, execution plans and workload-specific context can require additional evidence. Treat each finding as a ranked next check, not an automated tuning command.
This creates a closed-loop workflow: observe -> diagnose -> tune -> re-estimate RPS.