Explain Oracle AWR report, how to read and analyze performance issues?

Oracle AWR Report: How to Read and Analyze Performance Issues

What is an AWR Report?

An Automatic Workload Repository (AWR) Report in Oracle is a diagnostic tool that helps
analyze database performance over a given time period (snapshot interval). It provides insights
into CPU, memory, storage I/O, wait events, SQL execution, and system load.

AWR reports are generated using:

sql

CopyEdit

@$ORACLE_HOME/rdbms/admin/awrrpt.sql

It prompts for the snapshot range and generates a detailed report in HTML or text format.

How to Read and Analyze AWR Report for Performance Issues

1️⃣ Key Sections of an AWR Report

The report consists of various sections, but the most critical ones for performance tuning are:

Section Purpose

Database & Snapshot Shows the DB name, instance, snapshot range, elapsed time.
Details Ensure snapshots cover the issue timeframe.

Provides important system stats like transactions per second (TPS),

Load Profile logical/physical reads, redo size. Helps in identifying sudden
workload spikes.

Shows buffer cache, shared pool efficiency. Look for low buffer hit
Instance Efficiency
ratios (<90%) or high parse percentages.

Displays the most time-consuming wait events. Crucial for

Top Timed Events
identifying bottlenecks.

Shows the most resource-intensive SQL statements (CPU, I/O,

SQL Statistics
execution time).

I/O Statistics Identifies I/O-heavy tablespaces, high read/write latency.

Section Purpose

(Tablespaces & Datafiles)

Advisory Sections (SGA,

Recommends memory optimizations for SQL performance tuning.
PGA, Buffer Cache)

2️⃣ Key Areas to Focus On

🔹 A. Database Load: Load Profile Section

 Check Transactions per second (TPS) – Sudden spikes may indicate unexpected
workload changes.

 Redo Size, Logons per second – High values can indicate frequent commits or excessive
connections.

 Logical Reads (Consistent Gets + DB Blocks Gets) – A high value can indicate inefficient
queries scanning too many blocks.

Example of a high workload:

🛠 Optimization Tip: If TPS is high, check SQL Statistics for queries generating excessive
workload.

🔹 B. Identifying Bottlenecks: Top Timed Events

This section shows the most time-consuming wait events.

Common wait events include:
Wait Event Possible Issue Solution

db file sequential Optimize indexing, use Flash

High single-block I/O (Index lookups)
read Cache

Full table scans due to inefficient Enable Smart Scan, use

db file scattered read
queries partitioning

Tune redo logs, increase log

log file sync Slow commits, redo log contention
buffer

Use faster storage (Exadata

log file parallel write Slow writes to redo logs
Flash)

CPU time High CPU usage Identify top SQL consuming CPU

🔍 Example of problematic waits:

🛠 Optimization Tip: If db file sequential read is high, check SQL execution plans for inefficient
index scans.

🔹 C. Identifying Bad SQL: SQL Statistics Section

 This section shows Top SQL by CPU, I/O, Buffer Gets, Execution Time.

 Look for queries with high Execution Count, high Buffer Gets, or large Disk Reads.

 Example of a high-impact SQL:

 🛠 Optimization
Tip:

 Tune the SQL statement using EXPLAIN PLAN and SQL Tuning Advisor.

 Check if indexes are missing or not used efficiently.

 If disk reads are high, consider Smart Scan on Exadata.

🔹 D. Storage & I/O: Tablespace and Datafile Statistics

 Look for high I/O wait times or storage bottlenecks.

 Example of slow I/O:

🛠 Optimization Tip:

 If read times >10ms, move data to Exadata Smart Flash Cache.

 Ensure Exadata Smart Scan is enabled for full table scans.

🔹 E. Memory Tuning: Buffer Cache & PGA Advisory

 Buffer Cache Hit Ratio should be >90% for optimal performance.

 PGA Memory Allocated should be optimized to minimize TEMP tablespace usage.

 Example of suboptimal memory usage:

🛠 Optimization Tip:

 Increase SGA and PGA if memory allocation is too low.

 Check v$tempseg_usage for excessive TEMP space usage.

Summary: Steps to Analyze an AWR Report

✅ Step 1: Identify high load in Load Profile (TPS, CPU, Redo Size).
✅ Step 2: Check Top Timed Events for bottlenecks (I/O, CPU, wait events).
✅ Step 3: Analyze SQL Statistics for bad queries causing high resource usage.
✅ Step 4: Check Tablespace and I/O stats for storage issues.
✅ Step 5: Review Memory & PGA Advisory for suboptimal memory allocation.

Final Thoughts

📌 AWR reports help pinpoint bottlenecks in CPU, memory, storage, and SQL execution.
📌 Focus on high-impact wait events and SQL queries first.
📌 Leverage Exadata optimizations like Smart Scan, Flash Cache, and Storage Indexes.
📌 Use SQL Tuning Advisor & Execution Plans to fix inefficient queries.