Performance Tuning Basics 15 _ AWR Report Analysis – Expert Oracle

Performance Tuning Basics 15 : AWR Report
Analysis
PUBLISHED FEBRUARY 6, 2018 by BRIJESH GOGIA
The Oracle’s Automatic Workload Repository (AWR) collects, processes, and maintains
performance statistics for problem detection and self-tuning purposes. The report
generated by AWR is a big report and it can take years of experience to actually
understand all aspects of this report. In this post we will try to explain some important
sections of AWR, significance of those sections and also some important tips. Please
note that explaining all sections of AWR will not be possible so we will stick to some of
the most frequently used sections.
Note that this is not comprehensive information and goal is to help in giving an
overview of few key sections to Junior DBAs as a primer and to encourage them to
build further the knowledge in related fields.
To start with let us mention some high level important tips regarding AWR:
1. Collect Multiple AWR Reports: It’s beneficial to have two AWR Reports, one for the
good time and other when performance is poor or you can create three reports
(Before/Meantime/After reports) during the time frame problem was experienced and
compare it with the time frame before and after.
2. Stick to Particular Time: You must have a specific time when Database was slow so
that you can choose a shorter timeframe to get a more precise report.
3. Split Large AWR Report into Smaller Reports: Instead of having one report for long
time like one report for 3 hrs. it is better to have three reports each for one hour. This
will help to isolate the problem
4. FOR RAC, take each instance’s individual report: For RAC environment, you need to

do it separately of all the instances in the RAC to see if all the instances are balanced
the way they should be.
5. Use ASH also : Use AWR to identify the troublesome areas and then use ASH to
confirm those areas.
6. Increase the retention period : Some instances where you get more performance
issues you should increase the retention time so that you can have historical data to
compare.
TIME UNITS USED IN VARIOUS SECTIONS OF AWR REPORTS
-> s – second
-> cs – centisecond – 100th of a second
-> ms – millisecond – 1000th of a second
-> us – microsecond – 1000000th of a second
Top Header
SIGNIFICANCE OF THIS SECTION:
This contains information about the Database and environment. Along with the
snapshot Ids and times. Important thing to notice is that the configuration like CPU and
Memory has not changed when the performance is degraded.
PARAMETER
DESCRIPTION ANALYSIS
DB TIME Time spent in database during the DB TIME > Elapsed Time will mean that
Elapsed Time the sessions were active on database
OR concurrently
Sum of the time taken by all sessions in
the database during the ‘Elapsed’ You cam find the average active
time.DB Time= CPU Time + sessions during AWR Time:
Non IDLE wait time.
DB TIME/ELAPSED =>
Note: it does not include 1964.97/899.99 = 2.18
background processes
So database load (average
active sessions) = 2.18
(SAME IDEA AS CPU LOAD on

UNIX)
It means that
May be ~2 users were active on

database for ‘Elapsed’ Time.
or
May be 4 users were active for
Elapsed Time/2 each
or
Elapsed Time/4 each
or
Elapsed Time/32 each
If DB Time has higher value

means DB Activity/Sessions
were High during the AWR
Time.
AWR REPORT THAT WE WILL REVIEW
BELOW IS BASED ON THIS DB TIME.
This means that for every

minute of Elapsed time there is
2.2 minutes of work in done in
the database
Elapsed time should contain the issue

The time duration in which this AWR
ELAPSED TIME duration.
report has been generated.
Take manual snapshots if required
Thread count per core. It is not “actual”

CPUs
CPU.
STARTUP TIME Database startup time
If you have more than one node then take

RAC AWR from all nodes if you don’t know
issues are happening in which node.
Load Profile
Here in load profile (average active sessions, DB CPU, logical and physical reads, user
calls, executions, parses, hard parses, logons, rollbacks, transactions) —
check if the numbers are consistent with each other and with general database profile
(OLTP/DWH/mixed)
Pay most attention to physical reads, physical writes, hard parse to parse ratio
and executes to transaction ratio.
The ratio of hard parses to parses tells you how often SQL is being fully
parsed. Full parsing of SQL statements has a negative effect on performance.
High hard parse ratios (>2 – 3 percent) indicate probable bind variable issues or
maybe versioning problems.
Rows per sort can also be reviewed here to see if large sorts are occurring.
This section can help in the load testing for application releases. You can
compare this section for the baseline as well as high load situation.
PARAMETER DESCRIPTION ANALYSIS
Redo Size The main sources of redo Not very scary number in our
(Bytes) are (in roughly descending report
order): INSERT, UPDATE and
DELETE. For INSERTs and High redo figures mean that either
UPDATE s lots of new data is being saved
into the database, or existing data
is undergoing lots of changes.
What do you do if you find that

redo generation is too high (and
there is no business reason for
that)? Not much really — since
there is no “SQL ordered by redo”
in the AWR report.
Just keep an eye open for any

suspicious DML activity. Any
unusual statements? Or usual
statements processed more usual
than often? Or produce more
rows per execution than usual?
Also, be sure to take a good look
in the segments statistics section
(segments by physical writes,
segments by DB block changes
etc.) to see if there are any clues
there.
We have 8 CORES and so we can

potentially use 8 seconds of CPU
Its the amount of CPU time
time per second. In this case DB
spent on user calls. Same as
CPU (s) : 1.9 (per second) is reporting
DB CPU DB time it does not include
that the system
background process. The
is using 1.9 seconds of CPU of the
value is in microseconds
potential 8 seconds/second that it
can use.We are not CPU Bound
LOGICAL Consistent gets + db block Logical and physical reads

READS gets = Logical Reads combined shows measure of how
many IO’s (Physical and logical) that
As a process, Oracle will try the database is performing..
to see if the data is available
in Buffer cache i.e. SGA? If this is high go to section “SQL by
logical reads”. That may help in
If it does, then logical read pointing which SQL is having more
increases to 1. logical reads.
To explain a bit further, if

Oracle gets the data in a
block which is consistent
with a given point in time,
then a counter name
“Consistent Gets” increases
to 1.
But if the data is found in

current mode, that is, the
most up-to-date copy of the
data in that block, as it is
right now or currently then it
increases a different counter
name “db block Gets”.
Therefore, a Logical read is

calculated as = Total number
of “Consistent Gets” + Total
number of “db block gets”.
These two specific values

can be observed in ‘Instance
Activity Stats’ section.
USER Number of user queries

QUERIES generated
The total of all parses, hard

PARSES
and soft
HARD The parses requiring a How much hard parsing is

PARSES completely new parse of the acceptable?
SQL statement. These
consume both latches and It depends on too many things, like
shared pool area. number of CPUs, number of
executions, how sensitive are plans
to SQL parameters etc. But as a rule
of a thumb, anything below 1 hard
parse per second is probably okay,
and everything above 100 per
second suggests a problem (if the
database has a large number of
CPUs, say, above 100, those
numbers should be scaled up
accordingly). It also helps to look at
the number of hard parses as % of
executions (especially if you’re in the
grey zone).
If you suspect that excessive

parsing is hurting your database’s
performance:
1) check “time model statistics”

section (hard parse elapsed time,
parse time elapsed etc.)
2) see if there are any signs of

library cache contention in the
top-5 events
3) see if CPU is an issue.
Soft parses are not listed but

derived by subtracting the
hard parses from parses. A
Soft Parses: soft parse reuses a previous
hard parse; hence it
consumes far fewer
resources.
But if it Oracle does not find the
data in buffer cache, then it reads
it from physical block and
increases then Physical read count
to 1. Clearly, buffer get is less If this is high go to section “SQL by
Physical expensive than physical read Physical reads”. That may help in
Reads because database has to work pointing which SQL is having
harder (and more) to get the data. more Physical reads.
Basically time it would have taken
if available in buffer cache + time
actually taken to find out from
physical block.
If executes per second looks enormous

then its a red flag.
Example: This numbers,

combined with high CPU usage,
are enough to suspect there MAY
BE context switching as the
primary suspect: a SQL statement
Executes
containing a PL/SQL function,
(SQL)
which executes a SQL statement
hundreds of thousands of time
per function call.
if it is high then it also suggests that

most of the database load falls on
SQL statements in PL/SQL routines.
User Calls number of calls from a user This is an extremely useful piece of
process into the database – information, because it sets the
things like “parse”, “fetch”, scale for other statistics (such as
“execute”, “close” commits, hard parses etc.).
In particular, when the database is

executing many times per a user
call, this could be an indication of
excessive context switching (e.g. a
PL/SQL function in a SQL statement
called too often because of a bad
plan). In such cases looking into
“SQL ordered by executions” will be
the logical next step.
Establishing a new database

connection is also expensive (and
even more expensive in case of
audit or triggers). “Logon storms”
are known to create very serious
logons – really means what
Logons performance problems. If you
it means. Number of logons
suspect that high number of
logons is degrading your
performance, check “connection
management elapsed time” in
“Time model statistics”.
Sort operations consume

resources. Also, expensive
sorts may cause your SQL fail
because of running out of
TEMP space. So obviously,
the less you sort, the better
(and when you do, you should
sort in memory). However, I
Sorts
personally rarely find sort
statistics particularly useful:
normally, if expensive sorts
are hurting your SQL’s
performance, you’ll notice it
elsewhere first.
average number of active sessions

DB Time
is simply DB time per second.
Block Number of blocks modified
Changes during the sample interval
Instance Efficiency Percentage

Rule of thumb: Always minimize the number of Hard parses. This reduction yields the
benefits of minimizing CPU overhead spent performing costly parse work.
Every ratio here should reach 100%
Shows %of times Sorting

In Memory Sort being low (in the high 90s or lower)
In memory operations happened in
indicates PGA_AGGREGATE_TARGET or
sort % memory than in the disk
SORT_AREA_SIZE issues
(temporary tablespace).
Shows % of times
the SQL in shared
pool is used. Shows
Soft Parsing being low indicates bind
how often sessions
variable and versioning issues. With 99.25
issued a SQL
% for the soft parse meaning that about
soft parse % statement that is
0.75 % (100 – soft parse) is happening for
already in the
hard parsing. Low hard parse is good for
shared pool and
us.
how it can use an
existing version of
that statement.
If this value is near 100% means most of
the CPU resources are used into
operations other than parsing, which is
Oracle utilizes the good for database health.
CPU mostly for
% Non-Parse
statement
CPU Most of our statements were already
execution but not
parsed so we weren’t doing a lot of re
for parsing.
parsing. Re parsing is high on CPU and
should be avoided.
The way this ratio is computed, it will be a

number near 100 percent when the
application executes a given SQL
statement many times over but has
parsed it only once.
Shows how often If the number of parse calls is near the

parsed SQL number of execute calls, this ratio trends
Execute to towards zero.
statements are
Parse %
reused without re-
parsing. If the number of executes increase while
parse calls remain the same this ratio
trends up.
When this number is low, parsing is

consuming CPU and shared pool latching.
If the value are low then it means that there could be a

parsing problem. You may need to look at bind variable
Gives the ratio of CPU issues or shared pool sizing issue. If low it also means
Parse CPU to
time spent to parse SQL some bottleneck is there related to parsing. We would
Parse Elapsed %
statements. start by reviewing library cache contention and
contention in shared pool latches. You may need to
increase the shared pool.
Buffer Hit % Measures how many times

a required block was
found in memory rather
than having to execute an
expensive read operation
on disk to get the block.
This ratio relates to requests that a server process

makes for a specific buffer. This is the percentage of
Indicates % of times data those requests in which the requested buffer is
buffers were accessed immediately available. All buffer types are included in
Buffer Nowait%
directly without any wait this statistic. If the ratio is low, check the Buffer Wait
time. Statistics section of the report for more detail on which
type of block is being contended. Most likely,
additional RAM will be required.
Library hit % is great when it is near 100%.

If this was under 95% we would
investigate the size of the shared pool.
In this ration is low then we may need to:

• Increase the SHARED_POOL_SIZE init
Shows % of times
parameter.
SQL and PL/SQL
Library Hit% • CURSOR_SHARING may need to be set
found in shared
to FORCE.
pool.
• SHARED_POOL_RESERVED_SIZE may
be too small.
• Inefficient sharing of SQL, PLSQL or JAVA
code.
• Insufficient use of bind variables
Shows % of time
If Latch Hit % is <99%, you may have a
latches are acquired
Latch Hit % latch problem. Tune latches to reduce
without having to
cache contention
wait.
Shows whether the

Redo
redo log buffer has
NOWait%
sufficient size.
Top 10 Foreground Wait Events by Total Wait Time

This section is critical because it shows those database events that might constitute
the bottleneck for the system.
Here, first of all check for wait class if wait class is User I/O , System I/O, Others etc
this could be fine but if wait class has value “Concurrency” then there could be some
serious problem. Next to look at is Total Wait Time (sec) which show how many times
DB was waiting in this class and then Wait Avg (ms). If Total Wait Time(sec) are high but
Wait Avg(ms) is low then you can ignore this. If both are high or Wait Avg(ms) is high
then this has to further investigate.
Note that there could be significant waits that are not listed here, so check the Foreground
Wait Events (Wait Event Statistics) section for any other time consuming wait events.
For the largest waits look at the Wait Event Histogram to identify the distribution of
waits.
DB CPU Time running in CPU (waiting in run- Here 84.8% is the %DB Time for this Event
queue not included) which is really HIGH!
DB Time was 1965 minutes and

DB CPU is (100000/60= 1667
minutes)
1667/1965 is 84.8% which is
shown in above table.
We can find
1) DB CPU LOAD
=Total wait time /AWR TIME

=100,000/(900*60)
=1.85
2) DB CPU UTLIZATION %
=DB CPU LOAD/Number of
Cores
=
=(1.85/8) X 100
= 23% of Host cores
IMPORTANT: Your server may

have other database instances
sharing the CPU resources so
take into account those too.
Also this do not mean that

server CPU is 84% Utilized!
The sum should be approx 100%. If it is

Sum of %DB way below 100% then it may mean that wait
Time events were irrelevant OR Server is
overloaded.
enq TX – row lock waited for locked rows This parameter value currently is only 0.2%
contention of total DB time so we don’t have to much
worry about it.
Say that it was higher value, 10%

then we will have to look into
root cause.
You will have to go to

“Segments by Row Lock Waits”
and see what tables are getting
locked and then you will have to
see in which SQL_ID these are
used.
DB FILE single block i/o Average I/O call is 2ms which is not very
SEQUENTIAL high. If you have say very high wait average
READ Sequential read is an index read example 100ms or 200ms, it means that
followed by table read because it is your disks are slow
doing index lookups which tells

exactly which block to go to Are your SQLs returning too
many rows, is the I/O response
pretty bad on the server, is DB
not sized to cache enough
result sets
You need to see then the “File

IO Stats” section in the AWR
report.
The event indicates that index

scan is happening while reading
data from table. High no. of such
event may be a cause of
unselective indexes i.e. oracle
optimizer is not selecting proper
indexes from set of available
indexes. This will result in extra
IO activity and will contribute to
delay in SQL execution.
Generally high no. is possible for
properly tuned application
having high transaction activity.
•If Index Range scans are
involved, more blocks than
necessary could be being
visited if the index is un-
selective.By forcing or enabling
the use of a more selective
index, we can access the same
table data by visiting fewer
index blocks (and doing fewer
physical I/Os).
•If indexes are fragmented, we

have to visit more blocks
because there is less index data
per block. In this case, re-
building the index will compact
its contents into fewer blocks.
• If the index being used has a

large Clustering Factor, then
more table data blocks have to
be visited in order to get the
rows in each index block. By
rebuilding the table with its rows
sorted by the particular index
columns we can reduce the
Clustering Factor and hence the
number of table data blocks
that we have to visit for each
index block.
LOG FILE SYNC Here Wait AVG (MS) is 6 which is not a cry
number.
Above 20ms we don’t consider good
numberAlso go to “Instance
Activity Stats” section and see
how many commits actually
happened and then see here
that what % of COMMITS have to
wait.Remember that short
transactions, frequent commits
is property of OLTP Application.
To avoid this event, identify all the tables on

which FTS is happening and create proper
indexes so that oracle will do Index scans
instead of FTS. The index scan will help in
reducing no. of IO operations.
To get an idea about tables on

which FTS is happening please
DB FILE caused due to full table scans may be
refer to “Segment Statistics” ->
SCATTERED because of insufficient indexes or un-
“Segments By Physical Read”
READ avilablity of updated statistics
section of AWR report. This
section lists down both Tables
and Indexes on which Physical
Reads are happening. Please
note that physical reads doesn’t
necessarily means FTS but a
possibility of FTS.
Concurrency, wait Concurrency wait class is not good and if

class high then need to be analyzed.
this wait event shows Temp file activity

direct path read (sort,hashes,temp tables, bitmap)
temp or direct path check pga parameter or sort area or
write temp hash area parameters. You might want
to increase them
Wait Class, helps in classifying whether the issue is Wait events are broadly classified in to
column related to application or infrastructure. different WAIT CLASSES:
Administrative
Application
Concurrency
User IO
System IO
Cluster
Commit
Configuration
Idle
Network
Indicates that particular block is being used

by more than one processes at the same.
When first process is reading the block the
other processes goes in a wait as the block
is in unshared more. Typical scenario for
this event to occur is, when we have batch
process which is continuously polling
Buffer Busy Wait database by executing particular SQL
repeatedly and there are more than one
parallel instances running for the process.
All the instances of the process will try to
access same memory blocks as the SQL
they are executing is the same. This is one
of the situation in which we experience this
event.
enq: TX – row Oracle maintenance data consistency

lock contention: with the help of locking mechanism.
When a particular row is being modified
by the process, either through Update/
Delete or Insert operation, oracle tries to
acquire lock on that row. Only when the
process has acquired lock the process
can modify the row otherwise the
process waits for the lock. This wait
situation triggers this event. The lock is
released whenever a COMMIT is issued
by the process which has acquired lock
for the row. Once the lock is released,
processes waiting on this event can
acquire lock on the row and perform
DML operation.
This enq wait occurs when application

enq: UL –
explicitly locks by executing the lock
contention:
table command.
This usually happens due to a missing

enq: TM –
foreign key constraint on a table that’s
contention
part of a DML operation.
Host CPU

A high level of DB CPU usage in the Top N Foreground Events (or Instance CPU: %Busy
CPU) does not necessarily mean that CPU is a bottleneck. In this example also we have
DB CPU as the highest consuming category in the “Top 10 Foreground Events”
Look at the Host CPU and Instance CPU sections. The key things to look for are the
values “%Idle” in the “Host CPU” section and “%Total CPU” in the “Instance CPU” section.
If the “%Idle” is low and “%Total CPU” is high then the instance could have a bottleneck
in CPU (be CPU constrained). Otherwise, the high DB CPU usage just means that the
database is spending a lot of time in CPU (processing) compared to I/O and other
events. In either case (CPU is a bottleneck or not) there could be individual expensive
SQLs with high CPU time, which could indicate suboptimal
execution plans, especially if accompanied with high (buffer) gets.
If you see in our case %idle is high 74% AND %Total CPU is just 7.45 so CPU is not a
bottle neck in this example.

are actually threads.
Here we have 8 Cores
and 8 Threads per Core
so
CPUs CPU = number of core X
number of threads per
core
=8X8
= 64
Compare Load average with Cores.
Very Ideal thing is that Load Average

Load Average should be less than Cores although this
may not be happening (any it may not be
issue also!)
Can be misleading as sometimes your %Idle can be 50%

but your server is starving for CPU.
50% means that all your cores are BUSY.

You may have free threads (CPU) but you
can not run two processes
%Idle CONCURRENTLY on same CORE.
All % in this reports are calculated based

on CPU ( which are actually threads)
Here we have 8 core system

So we have 8 cores, meaning in a 60 min hour we have
Cores 60 X 8 = 480 CPU minsand total AWR duration is
8 hoursso 480X8 = 3840 CPU minutes in
total
Instance CPU
A high level of DB CPU usage in the Top N Foreground Events (or Instance CPU: %Busy
CPU) does not necessarily mean that CPU is a bottleneck. In this example also we have
DB CPU as the highest consuming category in the “Top 10 Foreground Events”
Look at the Host CPU and Instance CPU sections. The key things to look for are the
values “%Idle” in the “Host CPU” section and “%Total CPU” in the “Instance CPU” section.
If the “%Idle” is low and “%Total CPU” is high then the instance could have a bottleneck
in CPU (be CPU constrained). Otherwise, the high DB CPU usage just means that the
database is spending a lot of time in CPU (processing) compared to I/O and other
events. In either case (CPU is a bottleneck or not) there could be individual expensive
SQLs with high CPU time, which could indicate suboptimal
execution plans, especially if accompanied with high (buffer) gets.
If you see in our case %idle is high 74% AND %Total CPU is just 7.45 so CPU is not a
bottle neck in this example.
Cache Sizes
From Oracle 10g onwards, database server does Automatic Memory Management for
PGA and SGA components. Based on load, database server keeps on allocating or
deallocating memory assigned to different components of SGA and PGA. Due to this
reason, we can observe different sizes for Buffer Cache and Shared Pool, at the
beginning or end of AWR snapshot period.
Shared Pool Statistics
If your usage is low (<85 percent) then your

Memory shared pool is over sized. if Memory Usage %
shared pool usage
Usage% is too large like 90 % it could mean that your
shared pool is tool small
If your reuse is low (<60 – 70 percent) you

Shows % of SQLs executed more may have bind variable or versioning issues.
% SQL with
than 1 time. The % should be very Ideally all the percentages in this area of the
executions >1
near to value 100. report should be as high (close to 100) as
possible.
From the memory space
memory for SQL allocated to cursors, shows which
w/exec>1 % has been used by cursors more
than 1.
Time Model Statistics

Important statistics here is the DB Time. The statistic represents total time spent in databa
the CPU time and wait time of all sessions not waiting on idle event (non-idle user session
all non-idle sessions, it is possible that the time will exceed the actual wall clock time.
Out of all the DB

of time, 108,843
query so our att
SQL EXECUTE
Time spent executing the SQL Statement so much of DB T
ELAPSED TIME
DB time and DB
wait times shou

while CPU con
CPU time pars
CPU.
Above % show
focus on. You s
DB CPU represents time spent on CPU resource by what is DB CPU
DB CPU foreground user processes. This time doesn’t
include waiting time for CPU. DB CPU usage
CPU time / NU
Where NUM_C
statistics sectio
Of course, if the
system, the for
check that, loo
directly in the O
Parse Time “Parse time elapsed” represents time spent for

Elapsed Syntax and Semantic checks.
“Hard parse include time” represents time spent for

Hard parse
Syntax and Semantic checks PLUS time spent for
elapsed time
optimizing the SQL and generating optimizer plan.
In the time model statistics hierarchy, a child

statistic may be counted under more than one
% DB Time
parent and that is why the sum of the percentages
equal more than 100
can be get by subtracting parse time from hard

soft parse
parse
Foreground Wait Class

This is of less use. A wait could have multiple possible causes (in different classes)
depending on the context. There are normally only a handful of time consuming waits,
which can be analyzed and investigated separately.
There are over 800 distinct wait events. Oracle has grouped these wait events in 12
wait classes. These wait classes are further divided in 2 categories, Administrative Wait
Class and Application Wait Class.
These wait classes gives overall information about whether the waits happening for
Application or for System events.
High User IO means,
From the pool of available indexes proper

indexes are not being used
User I/O
OR
FTS is happening on big tables with millions of
rows
Foreground Wait Events

Mostly The idle events are listed down in the end which should not be focused much.
This is useful because there could be time consuming report wait events that do not
appear in the “Top N Timed Foreground Events”.
For the larger waits look at the Wait Event Histogram to identify the distribution of
waits. Are they closely clustered around an average value or are there a wide variance
of values ? Are there a large number of smaller waits or a few larger waits ?
SQL*Net Message Idle wait event We can find the number of average inactive sessions by this
from client wait event
Number of inactive sessions

= Total Wait Time/ (AWR Time * 60)
= 12679570/ (900 * 60)
= 235 average inactive sessions
This doesn’t mean user sessions as such but

the number of such connections from
Application Server connection pool.
Shows excessive sorting/hashing/global

temp table/bitmap activity going to your
Direct path temporary tablespace. Review
read/write to PGA_AGGREGATE_TARGET settings. Even if it
temp looks like it is big enough, if you aregetting
multiple small sorts to disk it could mean your
user load is over-utilizing it.
SQL*Net
SQL*Net message to client waits almost
Message to
always indicates network contention.
client
SQL*Net more
If it is very low then it indicates that the Oracle
data from
Net session data unit size is likely set correctly.
client
Usually indicates memory starvation, look at the db cache

Db file sequential
analysis and for buffer busy waits along with cache latch
reads
issues.
Db file scattered Usually indicates excessive full table scans, look at the AWR
reads segment statistics for tables that are fully scanned
Log file related waits: Look at excessive log switches,

Log file Sync
excessive commits or slow IO subsystems.
Wait Event Histogram

This can be used to determine the distribution of wait times. These days less than 5ms
is expected and more than 10ms is considered poor. An analysis of the histogram can
indicate if a high average time is due to a few individual long waits.
DB FILE This parameter will have mostly higher number of wait

SEQUENTIAL events in the histogram.
READ
Now if you see approx 50% wait events have
less than 1 ms of wait and another 30% has
less than 2 ms. It means that our disks are
working good. Wait is low for most of the
sessions going to database.
We simply don’t want that high% (and high

wait events numbers) are above 8ms of wait.
Now if you see that the DB FILE SEQUENTIAL

READ is the key wait event then next thing
will be to find
a) which segment is the bottleneck (go to
“Segments by Physical Reads” section
b) which sql query has that segment used.
SQL ordered by Elapsed Time

This can be used to identify the long running SQLs that could be responsible for a
performance issue. It can give useful information about the CPU time, the number of
executions
and the (SQL) Module. The Top SQLs can be matched to long running or slow
Processes in the application.
In this report, look for query has low executions and high Elapsed time per Exec (s) and
this query could be a candidate for troubleshooting or optimizations. In above report,
you can see first query has maximum Elapsed time but only 2 execution. So you have
to investigate this.
NOTE 1: The Elapsed time can indicate if a SQL is multithreaded (either Parallel
DML/SQL or multiple workers). In this case the elapsed time will be multiple times the
AWR duration (or the
observed clock time of the process/SQL). The elapsed time for multithreaded SQL will
be the total of elapsed time for all workers or parallel slaves.
NOTE 2: The “SQL Ordered” sections can often contain the PL/SQL call that contains
SQLs. So in this case the procedure WF_ENGINE (via procedures) ultimately calls the
SQL b6mcn03jvfg41. Also if you see the first line here that is also a package BEGIN
XXINV7566…. and inside this package it is running the SQL query running in the line 2
which is insert into XXINV7566_IQR…..
Elapse per Elapse time in seconds for per

Exec (s) execution of the SQL.
Remember that AWR reports shows those

SQL which were in shared pool at the end of
the AWR Time.
This number should be high value

which will mean that we were
able to capture all those SQLs
Captured SQL
Shows that how many % of SQL this which consumed the DB Time.
Account for 79.1%
AWR report was able to capture and
of
show us If this is low number than try to
total DB Time
generate AWR for lower snap
duration so that we are able to
capture the required SQLs which
are consuming DB Time
Executions Total no. of executions for the SQL

during the two snapshot period.
An important point, if
executions is 0 also
sometimes, it doesn’t
means query is not
executing, this might be the
case when query was still
executing and you took
AWR report. That’s why
query completion was not
covered in Report.
Provides module detail which is executing

the SQL. Process name at the OS level is
displayed as SQL Module name.
If the module name starts with

any of the names given below,
then don’t consider these SQLs
for tuning purpose as these SQLs
are oracle internal SQLs,
DBMS,
sqlplusw,
TOAD,
rman,
SQL,
SQL Module Enterprise Manager,
ORACLE,
MMON_SLAVE,
emagent etc…
In the list XXIN1768 has two

SQLIDs. The SQL id #1 is PL/SQL
code as a wrapper and it took
around 53k seconds. The sql #2
took 51k seconds and seems to
be called in sql ID# 1, as their
module names are same. Since
the SQL#2 insert statement took
almost all of the time so we sill
focus on this query for tuning.
Elasped Time The Elapsed Time is the

sum of all individual
execution time for the
sql_id. So if multiple
sessions execute the same
SQLs, the elapsed time can
be greater than the period
of two snap_ids.
SQL ordered by CPU Time

The most useful sections are SQL ordered by Elapsed Time, CPU Time, Gets and
Reads. All the sections can be useful in identifying if a particular SQL from a particular
module was
running during the AWR report period
However, In most cases this section does not reveal much more information than the
“SQL Ordered by Elapsed Time” section. However, it does sort by CPU and can output
SQLs that are not
in the previous section.
The first and second report are part of same transaction.

Second SQL is the inside part of first PLSQL.It is
The top record
accounting huge % of the DB CPU and
in this table
remember that DB CPU was the top event in
our AWR.
SQL ordered by Gets

The most useful sections are SQL ordered by Elapsed Time, CPU Time, Gets and
Reads. All the sections can be useful in identifying if a particular SQL from a particular
module was
running during the AWR report period
This is the logical Reads from Buffer Cache
When “CPU Other” is a significant component of total Response Time, then it is likely
that the time is being spent retrieving and manipulating Blocks and Buffers
(Block accesses are also known as Buffer Gets and Logical I/Os). Then as a next step
we will come to this section to find the SQL statements that access the most blocks
because these are likely to be responsible for the majority of this time.
This section will tell you HOW MANY BLOCKS WERE READ and “SQL Ordered by
Executions” section will tell you how many rows were fetched. Many a time this and
that section will have same SQL_ID.
Now if more BLOCKS are read here and that section tells that number of rows fetched
are real low means something is not right with the query. Why it has to read so many
blocks to get less rows.May be bad execution plan.
A high number of buffer gets is one of the main indicators of SQLs with
suboptimal execution plans Example if you see in this example, insert statement in row
number 4 (which is related to PLSQL in row number 3) is doing very high number of
buffer gets for single execution..
BUT Bear in mind that the SQL could have a good execution plan and just be doing a
lot of work. So we need to bring into account the data volume (and parameters that are
getting passed to the query).
You can easily see execution plans by running @awrsqrpt.sql and passing offending
SQL_ID as parameter.
You can refer to the “SQL Ordered by Executions” after reading this section.
HOW MANY insert statement in XXINV1738 module has Gets per

Gets per
BLOCKS WERE Exec that is too high, you need to analyze the SQL with
Exec
READ some additional output such as sqlt and sqlhc.
SQL ordered by Reads

This section reports the contents of the SQL area ordered by the number of reads from
the data files and can be used to identify SQL causing IO bottlenecks which consume
the following resources.
• CPU time needed to fetch unnecessary data.
• File IO resources to fetch unnecessary data.
• Buffer resources to hold unnecessary data.
• Additional CPU time to process the query once the data is retrieved into the buffer.
• % Total can be used to evaluate the impact of each statement.
If we talk about wait time then “Wait Time” is the sum of time waited for non-idle Wait
Events. These include I/O waits for reading blocks from disk as measured by the Wait
Events ‘db file sequential read’ for single-block reads and ‘db file scattered read’ for
multi-block reads.
When such Wait Events are found to be significant components of Response Time, the
next step is to find the SQL statements that read the most blocks from disk. We will
refer to this section then.
This is the Physical Reads from Disk
If the physical I/O waits (e.g. db file sequential read, db file scattered read, direct path
read) are relatively high then this section can indicate which SQLs are responsible.
This section can help identify the SQLs that are responsible for high physical I/O and
may indicate suboptimal execution plans, particularly if the execution plan contains full
table scans or large index range scans (where more selective index scans are
preferable).
Our goal is to have this % as high as possible. Probably

breaking down this AWR into smaller interval will increase
Captured SQL
this %.
account for 76% of
total
We have seen in the “Segments by Physical Reads” section

that
MTL_ITEM_CATEGORIES account for 51.32% and looking here
the SQL_ID which is a top and having 40.18% TOTAL is using
this table.Yousee here that although it has executed 73
The top record in
times but reads per executions is high making it top query
this table
consuming physical i/o.In contrast query at number
4 in this table has been executed around 40k
times but since reads per execution is low so
number 4th query is not the top query to worry
about.
Possible reasons for high Reads per Exec are use of

unselective indexes require large numbers of blocks to be
Reads per Exec fetched where such blocks are not cached well in the buffer
cache, index fragmentation, large Clustering Factor in index
etc.
SQL ordered by Physical Reads (UnOptimized)

This section is of concern when you have exadata machine in use
Read requests that are satisfied from the Smart Flash Cache in Exadata are termed
‘optimized’ since they are returned much faster than requests from disk (the
implemention uses solid state device (SSD) technology). Additionally, read requests
accessing Storage Indexes using smart scans in Oracle Exadata V2 (and significantly
reducing I/O operations) also fall under the category ‘optimized read requests’ since
they avoid reading blocks that do not contain relevant data.
IMPORTANT: In database systems where ‘Optimized Read Requests’ are not present
(which are not using EXA) , UnOptimized Read Reqs will be equal to Physical Read
Reqs (I/O requests satisfied from disk). In this case columns ‘UnOptimized Read Reqs’
and ‘Physical Read Reqs’ will display the same values and column ‘%Opt’ will display
zero (as seen in extract from AWR report above).
Note that the ‘Physical Read Reqs’ column in the ‘SQL ordered by
Physical Reads (UnOptimized)’ section is the number of I/O
requests and not the number of blocks returned. Be careful not to
Physica Read
confuse these with the Physical Reads statistics from the AWR
Reqs
section ‘SQL ordered by Reads’, which counts database blocks read
from the disk not actual I/Os (a single I/O operation may return
many blocks from disk).
SQL ordered by Parse Calls

This section shows the number of times a statement was parsed as compared to the
number of times it was executed. One to one parse/executions may indicate that:
• Bind variables are not being used.
• On RDBMS version 8172 and higher the init.ora parameter session_cached_cursors
was not set in the init.ora (100 is usually the suggested starting value).
• The shared pool may be too small and the parse is not being retained long enough
for multiple executions.
• init.ora cursor_sharing should be set to FORCE
When “CPU Parse” is a significant component of total Response Time the next step is
to find the SQL statements that have the most parses.
AWR and Statspack list such SQL statements in sections such as “SQL ordered by
Parse Calls”.
Tablespace IO Stats
These are useful to see what your hot tablespaces are. For example, having the
SYSTEM tablespace as the number one source of IO could indicate you have improper
temporary tablespace assignments as these used to default to SYSTEM. Having the
TEMP or UNDO tablespaces in the top position has already been discussed. Usually in
an OLTP system one of your index tablespaces should be at the top. In a DWH or OLAP
a data tablespace should be at the top. Also look at the latency values. For disk based
systems 5.0 ms is considered good performance.
Av Rd(ms) on the tablespace IO stats should be controlled

under 10, which is ideal. But Avg read (ms) of up to 20 is
acceptable for IO performance.
Av Rd(ms) NOTE: When the figure in Reads column is too

low, you can ignore the Av Rd(ms).
Av Buf Wt(ms) on the tablespace IO stats should be controlled

Av Buf Wt(ms
under 10, which is ideal.
Buffer Pool Advisory

The buffer pool advisory report answers the question, how big should you make your
database buffer cache. It provides an extrapolation of the benefit or detriment that
would result if you added or removed memory from the database buffer cache. These
estimates are based on the current size of the buffer cache and the number of
logical and physical IO’s encountered during the reporting point. This report can be
very helpful in “rightsizing” your buffer cache.
See what the effect of doubling the cache size would be. If it is significant (>20 percent
reduction in physical IO) you can suggest increasing the pool.
Example here if you see when size factor goes from 1 to 1.96 , the estimated physical
read factor is going down from 1 to 0.26 which is significant drop and is good for
database.
The two ‘Size Factor’ and ‘Estimated Phys Read Factor’ columns show how quickly or
slowly number of ‘Estimated Physical Reads’ goes down or up if the size of the buffer
cache would go up or down. They greatly simplify evaluation of the buffer cache
situation, as you do not need to compare big figures in columns ‘Size for Estimate’
and especially ‘Estimated Physical Reads’.
We will also generate the AWR at good time for comparison purpose. Our intention is
to not add more buffer pool just because one bad query sucked it up ( in which case
we will focus on query and not the buffer pool).
When you see huge Physical I/O happening in other section, you may be tempted to
increase the database buffer cache in order to lessen the amount of physical I/O. That
however does not take into account the overhead of serving the bigger buffer cache
(at Oracle level, longer search for a required buffer in a much bigger space, in
particular), which may outweigh benefits of further reduction in the amount of
physical reads, especially if such a reduction is small compared with the portion of the
increased buffer cache.
Apart from default buffer cache – pool (or subpool)

which is always present, buffer cache may have other
subpools.
Buffer Cache Advisory section will then

have separate subsection for each of those
subpools distinguished from others by a
letter in the very left column of the section
as follows:
First
‘D’ – Default buffer cache (always present),
Parameter “P”
‘K’ – Keep buffer cache (if
db_keep_cache_size parameter is defined),
‘R’ – Recycle buffer cache (if
db_recycle_cache_size parameter is
defined),
<N> – Caches for non-default block sizes (if
defined with parameters
db_<N>k_cache_size)
Changing ‘Size Factor’ shows ratio of

the proposed size of the buffer cache
Size Factor (increased or decreased) to the
approximate actual size currently in use
found in the row with ‘Size Factor’ = 1.0.
HERE WE CAN SEE
THAT IF WE INCREASE
Changing ‘Estimated Phys Read Factor’ OUR BUFFER CACHE
shows ratio of the estimated number of FROM 6 GB TO 10 GB IT
Physical Reads for the proposed (increased IS HELPING US
Estimated
or decreased) size of the buffer cache to SIGNIFICANTLY
Phys Read
the number of Physical Reads calculated
Factor
for the current size of buffer cache found in THIS FACTOR
the row with ‘Estimated Phys Read Factor’ = WILL COME
1.0. DOWN FROM 1
TO 0.3.
PGA Memory Advisory

Similar to Buffer Pool Advisory, the statistic provides information on how the increase or
decrease in PGA memory will cause increase or decrease in Estd PGA Cahce Hit %.
Starting point here is “Size Factor” = 1.0. This gives current memory allocation for PGA.
In this example 12 GB is being allocated to PGA. With this allocation the Estd PGA
Cahce Hit % is 100, which is good. Hence even if we increase PGA to any value Estd
PGA Cahce Hit % won’t change. Hence it won’t be advisable to increase PGA further.
However decreasing can save memory without hitting performance
In this section, you first need to find the row with the ‘Size Factr’ column value of 1.0.
This column indicates the size factor of the PGA estimates; a value of 1 indicates the
current PGA size. The ‘PGA Target Est(MB)’ value of this row will show your current PGA
size: 12 GB in this example. Other columns you will be interested in are ‘Estd Extra W/A
MB Read/Written to Disk ‘ and ‘Estd PGA Overalloc Count’.
When you go down or up the advisory section from the row with ‘Size Factr’ = 1.0, you
get estimates for Disk usage – column ‘Estd Extra W/A MB Read/Written to Disk ‘ – for
bigger or smaller settings of PGA_AGGREGATE_TARGET. The less Disk usage figure in
this column, usually the better. A lower value means less work areas have to be spilled
to disk, enhancing performance of the Oracle instance.
The question on whether to increase or decrease the PGA_AGGREGATE_TARGET from
the current value should be always investigated. The answer depends on how much of
total memory (SGA+PGA) can be allocated for this database instance on the machine,
taking into account memory needs of other database instances on the same machine,
non-Oracle software and the OS itself. Too much memory allocated wastes memory,
and too less memory allocated causes possible performance issues in the Oracle
environment.
Shows how many times the database instance processes would

need to request more PGA memory at the OS level than the
amount shown in the ‘PGA Target Est (MB)’ value of the respective
row. Ideally this field should be 0 (indicating that the PGA is
Estd PGA
correctly sized, and no overallocations should take place), and that
Overalloc
is your equally important second goal. In the given example this
Count
goal is achieved with PGA_AGGREGATE_TARGET of even 1,536MB.
So our PGA allocation is way too high.
Shared Pool Advisory

SHARED POOL IS QUALITATIVE KIND OF POOL WHILE OTHER POOLS ARE
QUANTITATIVE POOL. This means that it greatly depends “what” you are keeping in
shared pool and not just “how much” you are keeping.
Similar to Buffer Pool Advisory and PGA, the statistic provides information on how the
increase or decrease in Shared pool memory will cause increase or decrease in Estd
LC Load Time (s).
Starting point here is “SP Size Factor” = 1.0. This gives current memory allocation for
shared pool.
In this example approx 2 GB is being allocated to shared pool. With this allocation the
Estd LC Load Time (s) is 58,972. If we increase the shared pool size to 4 GB then Estd
LC Load Time (s) will come down to value 39301. Which is not a huge benefit but still
the shared pool can be increased if possible.
Also you can analyze by the “Est LC Time Saved Factr” column . if “Est LC Time Saved
Factr” increases as the “Size Factor” increases then increasing the shared pool will
improve performance.
EST LC TIME LC means LIBRARY you have to see that if increase your shared pool then
SAVED CACHE what is the amount of this time that you can save
SGA Target Advisory
The SGA target advisory report is somewhat of a summation of all the advisory reports
previously presented in the AWR report. It helps you determine the impact of changing
the settings of the SGA target size in terms of overall database performance. The
report uses a value called DB Time as a measure of the increase or decrease in
performance relative to the memory change made. Also the report will summarize an
estimate of physical reads associated with the listed setting for the SGA.
Starting at a “Size Factor” of 1 (this indicates the current size of the SGA). If the “Est DB
Time (s)” decreases significantly as the “Size Factor” increases then increasing the SGA
will significantly reduce the physical reads and improve performance. but here in our
example the Est DB Time is not reducing as much with increase in SGA so increasing
SGA in our case will not be beneficial.
When the SQL requires a large volume of data access, increasing the SGA_TARGET
size can reduce the amount of disk I/O and improve the SQL performance.
Buffer Wait Statistics

The buffer wait statistics report helps you drill down on specific buffer wait events, and
where the waits are occurring
We focus on Total wait time(s) and in this example this value is only 702 seconds
Avg time(ms) is also only 1 ms
Enqueue Activities
The Enqueue activity report provides information on enqueues (higher level Oracle
locking) that occur. As with other reports, if you see high levels of wait times in these
reports, you might dig further into the nature of the enqueue and determine the cause
of the delays.
This can give some more information for enqueue waits (e.g. Requests, Successful
gets, Failed gets), which can give an indication of the percentage of times that an
enqueue has to wait and the number of failed gets.
In our example the top row do have failed gets but the number of waits is only 55 and
wait time (s) is also not high number. So Enqueue is not our major issue in this AWR.
Undo Segment Summary
Represents Minimum and Maximum Tuned In this example this

Min/MAX TR
Retention Minutes for Undo data. This data will help parameter can be set to
(mins)
to set the UNDO_RETENTION database parameter. 868.4 min
In this example the

Max Qry
Represents Maximum query length in seconds. max query length is
Len(s)
51,263 seconds.
STO/ OOS Represents count for Sanpshot Too Old and Out Of In this example, we can see
Space errors, occurred during the snapshot period. 0 errors occurred during this
period.
Latch Activity

The latch activity report provides information on Oracle’s low level locking mechanism
called a latch. From this report you can determine if Oracle is suffering from latching
problems, and if so, which latches are causing the greatest amount of contention on
the system.
There are a plethora of latch statistics

Misses, unless they cause significant amount of sleeps aren’t of concern
Sleeps can be a problem
May need to look at spin count if you have excessive sleeps
Spin count (undocumented (_SPIN_COUNT) was based on CPU speed and
2000 setting was several years ago
If latch waits or other latch related events aren’t showing up, then latches
probably aren’t an issue
Usually cache buffer and shared pool related latches are the major latches.
WAIT TIME (S) should be 0
(Pct Get Miss should be 0 or near 0
Segments by Logical Reads
The statistic displays segment details based on logical reads happened. Data
displayed is sorted on “Logical Reads” column in descending order. It provides
information about segments for which more logical reads are happening. Most of these
SQLs can be found under section SQL Statistics -> SQL ordered by Gets.
These reports can help you find objects that are “hot” objects in the database. You may
want to review the objects and determine why they are hot, and if there are any tuning
opportunities available on those objects (e.g. partitioning), or on SQL accessing those
objects.
When the segments are suffering from high logical I/O, those segments are listed
here. When the table has high logical reads and its index has relatively small logical
reads, there is a high possibility some SQL is using the index inefficiently, which is
making a throw-away issue in the table. Find out the columns of the condition
evaluated in the table side and move them into the index. When the index has high
logical reads, the index is used excessively with wide range. You need to reduce the
range with an additional filtering condition whose columns are in the same index.
If a SQL is suboptimal then this can indicate the tables and indexes where the
workload or throwaway occurs and where the performance issue lies. It can be
particularly useful if there are no actual statistics elsewhere (e.g. Row Source Operation
Counts (STAT lines) in the SQL Trace or no actuals in the SQLT/Display Cursor report).
Segments by Physical Reads
If there are a high number of physical read waits (db file scattered read, db file
sequential read and direct path read) then this section can indicate on which segments
(tables or
indexes) the issue occurs.
This can help identify suboptimal execution plan lines. It can also help identify changes
to tablespace and storage management that will improve performance.
When the SQLs need excessive physical reads on the particular segments, this section
lists them. You need to check if some of SQLs are using unnecessary full scan and
wide range scan.
The statistic displays segment details based on physical reads happened. Data
displayed is sorted on “Physical Reads” column in descending order. It provides
information about segments for which more physical reads are happening.
Queries using these segments should be analysed to check whether any FTS is
happening on these segments. In case FTS is happening then proper indexes should
be created to eliminate FTS. Most of these SQLs can be found under section SQL
Statistics -> SQL ordered by Reads.
These reports can help you find objects that are “hot” objects in the database. You may
want to review the objects and determine why they are hot, and if there are any tuning
opportunities available on those objects (e.g. partitioning), or on SQL accessing those
objects.
For example, if an object is showing up on the physical reads report, it may be that an
index is needed on that object.
This % number is important.

Captured Segments
It should be high value which shows that we are
account for 90.8%
looking at correct data.
MTL_ITEM_CATEGORIES account for 51.32% of the

total physical reads which is a big number. we need
to see which SQL statement is using this segment
and probably tune that SQL.
The top segment
MTL_ITEM_CATEGORIES
record
You will have to go to “SQL Ordered by
Reads” section of AWR to see which
SQL Statement is using this segment.
Segments by Row Lock Waits

If there is a high level of “enq: TX row lock contention” waits then this section can
identify the segments (tables/indexes) on which they occur.
The statistic displays segment details based on total “Row lock waits” which happened
during snapshot period. Data displayed is sorted on “Row Lock Waits” column in
descending order. It provides information about segments for which more database
locking is happening.
DML statements using these segments should be analysed further to check the
possibility of reducing concurrency due to row locking.
When the segments are suffering from Row Lock, those segments are listed in this
section. The general solution is to provide more selective condition for the SQL to lock
only rows that are restricted. Or, after DML execution, commit or rollback as soon as
possible. Or so on.
Segments by ITL Waits

If there is a high level of “enq: TX allocate ITL entry” waits then this section can identify
the segments (tables/indexes) on which they occur.
Whenver a transaction modifies segment block, it first add transaction id in the Internal
Transaction List table of the block. Size of this table is a block level configurable
parameter. Based on the value of this parameter those many ITL slots are created in
each block.
ITL wait happens in case total trasactions trying to update same block at the same
time are greater than the ITL parameter value.
Total waits happening in the example are very less, 34 is the Max one. Hence it is not
recommended to increase the ITL parameter value.
Usually when the segments are suffering from Row Lock, those segments are listed in
this section. The general solution is to provide more selective condition for the SQL to
lock only rows that are restricted. Or, after DML execution, commit or rollback as soon
as possible. Or so on.
Segments by Buffer Busy Waits
If there is a high level of “Buffer Busy Waits” waits then this section can identify the
segments (tables/indexes) on which they occur.
The section lists segments that are suffering from buffer busy waits. Based on the
reason code or class#, the treatment of each is different. The physical segment’s
attributes such as freelist, freelist groups, pctfree, pctused and so on are handled by
rebuilding the object. But before this treatment, you need to check if your SQLs can
visit different blocks at the same time if possible to avoid the contention.
Buffer busy waits happen when more than one transaction tries to access same block
at the same time. In this scenario, the first transaction which acquires lock on the block
will able to proceed further whereas other transaction waits for the first transaction to
finish.
If there are more than one instances of a process continuously polling database by
executing same SQL (to check if there are any records available for processing), same
block is read concurrently by all the instances of a process and this result in Buffer
Busy wait event.
This is one of the post in Performance Tuning Fundamentals Series. Click on below links to
read more posts from the series:
Performance Tuning Basics 1 : Selectivity and Cardinality

Performance Tuning Basics 2 : Parsing
Performance Tuning Basics 3 : Parent and Child Cursors
Performance Tuning Basics 4 : Bind Variables
Performance Tuning Basics 5 : Trace and TKPROF – Part 1: Trace
Performance Tuning Basics 6 : Trace and TKPROF – Part 2: Generating TKPROF
Performance Tuning Basics 7 : Trace and TKPROF – Part 3: Analyzing TKPROF Files
Performance Tuning Basics 8 : Trace File Analyzer (TRCA)
Performance Tuning Basics 9 : Optimizer Mode
Performance Tuning Basics 10 : Histograms
Performance Tuning Basics 11 : Steps to analyze a performance problem
Performance Tuning Basics 12 : Dynamic Performance Views
Performance Tuning Basics 13 : Automatic Workload Repository (AWR) Basics
Performance Tuning Basics 14 : Active Sessions History (ASH) Basics
Performance Tuning Basics 15 : AWR Report Analysis
Performance Tuning Basics 16 : Using SQL Tuning Health-Check Script (SQLHC)
Share
Brijesh Gogia
I’m an experienced Cloud/Oracle Applications/DBA Architect with more than 15 years of
full-time DBA/Architect experience. I have gained wide knowledge on Oracle and Non-
Oracle software stack running on-prem and on Cloud and have worked on several big
projects for multi-national companies. I enjoy working with leading-edge technology and
have a passion for Cloud architecture, automation, database performance, and stability.
Thankfully my work allows me time for researching new technologies (and to write about
them).
 Post Views: 16,827
Related Posts:
1. Performance Tuning Basics 2 : Parsing

2. Performance Tuning Basics 7 : Trace and TKPROF – Part 3: Analyzing TKPROF
Files
3. Performance Tuning Basics 6 : Trace and TKPROF – Part 2: Generating
TKPROF
4. Performance Tuning Basics 14 : Active Sessions History (ASH) Basics
5. Performance Tuning Basics 4 : Bind Variables
6. Performance Tuning Basics 12 : Dynamic Performance Views
7. Understanding SQL Execution Cycle
8. Performance Tuning Basics 3 : Parent and Child Cursors
9. Performance Tuning Basics 13 : Automatic Workload Repository (AWR) Basics
10. Performance Tuning Basics 5 : Trace and TKPROF – Part 1: Trace
CATEGORIES: Performance Tuning Series TUNING Tuning Basics
PREVIOUS POST NEXT POST

Oracle Enterprise Manager (OEM) 13c – Physical and Logical Block Corruption in
Part 3 : New Features in OEM 13c (13.2) Oracle Database
35 Comments
Bharat Kaushik
Excellent stuff Brijesh.. Really enjoyed reading it…
APRIL 14, 2018 REPLY
Mittapalli Gowri Sankar
Hi Brijesh Gogia this is really great work done for you. your research work many
people used. Please do and write more Articles AWR report for Solve performance
Issue and solutions.
Thanks,
Gowri Infosys India.
JULY 15, 2021 REPLY
Smita
Excellent article. Thanks for sharing!
MAY 11, 2018 REPLY
Ramya
Excellent article. Really liked.
FEBRUARY 26, 2019 REPLY

Abdul Taher
Hi Brijesh,
very Nice article and very help full for new DBA.
APRIL 20, 2019 REPLY
Anto
Well explained all stuffs.Thanks
MAY 27, 2019 REPLY
Deepa
Very Good Article. Thanks
JULY 12, 2019 REPLY
Rahul
Today I learned AWR report in real term. Best way of expalinning
JULY 20, 2019 REPLY
Raj kadam
Good article to understand the metrics inside db and it exactly said where to trace.
NOVEMBER 25, 2019 REPLY

harsha
you are a god
DECEMBER 10, 2019 REPLY
Kishore
Its too good.If you have any videos on these topics?
MARCH 11, 2020 REPLY
sandeep singh
Really good information.
MAY 6, 2020 REPLY
Sikam Patar
This is beyond amazing. Thank you so much for your time in writing this. Very helpful to
newcomers.
MAY 20, 2020 REPLY
Sumanta
Excellent
AUGUST 15, 2020 REPLY
Jon Adams
Very detailed and thoughtful. Thanks.
SEPTEMBER 25, 2020 REPLY
Ramakrishna
Very useful explained thoroughly.
SEPTEMBER 26, 2020 REPLY
Kishore
Hi Sir,
This is Very very helpful for beginners to understand the AWR report
Thanks for the Information.
OCTOBER 31, 2020 REPLY
Biao.You
Excellent，It is what i want
Jimmy
Thank you !!
This very helpful to me
mohan
Excellent
Aditya
Excellent stuff Brijesh !! very informative
MAY 5, 2021 REPLY
Prasad
Excellent explanation on AWR
JUNE 4, 2021 REPLY
suresh kumar
Hi Brijesh,
thanks for indeed explanation. I have one query regarding DB cpu utilization .
in your post you have mentioned DBCPU/core* 100. In my case my server have 20core
40 num cpu. CPU distributed to databases on their criticality. one of Database have
cpu_count is 19. if I have to calculate CPU utilization for this DB so it would be 19/2=9.5
make it round 10 core or I need to consider cpu_count is core value. in AWR report
under load profile DBCPU is 10.38 if I consider core (19/2=9.5 making it round 10 then
my database cpu utilization is almost 100%. Could you please explain more on this .
JULY 9, 2021 REPLY
Anonymous
Very good work ..helpful
OCTOBER 22, 2021 REPLY

Anonymous
super post
Chandru
Good Article and gives sufficient idea on AWR Analysis.
JANUARY 1, 2022 REPLY
Oscar
Nice work! Thx!
Srinivas
very good explanation . Thanks alot for sharing
aditaya dayal
you should have taken a real time example.. or awr with some issue at least
MARCH 13, 2022 REPLY
Rakesh Kumar Singh

really good article.
Thanks
JULY 7, 2022 REPLY
Anoop KC.
Really Great work!
JULY 27, 2022 REPLY
Xim
Super bien explicado, Muchas gracias!!! =)
Makara Theang
Excellent improvement, thank you!
Miguel
Excelentísimo trabajo de recopilación. Muchísimas gracias.
Vimal Rathinasamy
Thank you Brijesh for writing this. up with great Effort. This is Excellent and no words!
Leave a Reply
Comment
Name (optional)
Post Comment
© Copyright 2023 expertoracle.com

Performance Tuning Basics 15 _ AWR Report Analysis – Expert Oracle

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Performance Tuning Basics 15 _ AWR Report Analysis – Expert Oracle

Uploaded by

Copyright:

Available Formats

Performance Tuning Basics 15 : AWR Report

TIME UNITS USED IN VARIOUS SECTIONS OF AWR REPORTS

SIGNIFICANCE OF THIS SECTION:

(SAME IDEA AS CPU LOAD on

May be ~2 users were active on

If DB Time has higher value

This means that for every

Elapsed time should contain the issue

Thread count per core. It is not “actual”

STARTUP TIME Database startup time

If you have more than one node then take

PARAMETER DESCRIPTION ANALYSIS

What do you do if you find that

Just keep an eye open for any

We have 8 CORES and so we can

LOGICAL Consistent gets + db block Logical and physical reads

To explain a bit further, if

But if the data is found in

Therefore, a Logical read is

These two specific values

USER Number of user queries

The total of all parses, hard

HARD The parses requiring a How much hard parsing is

If you suspect that excessive

1) check “time model statistics”

2) see if there are any signs of

3) see if CPU is an issue.

Soft parses are not listed but

If executes per second looks enormous

Example: This numbers,

if it is high then it also suggests that

In particular, when the database is

Establishing a new database

Sort operations consume

average number of active sessions

Instance Efficiency Percentage

SIGNIFICANCE OF THIS SECTION:

PARAMETER DESCRIPTION ANALYSIS

Shows %of times Sorting

The way this ratio is computed, it will be a

Shows how often If the number of parse calls is near the

When this number is low, parsing is

If the value are low then it means that there could be a

Buffer Hit % Measures how many times

This ratio relates to requests that a server process

Library hit % is great when it is near 100%.

In this ration is low then we may need to:

Shows whether the

SIGNIFICANCE OF THIS SECTION:

PARAMETER DESCRIPTION ANALYSIS

DB Time was 1965 minutes and

=Total wait time /AWR TIME

IMPORTANT: Your server may

Also this do not mean that

The sum should be approx 100%. If it is

Say that it was higher value, 10%

You will have to go to

followed by table read because it is your disks are slow

doing index lookups which tells

You need to see then the “File

The event indicates that index

•If indexes are fragmented, we

• If the index being used has a

To avoid this event, identify all the tables on