Resolving common Oracle Wait Events using the Wait Interface

Wait Event Possible Causes Actions Remarks

db file sequential reads Use of an unselective index
Fragmented Indexes
High I/O on a particular disk or mount point
Bad application design
Index reads performance can be affected by
slow I/O subsystem and/or poor database
files layout which result in a higher average
wait time
!heck indexes on the table to ensure
that the right index is being used
!heck the column order of the index
with the "H#$# clause of the %op
&'( statements
$ebuild indexes with a high clustering
factor
Use partitioning to reduce the amount
of blocks being visited
)ake sure optimi*er statistics are up
to date
$elocate +hot, datafiles
!onsider the usage of multiple buffer
pools and cache fre-uently used
indexes/tables in the .##/ pool
Inspect the execution plans of the
&'( statements that access data
through indexes
Is it appropriate for the &'(
statements to access data through
index lookups0
Is the application an online transaction
processing 1O(%/2 or decision
support system 13&&20

"ould full table scans be more
efficient0
3o the statements use the right driving
%he Oracle process wants a block that is currently
not in the &45 and it is waiting for the database
block to be read into the &45 from disk6
&ignificant db file sequential read wait time is most
likely an application issue6
If the
3B57I83#9#&6!(U&%#$I847F5!%O$ of the
index approaches the number of blocks in the
table then most of the rows in the table are
ordered6 %his is desirable6
However if the clustering factor approaches the
number of rows in the table it means the rows in
the table are randomly ordered and thus it re-uires
more I/Os to complete the operation6 :ou can
improve the index,s clustering factor by rebuilding
the table so that rows are ordered according to the
index key and rebuilding the index thereafter6
%he O/%I)I;#$7I83#97!O&%753< and
O/%I)I;#$7I83#97!5!HI84 initiali*ation
parameters can influence the optimi*er to favour
the nested loops operation and choose an index
access path over a full table scan6
%uning I/O related waits 8ote= >>?@@A6@
db file se-uential read $eference 8ote= ?BCCD6@
table0
%he optimi*ation goal is to minimi*e
both the number of logical and
physical I/Os6
db file scattered reads
%he Oracle session has re-uested and is
waiting for multiple contiguous database
blocks 1up to 3B7FI(#7)U(%IB(O!.7$#537!OU8%2 to
be
read into the &45 from disk6
Full %able scans
Fast Full Index &cans
Optimi*e multiEblock I/O by setting the
parameter
3B7FI(#7)U(%IB(O!.7$#537!OU8%
/artition pruning to reduce number of
blocks visited
!onsider the usage of multiple buffer
pools and cache fre-uently used
indexes/tables in the .##/ pool
Optimi*e the &'( statement that
initiated most of the waits6 %he goal is
to minimi*e the number of physical
and logical reads6
&hould the statement access the data
by a full table scan or index FF&0
"ould an index range or uni-ue scan
be more efficient0
3oes the -uery use the right driving
table0
5re the &'( predicates appropriate
for hash or merge Foin0
If full scans are appropriate can
parallel -uery improve the response
time0
%he obFective is to reduce the
demands for both the logical and
physical I/Os and this is best
achieved through &'( and application tuning6
)ake sure all statistics are
representative of the actual data6
!heck the (5&%7585(:;#3 date
If an application that has been running fine for a
while suddenly clocks a lot of time on the db file
scattered read event and there hasn,t been a code
change you might want to check to see if one or
more indexes has been dropped or become
unusable6
db file scattered read $eference 8ote= ?BCCG6@
log file parallel write (4"$ waits while writing contents of the
redo log buffer cache to the online log files
on disk
I/O wait on sub system holding the online
redo log files
$educe the amount of redo being
generated
3o not leave tablespaces in hot
backup mode for longer than
necessary
3o not use $5I3 C for redo log files
Use faster disks for redo log files
#nsure that the disks holding the
archived redo log files and the online
redo log files are separate so as to
avoid contention
!onsider using 8O(O44I84 or
U8$#!OH#$5B(# options in &'(
statements
$eference 8ote= ?BCG?6@
log file snc Oracle foreground processes are waiting
for a !O))I% or $O((B5!. to complete
%une (4"$ to get good throughput to
disk egI 3o not put redo logs on
$5I3C
$educe overall number of commits by
batching transactions so that there
are fewer distinct !O))I% operations
$eference 8ote= ?BCD>6@
High "aits on log file sync 8ote= @>C>JD6@
%uning the $edolog Buffer !ache and $esolving
$edo (atch !ontention
8ote= @BABA@6@
buffer bus waits Buffer busy waits are common in an I/OE
bound Oracle system6
%he two main cases where this can occur
areI
5nother session is reading the block into the
buffer
%he main way to reduce buffer busy
waits is to reduce the total I/O on the
system
3epending on the block type the
actions will differ
!ata "locks
#liminate HO% blocks from the
application6
5 process that waits on the buffer busy waits event
publishes the reason code in the /? parameter of
the wait event6
%he Oracle )etalink note = ?BBKC6@ provides a
table of reference E codes @?K and >>K are the
most common6
$esolving intense and random buffer busy wait
performance problems6 8ote= @CCDA@6@
5nother session holds the buffer in an
incompatible mode to our re-uest
%hese waits indicate read/read read/write
or write/write contention6
%he Oracle session is waiting to pin a buffer6
5 buffer must be pinned before it can be
read or modified6 Only one process can pin a
buffer at any one time6
%his wait can be intensified by a large block
si*e as more rows can be contained within
the block
%his wait happens when a session wants to
access a database block in the buffer cache
but it cannot as the buffer is Lbusy
It is also often due to several processes
repeatedly reading the same blocks 1egI if
lots of people scan the same index or data
block2
!heck for repeatedly scanned /
unselective indexes6
%ry rebuilding the obFect with a higher
/!%F$## so that you reduce the
number of rows per block6
!heck for MrightE handEindexesM
1indexes that get inserted into at the
same point by many processes26
Increase I8I%$58& and )59%$58&
and reduce /!%U&#3 %his will make
the table less dense 6
$educe the number of rows per block
#egment $eader
Increase of number of F$##(I&%s
and F$##(I&% 4$OU/s
%ndo $eader
Increase the number of $ollback
&egments
free buffer waits %his means we are waiting for a free buffer
but there are none available in the cache
because there are too many dirty buffers in
the cache
#ither the buffer cache is too small or the
3B"$ is slow in writing modified buffers to
disk
3B"$ is unable to keep up to the write
re-uests
!heckpoints happening too fast N maybe due
to high database activity and underEsi*ed
online redo log files
$educe checkpoint fre-uency E
increase the si*e of the online redo
log files
#xamine the si*e of the buffer cache
N consider increasing the si*e of the
buffer cache in the &45
&et disk7asynch7io O true set
If not using asynchronous I/O
increase the number of db writer
processes or dbwr slaves
Understanding and %uning Buffer !ache and
3B"$ 8ote= J>@A>6@
How to Identify a Hot Block within the database
Buffer !ache6
8ote= @J?B>B6@
(arge sorts and full table scans are filling the
cache with modified blocks faster than the
3B"$ is able to write to disk
If the number of dirty buffers that need to be
written to disk is larger than the number that
3B"$ can write per batch then these waits
can be observed
#nsure hot spots do not exist by
spreading datafiles over disks and
disk controllers
/reEsorting or reorgani*ing data can
help
enqueue waits %his wait event indicates a wait for a lock
that is held by another session 1or sessions2
in an incompatible mode to the re-uested
mode6
&' &ransaction (ock
4enerally due to table or application set up
issues
%his indicates contention for rowElevel lock6
%his wait occurs when a transaction tries to
update or delete rows that are currently
locked by another transaction6
%his usually is an application issue6
&) !)( enqueue lock
4enerally due to application issues
particularly if foreign key constraints have
not been indexed6
#& lock
3atabase actions that modify the U#%P 1used
extent2 and F#%P 1free extent2 tables re-uire
$educe waits and wait times
%he action to take depends on the lock
type which is causing the most problems
"henever you see an enqueue wait
event for the %9 en-ueue the first
step is to find out who the blocker is
and if there are multiple waiters for
the same resource
"aits for %) en-ueue in )ode ? are primarily due
to unindexed foreign key columns6
!reate indexes on foreign keys Q @Kg
Following are some of the things you
can do to minimi*e &% lock contention
in your databaseI
Use locally managed tablespaces
$ecreate all temporary tablespaces
using the !$#5%# %#)/O$5$:
%5B(#&/5!# %#)/FI(#R command6

)aximum number of en-ueue resources that can
be concurrently locked is controlled by the
#8'U#U#7$#&OU$!#& parameter6
$eference 8ote= ?BCJJ6@
%racing sessions waiting on an en-ueue 8ote=
@K>D>C6@
3etails of HP(O!. view and lock modes
8oteI>DAGA6@
the &% lock which includes actions such as
drop truncate and coalesce6
!ontention for the &% lock indicates there are
multiple sessions actively performing
dynamic disk space allocation or deallocation
in dictionary managed tablespaces
Cache buffer chain latch %his latch is ac-uired when searching
for data blocks
Buffer cache is a chain of blocks and
each chain is protected by a child
latch when it needs to be scanned
Hot blocks are another common
cause of cache buffers chains latch
contention6 %his happens when
multiple sessions repeatedly access
one or more blocks that are
protected by the same child cache
buffers chains latch6
&'( statements with high
BUFF#$74#%& 1logical reads2 per
#9#!U%IO8& are the main culprits
)ultiple concurrent sessions are
executing the same inefficient &'(
that is going after the same data set
$educing contention for the cache
buffer chains latch will usually re-uire
reducing logical I/O rates by tuning
and minimi*ing the I/O re-uirements of
the &'( involved6 High I/O rates could
be a sign of a hot block 1meaning a
block highly accessed26
#xporting the table increasing the
/!%F$## significantly and importing
the data6 %his minimi*es the number of
rows per block spreading them over
many blocks6 Of course this is at the
expense of storage and full table
scans operations will be slower
)inimi*ing the number of records per
block in the table
For indexes you can rebuild them
with higher /!%F$## values bearing
in mind that this may increase the
height of the index6
%he default number of hash latches is usually @K>B
%he number of hash latches can be adFusted by the
parameter 73B7B(O!.&7H5&H7(5%!H#&
"hat are latches and what causes
latch contention
!onsider reducing the block si*e
&tarting in OracleDi 3atabase Oracle
supports multiple block si*es6 If the
current block si*e is @J. you may
move the table or recreate the index in
a tablespace with an G. block si*e6
%his too will negatively impact full
table scans operations6 5lso various
block si*es increase management
complexity6
Cache buffer (R% chain latch /rocesses need to get this latch when they
need to move buffers based on the ($U
block replacement policy in the buffer cache
%he cache buffer lru chain latch is ac-uired
in order to introduce a new block into the
buffer cache and when writing a buffer
back to disk specifically when trying to
scan the ($U 1least recently used2 chain
containing all the dirty blocks in the buffer
cache6
!ompetition for the cache buffers lru chain
latch is symptomatic of intense buffer cache
activity caused by inefficient &'(
statements6 &tatements that repeatedly scan
large unselective indexes or perform full
table scans are the prime culprits6
Heavy contention for this latch is generally
due to heavy buffer cache activity which
can be caused for example byI
!ontention in this latch can be
avoided implementing multiple
buffer pools or increasing the
number of ($U latches with the
parameter 3B7B(O!.7($U7(5%!H#&
1%he default value is generally
sufficient for most systems26
Its possible to reduce
contention for the cache buffer
lru chain latch by increasing the
si*e of the buffer cache and
thereby reducing the rate at
which new blocks are
introduced into the buffer cache
$epeatedly scanning large unselective
indexes
!irect Path Reads %hese waits are associated with direct read operations
which read data directly into the sessions /45 bypassing
the &45
%he Ldirect path readL and Ldirect path writeL wait events
are related to operations that are performed in /45 like
sorting group by operation hash Foin
In 3&& type systems or during heavy batch periods waits
on Ldirect path readL are -uite normal
However for an O(%/ system these waits are significant
%hese wait events can occur during sorting operations
which is not surprising as direct path reads and writes
usually occur in connection with temporary tsegments
&'( statements with functions that re-uire sorts such as
O$3#$ B: 4$OU/ B: U8IO8 3I&%I8!% and
$O((U/ write sort runs to the temporary tablespace when
the input si*e is larger than the work area in the /45
#nsure the O& asynchronous IO is configured
correctly6
!heck for IO heavy sessions / &'( and see if the
amount of IO can be reduced6
#nsure no disks are IO bound6
&et your /457544$#45%#7%5$4#% to
appropriate value 1if the parameter
"O$.5$#57&I;#7/O(I!: O 5U%O2
Or set S7area7si*e manually 1like sort7area7si*e
and then you have to set
"O$.5$#57&I;#7/O(I!: O )58U5(
"henever possible use U8IO8 5(( instead of
U8IO8 and where applicable use H5&H <OI8
instead of &O$% )#$4# and 8#&%#3 (OO/&
instead of H5&H <OI86
3efault si*e of H5&H75$#57&I;# is twice that of
&O$%75$#57&I;#
(arger H5&H75$#57&I;# will influence optimi*er
to go for hash Foins instead of nested loops
Hidden parameter 3B7FI(#73I$#!%7IO7!OU8%
can impact the direct path read performance6It sets
the maximum I/O buffer si*e of direct read and
write operations6 3efault is @) in Di
How to identify resource intensive &'(
statements0
)ake sure the optimi*er selects the right driving
table6 !heck to see if the composite index,s
columns can be rearranged to match the O$3#$
B: clause to avoid sort entirely6
5lso consider automating the &'( work areas
using /457544$#45%#7%5$4#% in OracleDi
3atabase6
'uery HP&#&&%5%T to identify sessions with high
Lphysical reads directL
!irect Path Writes %hese are waits that are associated with
direct write operations that write data from
users, /45s to data files or temporary
tablespaces
3irect load operations 1egI !reate %able as
&elect 1!%5&2 may use this2
/arallel 3)( operations
&ort IO 1when a sort does not fit in memory
If the file indicates a temporary
tablespace check for unexpected disk
sort operations6
#nsure
Q/arameterI3I&.75&:8!H7IOT is
%$U# 6 %his is unlikely to reduce wait
times from the wait event timings but
may reduce sessions elapsed times
1as synchronous direct IO is not
accounted for in wait event timings26
#nsure the O& asynchronous IO is
configured correctly6
#nsure no disks are IO bound
(atch *ree Waits
%his wait indicates that the process is
waiting for a latch that is currently busy
1held by another process26
"hen you see a latch free wait event in the
HP&#&&IO87"5I% view it means the
process failed to obtain the latch in the
willingEtoEwait mode after spinning
7&/I87!OU8% times and went to sleep6
"hen processes compete heavily for
latches they will also consume more !/U
resources because of spinning6 %he result is
a higher response time
If the %I)# spent waiting for latches is
significant then it is best to determine
which latches are suffering from
contention6
5 latch is a kind of low level lock6
(atches apply only to memory
structures in the &456 %hey do not
apply to database obFects6 5n Oracle
&45 has many latches and they
exist to protect various memory
structures from potential corruption
by concurrent access6
%he time spent on latch waits is an
effect not a causeU the cause is that
you are doing too many block gets
and block gets re-uire
cache buffer chain latching
"hat are (atches and what causes
(atch contention
3atabase (ock and (atch Information
.nowledge Browser /roduct /age
(ibrar cache latch %he library cache latches protect the
cached &'( statements and obFects
definitions held in the library cache within the
shared pool6 %he library cache latch must be
ac-uired in order to add a new statement to
the library cache
5pplication is making heavy use of literal
&'(E use of bind variables will reduce this
latch considerably
(atch is to ensure that the application
is reusing as much as possible &'(
statement representation6 Use bind
variables whenever possible in the
application
:ou can reduce the library cache
latch hold time by properly setting the
&#&&IO87!5!H#37!U$&O$& parameter
!onsider increasing shared pool
(arger shared pools tend to have
long free lists and processes that
need to allocate space in them must
spend extra time scanning the long
free lists while holding the shared
pool latch
if your database is not yet on
OracleDi 3atabase an oversi*ed
shared pool can increase the
contention for the shared pool latch6
#hared pool latch %he shared pool latch is used to protect
critical operations when allocating and
freeing memory in the shared pool
!ontentions for the shared pool and library
"ays to reduce the shared pool latch
are avoid hard parses when
possible parse once execute many6
#liminating literal &'( is also useful to
+,ote -./012/3 explains how to
identify and correct problems with the
shared pool and shared pool latch6
cache latches are mainly due to intense hard
parsing6 5 hard parse applies to new
cursors and cursors that are aged out and
must be reEexecuted
%he cost of parsing a new &'( statement is
expensive both in terms of
!/U re-uirements and the number of times
the library cache and shared pool latches
may need to be ac-uired and released6
avoid the shared pool latch6 %he si*e
of the shared7pool and use of )%&
1shared server option2 also greatly
influences the shared pool latch6
%he workaround is to set the
initiali*ation parameter
!U$&O$7&H5$I84 to FO$!#6 %his
allows statements that differ in literal
values but are otherwise identical to
share a cursor and therefore reduce
latch contention memory usage and
hard parse6
Row cache ob4ects latch %his latch comes into play when user
processes are attempting to access the
cached data dictionary values6
It is not common to have contention in
this latch and the only way to reduce
contention for this latch is by
increasing the si*e of the shared pool
1&H5$#37/OO(7&I;#26
Use (ocally )anaged tablespaces for
your application obFects especially
indexes
$eview and amend your database
logical design a good example is to
merge or decrease the number of
indexes on tables with heavy inserts
!onfiguring the library cache to an
acceptable si*e usually ensures that
the data dictionary cache is also
properly si*ed6 &o tuning (ibrary
!ache will tune $ow !ache indirectly