10/11/24, 10:14 AM Document 1628089.

1
Copyright (c) 2024, Oracle. All rights reserved. Oracle Confidential.

AWR Report Interpretation Checklist for Diagnosing Database Performance Issues (Doc ID
1628089.1)

In this Document

Purpose
Scope
Details
Starting Points
Oracle Diagnostic Method
The nature of AWR, ADDM and ASH
Checklist
Checklist Detail
Implement findings from an ADDM report from the same snapshot interval
Review Overall picture from AWR header information
Check Host and Instance CPU to determine the proportion of CPU usage by this instance
Check the Load profile to use later in the context of the top waits
Examine Top 5 Timed Events for highest resource users
References

APPLIES TO:

Oracle Database - Enterprise Edition - Version 10.1.0.2 and later

Oracle Database Cloud Schema Service - Version N/A and later
Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Backup Service - Version N/A and later
Information in this document applies to any platform.

PURPOSE

This document provides a checklist for starting to interpret an AWR (Automatic Workload Repository)
report. The AWR report contains a significant amount of information, so it helps to focus on certain areas to
get started.

SCOPE

Parties interested in interpreting AWR report information to resolve performance issues.

DETAILS

Starting Points

A video entitled: "Introduction to Performance Analysis Using AWR and ASH" is available here providing a comprehensive
guided tour using an actual problem.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=oio8unifj_4&id=1628089.1 1/6
10/11/24, 10:14 AM Document 1628089.1
Many of the points raised in this article are expanded upon in the "Troubleshooting DB Performance issues with AWR"
Webcast. The recording for this webcast can be accessed in the following document:

Document 740966.1 Oracle Support Advisor Webcasts: Current Schedule and Archived Recordings

For more information you can review the following Oracle Open World presentation to see how to apply AWR to real life
scenarios.

Oracle Diagnostic Method

AWR interpretation to resolve performance issues should always be taken with the Oracle Diagnostic Method in mind. That is:

Find the worst bottleneck

Relieve it
Repeat until performance is good enough

A systems performance is no better than the worst bottleneck, so concentrating on this and then improving the performance in
this area is always going to give the best results for the time spent.

The nature of AWR, ADDM and ASH

AWR, ADDM (Automatic Database Diagnostic Monitor) and ASH (Active Session History) are interval sample tools. They sample
information at particular times. We can then look at the changes in the interval between the samples.

The AWR default sample is every 60 minutes. See:

Oracle® Database Performance Tuning Guide

12c Release 1 (12.1)
E15857-15
Chapter 6 Gathering Database Statistics
Section 6.2.2.2 Creating Snapshots
http://docs.oracle.com/cd/E16655_01/server.121/e15857/gather_stats.htm#TGDBA190

"By default, Oracle Database automatically generates snapshots once every hour."

The ASH default sample is 1 second, but later is stored in 10 second intervals on disk.

Note: The use of ASH reports are not directly covered in this article but due to it's short snapshot interval a much finer
granularity of information is available. Among other uses, it is useful to collect ASH reports in a situations where:

you need to narrow down which selects are responsible for a particular wait
you want to know when a particular wait occurred within the snapshot period to tie up with performance spikes or
intermittent hangs

Checklist

[ X ] Implement findings from an ADDM report from the same snapshot interval

[ X ] Review Overall picture from AWR header information

[ X ] Check Host and Instance CPU to determine the proportion of CPU usage by this instance

[ X ] Check the Load profile to use later in the context of the top waits

[ X ] Examine Top 5 Timed Events for highest resource users

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=oio8unifj_4&id=1628089.1 2/6
10/11/24, 10:14 AM Document 1628089.1

Checklist Detail

This checklist steps through the recommended areas to investigate when presented with an AWR report. It does not assume
that you have any information other than the database is performing slowly and what is contained in the AWR output.

Implement findings from an ADDM report from the same snapshot interval

The ADDM report for the same period as that covered by the snapshot interval can identify and suggest potential
resolution options for many issues. The ADDM report provides a number of recommendations on various areas such as
CPU bottlenecks, undersized memory structures, I/O capacity issues, high-load SQL statements etc. that otherwise may
need experience and/or be difficult and time consuming to produce. For more on ADDM reports see:

Oracle® Database Performance Tuning Guide

12c Release 1 (12.1)
E15857-15
Chapter 7 Automatic Performance Diagnostics
Section 7.1 Overview of the Automatic Database Diagnostic Monitor

http://docs.oracle.com/cd/E16655_01/server.121/e15857/pfgrf_diag.htm#TGDBA02602

It is recommended to start with an ADDM report and try to implement the top suggestion. Once changes have been
made re-try until performance is good enough. If this does not work then approach the AWR report, bearing in mind
the ADDM findings. Also see: Use of ADDM Reports alongside AWR

Review Overall picture from AWR header information

The header section contains useful information that can help set the context of the report you are looking at. For
example, the report contains a number of sections that quote specific counts of various statistics. Without a timescale,
these numbers are meaningless.

Release
Depending on the problem, the database version may be important. If the version is old or is not the latest
patchset release then the most up to date fixes may not be applied which has the potential to open the database
up to issues.
RAC
If the database is running in a Real Application Cluster configuration then you may need to look at information
from the other instances to get a full picture of the database performance
Platform
There may be platform specific issues that have a bearing on the system
CPUs/Cores
In a multi-processor environment, the "wall clock" time is not necessarily a good indicator of how much work the

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=oio8unifj_4&id=1628089.1 3/6
10/11/24, 10:14 AM Document 1628089.1
database can do since multiple operations can be pursued simultaneously. You can use cores for an indication of
how much CPU work can likely be done at once.
Snap Time
The Snap time shows the times for the starting and ending snapshots for the report period. Does this cover the
time of problem that is being encountered?
Elapsed time
The elapsed time indicates the duration of the report between the 2 selected snapshots. Any other duration
figures can be compared back to this. When looking at this figure, is the duration reasonable? If the duration is
too short then important information may be missed. If it is too long then findings may be diluted. A 30-60
minute reporting period is usually recommended. In terms of AWR snapshots, as much as possible snapshots
should be minimum 10 minutes, maximum 30 minutes.
DB time
The DB Time is the time spent in the database for the period of the report. If this is significantly higher than the
Elapsed time then this is a good indicator of a heavily loaded system. Remember that on a multi-processor
system, you might expect the DB Time to be able to exceed the elapsed time. Additionally, the db time includes
the time waiting for the CPU to become available, so this number can be higher than the Elapsed time X Cores.
In the example above, the numbers say that the database worked for 2193 minutes in 15 minutes of elapsed
time. Whether that is an indication of a problem depends on the capacity and concurrency capabilities of the
system. Looking at the numbers, 2193:15 is a ratio of 146:1, so, in this case, if they had significantly less than
146 cpus it is likely that there is some overloading issues. Remember that the user perception is also a
significant factor in whether there is a "performance issue" - if the system delivers what the users want then
there might not be a problem!
Sessions
You can use the sessions information along with the DB time to give an average amount of DB time per session.
Are there a large number or a small number of connections?

Check Host and Instance CPU to determine the proportion of CPU usage by this instance

Another important area to look at before going to the detail of the top wait events is the Host and Instance CPU
sections.

These provide information regarding how much load there is on the underlying operating system and also how much of
it is attributable to the instance in the AWR report. If the system is heavily loaded, then the performance of the
database itself may be affected by the external contention. In these cases, look to see how much of the total CPU
usage is being caused by this instance. In this case, 92.4% of the Total CPU can be attributed to the instance, which
would tend to indicate that improving the instance performance is likely to improve the overall performance. If the
instance was only responsible for a small proportion of the overall CPU, it may be that the problem lies elsewhere.

Check the Load profile to use later in the context of the top waits

The load profile section can provide you with a more detailed impression of where the database is loaded. Information
is provided "Per Second" and "Per Transaction" for most statistics and also "Per Exec" and "Per Call" for DB Time and
CPU.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=oio8unifj_4&id=1628089.1 4/6
10/11/24, 10:14 AM Document 1628089.1

Suggested interpretations:
DB CPU(s)
The DB CPU(s) figure shows the amount of the CPU being used by the database. You can use this alongside the
actual number of cores to give you an idea of how much of the total available machine CPU is actually being
used by this instance.
DB Time(s) Here the "Per Second" information gives you another version of the total DB time used, just in this
case expressed as every second as opposed to the full elapsed period.

Other statistics should be looked at within the context of the overall elapsed time and also in the context of the top
waits, once you have looked at these later. For example:

Top events indicate library cache or cursor contention

In this case it would be sensible to look at the load in terms of Parse and Hard Parse statistics. The number of
parses per execution could also be a relevant indicator
Top events are related to reading of blocks
In this case, do we see mainly physical or logical reads? If it is physical then are the explain plans for top queries
such as to encourage more logical reads?

At this point you may also want to look at the Instance Efficiency Percentages to see if these bear out the findings from
the above:

Looking at these in the context of a specific wait is far more beneficial than attempting to reach 100%. If the bottleneck
is elsewhere, attempting to change individual statistics will have little or no impact on the overall system. For example,
in the Instance Efficiency Percentages above, the "Buffer Hit %" is 99.88%. If there is no contention for buffers and no
waits for buffers, then what is the benefit in making changes to try to improve this number?

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=oio8unifj_4&id=1628089.1 5/6
10/11/24, 10:14 AM Document 1628089.1
You should also look at the numbers in the context of the other numbers. For example, in the case above, let us say
that there is a performance issue and the top timed events showed that CPU usage was a significant resource. Looking
at the "Parse CPU to Parse Elapsd %" alone, this says that 26.87% of the total parse time is CPU and maybe you would
prefer a lower percentage (although 26% seems quite reasonable). Since the: "% Non-Parse CPU" is 98.07% this
means that only 1.03% of the total CPU usage is parsing, so even if you reduced that 26.87% to the impossible value
of zero then you would only gain 1% extra CPU overall. It is likely that you would need to look elsewhere for the cause
of your CPU resource issue.

Examine Top 5 Timed Events for highest resource users

Once you have looked at the background information, the Top 5 Timed Events section is the place to start in order to
tell what is taking up the largest proportion of the database time. Based upon the general feeling for the system, the
top resource users are put in context and can be investigated to determine a root cause. This topic is covered in more
detail in the following article:

Document 1359094.1 How to Use AWR Reports to Diagnose Database Performance Issues

REFERENCES
NOTE:1599440.1 - FAQ: Automatic Workload Repository (AWR) Reports
NOTE:1363422.1 - Automatic Workload Repository (AWR) Reports - Main Information Sources
NOTE:1359094.1 - How to Use AWR Reports to Diagnose Database Performance Issues

Didn't find what you are looking for?

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=oio8unifj_4&id=1628089.1 6/6