1. Oracle AWR report Analysis

2. Table of contents
ORACLE AWR REPORT ANALYSIS........................................................................................................1
TABLE OF CONTENTS...............................................................................................................................2
1. INTRODUCTION......................................................................................................................................3
2. AWR REPORT PARTS.............................................................................................................................3
2.1 THE SNAPSHOT DETAILS.........................................................................................................................3
2.2 LOAD PROFILE........................................................................................................................................3
2.3 TOP 5 TIMED FOREGROUND EVENTS.....................................................................................................4
......................................................................................................................................................................5
2.4 THE TIME MODEL STATISTICS.................................................................................................................5
Time Model Statistics..............................................................................................................................5
2.5 SQL SECTION.........................................................................................................................................6
2.5.1 Total Elapsed Time
................................................................................................................................................................7
2.5.2 Total CPU Time.............................................................................................................................7
2.5.3 Total Buffer Gets
................................................................................................................................................................7
2.5.4 Total Disk Reads
................................................................................................................................................................7
2.5.5 Total Executions............................................................................................................................8
2.5.6 Parse Calls
................................................................................................................................................................8
2.5.7 Sharable Memory
................................................................................................................................................................8
2.5.8 Version Count................................................................................................................................9

3. 1. Introduction
This document will introduce and explain the main parts of an Oracle AWR report.
2. AWR report parts
2.1 The snapshot details
This is normally shown at the beginning of the report.
Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 7556 19-Oct-12
21:00:05
247 41.9
End Snap: 7558 19-Oct-12
23:00:14
249 41.6
Elapsed: 120.14 (mins)
DB Time: 239.38 (mins)
Elapsed (time) is the interval of time between the start and end snapshots. Another
important quantity is database DB Time which is the sum of working sessions’ time.
DB Time = sum of database CPU time + waits. In systems with multiple concurrent
active sessions DB Time can be larger than the elapsed time. This is because DB
Time is a sum of over all active sessions that are using CPU(s) or waiting for an
event. Note that Background processes are not included in that.
2.2 Load Profile
Per Second Per Transaction Per Exec Per Call
DB Time(s): 2.0 0.0 0.01 0.01
DB CPU(s): 1.3 0.0 0.01 0.00
Redo size: 31,071.8 423.5
Logical reads: 1,022,277.2 13,933.4
Block changes: 174.3 2.4

4. Physical reads: 493.9 6.7
Physical writes: 10.2 0.1
User calls: 301.1 4.1
Parses: 22.6 0.3
Hard parses: 0.7 0.0
W/A MB processed: 12.8 0.2
Logons: 0.2 0.0
Executes: 160.6 2.2
Rollbacks: 66.9 0.9
Transactions: 73.4
The Load Profile is one of the most important parts in the AWR report. Of particular
significance are the physical I/O rates and hard parses1
. A high hard parse rate
usually is a result of not using bind variables2
. If you see a high hard parse
rate per second for logons, it usually means that your applications aren’t
using persistent connections. A high number of logons or an unusually high
number of transactions tells you something unusual is happening in your
DB. However, the only way you will know the numbers are unusual is if you
regularly check the AWR reports in a properly functioning DB.
2.3 Top 5 Timed Foreground Events
This is probably one of the most important sections of AWR report.
This section is where you can usually spot the problem, by showing you why the
sessions are ‘waiting’. The top 5 events information shows the total waits for all
sessions. Usually one or two sessions are responsible for most of the waits.
In a nicely performing DB, you should see CPU and I/O as the top wait
events.
1
Hard parse – Oracle has to do a hard parse when a session executes an SQL statement that does not
exist in the shared pool. AS opposed to Soft parse that happens when a session executes an SQL
statement that exists in the shared pool and there is a version of the statement that can be used.
2
Bind variables is a place-holder variable in a SQL statement that must be replaced with a valid value (or
address of a value) before the statement can successfully execute.

5. If any wait events from the concurrent wait class such as latches3
show up
in the top wait events, investigate these events further.
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
db file
sequential read
2,817,676 810 0 62.0 User I/O
DB CPU 130 9.9
free buffer
waits
5,505 70 13 5.3 Configurat
log file
sync
142 46 324 3.5 Commit
log
buffer space
371 36 97 2.7 Configurat
In above 62% of database time was spent waiting for db file sequential read.
However, the average wait time was zero. Another 9.9% of the time was spent
waiting for or using CPU time. A tenth of database time used by DB CPU event is not
bad at all.
In general High CPU usage is often a symptom of poorly tuned SQL.
2.4 The time model statistics
Time Model Statistics
• Total time in database user-calls (DB Time): 14363s
• Statistics including the word "background" measure background process time, and so
do not contribute to the DB time statistic
• Ordered by % or DB time desc, Statistic name
Statistic Name Time (s) % of DB Time
sql execute elapsed time 12,416.14 86.45
DB CPU 9,223.70 64.22
parse time elapsed 935.61 6.51
hard parse elapsed time 884.73 6.16
failed parse elapsed time 821.39 5.72
PL/SQL execution elapsed time 153.51 1.07
3
Latch - fast, inexpensive and non-sophisticated lock. The latch is used when you need to serialize access
to operations, functions and data structures in Oracle. They are meant to be held for a very short time.

6. hard parse (sharing criteria) elapsed time 25.96 0.18
connection management call elapsed time 14.00 0.10
hard parse (bind mismatch) elapsed time 4.74 0.03
PL/SQL compilation elapsed time 1.20 0.01
repeated bind elapsed time 0.22 0.00
sequence load elapsed time 0.11 0.00
DB time 14,362.96
background elapsed time 731.00
background cpu time 72.00
Time model statistics give you an idea about how the DB has spent its time,
including the time it spent on executing SQL statements as against parsing
statements. If parsing time is very high, or if hard parsing is significant, you must
investigate it further.
In the above example, 9,223.70 seconds CPU time was used for all user sessions.
This was just under 65% of database resources. In total there was 14363 seconds
database time used. The total wait event time can be calculated as 14363 – 9223.70
= 5139.3 seconds. The lion share of database time (86.45%) was spent on executing
sql which is a good sign. The total parse time was 935.61 seconds of which 884.73
seconds was hard parsing. The rest of statistics is tiny in this case
2.5 SQL Section
If any SQL statement appears in the top 5 statements in two or more areas below, it
is a prime candidate for tuning. The sections are:
• Total Elapsed Time
• Total CPU Time
• Total Buffer Gets
• Total Disk Reads
• Total Executions
• Total Parse Calls
• Total Sharable Memory
• Total Version Count
Let us try to see what these mean.

7. 2.5.1 Total Elapsed Time
Total Elapsed Time = CPU Time + Wait Time. If a SQL statement appears in the total
elapsed time area of the report this means its CPU time plus any other wait times
made it pop to the top of the pile. Excessive Elapsed Time could be due to excessive
CPU usage or excessive wait times.
2.5.2 Total CPU Time
When a statement appears in the Total CPU Time area this indicates it used
excessive CPU cycles during its processing. Excessive CPU processing time can be
caused by sorting, excessive function usage or long parse times. Indicators that you
should be looking at this section for SQL tuning candidates include high CPU
percentages in the service section for the service associated with this SQL (a hint, if
the SQL is uppercase it probably comes from a user or application; if it is lowercase
it usually comes from the internal or background processes). To reduce total CPU
time, reduce sorting by using composite indexes that can cover sorting and use bind
variables to reduce parse times.
2.5.3 Total Buffer Gets
Total buffer gets mean a SQL statement is reading a lot of data from the db block
buffers. Generally speaking buffer gets (AKA logical IO or LIO) are OK, except when
they become excessive. To reduce excessive buffer gets, optimize SQL to use
appropriate indexes and reduce full table scans. You can also look at improving the
indexing strategy and consider deploying partitioning.
2.5.4 Total Disk Reads
High total disk reads mean a SQL statement is reading a lot of data from disks rather
than being able to access that data from the db block buffers. High physical reads

8. after a server reboot are expected as the cache is cold and data is fetched from the
disk. However, disk reads (or physical reads) are undesirable in an OLTP4
system,
especially when they become excessive. Excessive disk reads cause performance
issues.
To reduce excessive disk reads, consider partitioning, use indexes and look at
optimizing SQL to avoid excessive full table scans.
2.5.5 Total Executions
High total executions need to be reviewed to see if they are genuine executions or
loops in SQL code. I have also seen situations where autosys jobs fire duplicate
codes erroneously.
If the database has excessive physical and logical reads or excessive IO wait times,
then look at the SQL statements that show excessive executions and show high
physical and logical reads.
2.5.6 Parse Calls
Whenever a statement is issued by a user or process, regardless of whether it is in
the SQL pool it undergoes a parse. As explained under Parsing, the parse can be a
hard parse or a soft parse. Excessive parse calls usually go with excessive
executions. If the statement is using what are known as unsafe bind variables then
the statement will be reparsed each time. If the headers parse ratios are low look
here and in the version count areas (2.5.8).
2.5.7 Sharable Memory
Sharable Memory refers to Shared Pool memory area in SGA, hence, this particular
section in AWR Report states about the SQL STATEMENT CURSORS which consumed
the maximum amount of the Shared Pool for their execution.
4
Online transaction processing, or OLTP, refers to a class of systems that facilitate and manage
transaction-oriented applications, typically for data entry and retrieval transaction processing.

9. In general, high values for Sharable Memory doesn’t necessary imply there is an
issue, it simply means that:
1. These SQL statements are big or complex and Oracle has to keep lots of
information about these statements OR
2. big number of child cursors exist for those parent cursors
3. combination of 1 & 2
In case of point 2, it may be due to poor coding such as bind variables mismatch,
security mismatch or overly large SQL statements that join many tables. Usually
large statements will result in excessive parsing, recursion, and large CPU usage.
2.5.8 Version Count
High version counts are usually due to multiple identical-schema databases, unsafe
bind variables, or Oracle bugs.

10. In general, high values for Sharable Memory doesn’t necessary imply there is an
issue, it simply means that:
1. These SQL statements are big or complex and Oracle has to keep lots of
information about these statements OR
2. big number of child cursors exist for those parent cursors
3. combination of 1 & 2
In case of point 2, it may be due to poor coding such as bind variables mismatch,
security mismatch or overly large SQL statements that join many tables. Usually
large statements will result in excessive parsing, recursion, and large CPU usage.
2.5.8 Version Count
High version counts are usually due to multiple identical-schema databases, unsafe
bind variables, or Oracle bugs.