“Slow SQL Queries → Slow Application Response”

– A Beginner-Friendly Guide to AWR

When your application is slow, it’s often

because of a slow SQL query​

To fix it, you’ll need to read and understand

the AWR report. This is a guide to help you
get comfortable reading AWR reports.

sandeep-pawar21 | Performance Architect​ ​ ​ ​ 1

 What is AWR ❓
AWR stands for Automated Workload
Repository​

It is a powerful diagnostic tool that captures

snapshots of database activity over time. Think of
AWR as your database's "black box recorder" - it
collects critical performance data that helps you
identify bottlenecks and troubleshoot issues.

By focusing on just a few key tables in the AWR

report, you'll learn to spot performance problems
and provide specific, actionable information to your
database administrators or developers. Let's get
started with the basics!

sandeep-pawar21 | Performance Architect​ ​ ​ ​ 2

 The First 4 Tables You Need to Understand

First 4 Tables on the AWR report introduce you to the

Database, Database Instance, Host machine running the
instance, and the time frame of the report.

1: DB Info ➡️
➡️
2. Instance Info

3. Host Info ➡️

4. Snap Info ➡️

sandeep-pawar21 | Performance Architect​ ​ ​ ​ 3

 Table 1: Database Info

Columns 🔍 What to Look For

DB Name, DB Id, Helps identify the database — useful to
Unique Name make sure you are analyzing the right
one
Role Is it a Primary or Standby? Only Primary
matters for app-level performance.
Edition, Release Knowing the version helps when
searching for known bugs or tuning
advice.
RAC, CDB Indicates if the DB is clustered or
containerized — performance tuning
may differ.

RAC - Stands for Real Application Cluster. If the value for

RAC is Yes, there will be other instances too. Check the
Instance ID in the next table, and ask for AWR reports of
other instances as well.

CDB - Stands for Container DB.

sandeep-pawar21 | Performance Architect​ ​ ​ ​ 4

 Table 2: Instance Info

Columns What to Look For

Instance, Inst Num, Shows when the DB was restarted. A recent restart
Startup Time may reset trends.

User Name Most of the time, you'll see it as SYS, because that's
the default high-privileged user used for generating
AWR reports.

System Data Visible This field tells you whether the AWR report
includes system-level stats like:

●​ OS statistics (CPU, memory usage, etc.)​

●​ Background wait events​

●​ Host-level metrics​

This is typically set to:

●​ YES – Full system data is included​

●​ NO – The report is missing system data

(maybe due to lack of permissions or some
config being off)

💡 You generally want this to be YES, so that you

get a complete picture — not just SQL stats, but also
server-level resource utilization.

sandeep-pawar21 | Performance Architect​ ​ ​ ​ 5

 Table 3: Host Info
This Machine runs your Database

This table gives you a quick glance at the hardware and OS

environment where the Oracle Database is running — very
important for performance context.

Column What It Means

Host The server name (hostname) where this Oracle instance is
Name running. Helps you identify the physical or virtual machine in your
environment.

Platform The operating system and architecture, e.g., Linux x86

64-bit, Windows x86 64-bit, etc. Useful for understanding
the environment and compatibility.

CPUs* Total number of logical CPUs (includes cores × threads). Affects

how many processes Oracle can run in parallel.(See note below)

Cores* Total number of physical CPU cores. More cores = better parallel
query performance. (See note below)

Sockets Number of CPU sockets on the motherboard. Usually, servers

with multiple CPUs will have more sockets.

Memory Amount of physical RAM available on the host. This impacts how
(GB) much memory Oracle can use for caching, sorting, and buffer
pools.

…Continued

sandeep-pawar21 | Performance Architect​ ​ ​ ​ 6

 🔍 Note on CPUs and Cores in AWR Reports

In AWR reports:
●​ Cores = Physical processor cores​

●​ CPUs = Logical threads (also called vCPUs)​

→The number of logical threads per core depends on

the processor architecture:
●​ On Intel/AMD: 1 core → 2 threads (via
Hyper-Threading / SMT)​

●​ On PowerPC/SPARC: 1 core → up to 8 threads (via

Simultaneous Multi Threading – SMT)​

This info helps you understand how much parallel

processing your DB host is capable of.

sandeep-pawar21 | Performance Architect​ ​ ​ ​ 7

 Table 4: Snapshot Info
Time Window of the Report

Oracle takes a snapshot (think of a photo) of the current

state of its operation.

Key points of this table:

●​ Begin Snapshot - Starting snapshot of the report

●​ End Snapshot - Ending snapshot of the report
●​ Elapsed time - Duration of the AWR Report
●​ The 4th row is DB time - The total time the database
spent actively processing requests (CPU + wait time).
We won’t dive into using it just yet, but know that many
tables in AWR report reference % of DB Time — so it’s
worth getting familiar with the term.
●​ Snap id is the numeric id of the snapshot. Typically they
are in sequence. However if the difference in them is
more than 1, you can get another AWR report for a finer
timeframe.​ ​ ​ ​ ​ ​ ​ …Continued

sandeep-pawar21 | Performance Architect​ ​ ​ ​ 8

 ●​ Snap Time is the time when that snapshot was taken.
●​ Sessions, Cursors/Sessions & Instances columns show
the respective values at the beginning & End time of the
AWR Report. The numbers might have increased or
decreased between these AWR snapshots but that
information is not shown in the AWR report. These define
the time range (aka reporting interval) for the entire AWR
report.

ℹ️ By default every 1 hour, but it is configurable.

👉 For 30 mins of load tests, it is advised to change the duration
of snapshot interval to 15 mins, and generate at least 3 AWR
reports of 15 mins each to completely cover the load test
duration. This helps you compare different phases of your load
test.

👉 If you are analyzing for production, 1 hour gap in snap is

perfectly fine.

The important information for you at this time are Snap times,
Snap Id & Elapsed time. The rest you can learn later when you
acquire advanced knowledge about Oracle Database tuning.

Next chapter is about Identifying Slow Queries

sandeep-pawar21 | Performance Architect​ ​ ​ ​ 9

Next, find SQL Statistics Section in the AWR report.
(Tip: You can press Ctrl+F in your browser to search with
“SQL Statistics” string in AWR Report’s Web Page)

The 3 key subsections here are

●​ SQL ordered by Elapsed Time
●​ SQL ordered by Executions
●​ Complete List of SQL Text

Click on “SQL ordered by Elapsed Time”

sandeep-pawar21 | Performance Architect​ ​ ​ ​ 10

 Table: SQL Ordered by Elapsed Time
Main table of slow queries

The key columns are (not in order of appearance)

●​ SQL Text - Actual text of the SQL query
●​ SQL Id - alphanumeric unique id generated for the given
SQL Text
●​ Elapsed Time per Exec (s) - Average time taken per
execution by SQL Id
●​ Executions - Total number of executions of that query
during Elapsed time of the AWR report
●​ Elapsed Time (s) - Executions x Elapsed Time per Exec (s)

✅ "Tip: You’ve seen two types of Elapsed Time — they mean

different things:

●​ In Snapshot section: it's the duration of the AWR report

●​ In other SQL sections: it's the total time the query took to
execute across all runs"

sandeep-pawar21 | Performance Architect​ ​ ​ ​ 11

 🚩 How to Spot A Slow Query
Case 1: Very High Elapsed Time and Elapsed time per
Exec (s)

●​ These are expensive queries that take too long.​

●​ Even a single execution may be hurting performance.​

Case 2: Many Executions + Moderate Elapsed Time

●​ These queries may not be slow per execution, but because

they run too often, they add up.​

●​ These are high-impact frequent queries.​

Tips to Investigate Further

●​ Click the SQL Id to go to the full SQL Text later in AWR.
●​ Once you find a slow query, ensure that it belongs to the slow
transaction/API you are concerned with. → Sometimes the
identified slow query may be related to a background job or
another application and not related to your transaction/API.
●​ Compare the Elapsed Time (s), Executions, Rows per Exec
for the same SQL Id across multiple AWR reports. For example,
compare the first half of the load test with the second. Peak and
Non Peak, etc. → Sometimes, the query runs slow only for one
instance or one interval only.

sandeep-pawar21 | Performance Architect​ ​ ​ ​ 12

🔄 Watch Out for Over-Executed Queries (Chatty APIs)
Sometimes, your app is not slow because of a few slow
queries, but because of many fast queries being
executed too frequently. This is called “chatty”
behavior — where the database is overwhelmed by
sheer volume.
You can refer to 2 tables for this case.
Table 1: SQL ordered by Elapsed Time table →
Executions Column (Refer previous section)
Table 2: SQL Ordered by Executions (See below table)

Pro Tip: Look at the Rows per Exec count with respect
to Executions Count, High Rows per execution, as well
as very low Rows per Exec but high Executions count
can cause high response time.

sandeep-pawar21 | Performance Architect​ ​ ​ ​ 13

 📌 Key Takeaways

●​Use SQL ordered by Elapsed Time to find

slow queries​

●​Watch out for chatty APIs with frequent

executions​

●​Use SQL Id to trace the query in other

sections or instance of AWR report​

●​Focus on Snap Time, Elapsed Time, and

Executions to isolate issues

Pro Tip: AWR report comes in Text & HTML

format. Whenever possible, use HTML for easy
navigation.

sandeep-pawar21 | Performance Architect​ ​ ​ ​ 14

 What Next? Ask for Plans, Compare
Across Reports

1.​Ask for a Query Execution Plan or SQL plan

for the given Query ID.
2.​Check other areas or instance of the AWR
using the SQL Id
3.​Coordinate with DBAs or Performance
Engineers

🙌 Feeling Confident with AWR Now? Let Me

Know!

sandeep-pawar21 | Performance Architect​ ​ ​ ​ 15