Resolving common Oracle Wait Events using the Wait Interface

Wait Event Possible Causes Actions Remarks

db fle 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 afected by
slo I/O subsystem and/or poor database
!les layout" hich result in a higher average
ait time
#heck indexes on the table to ensure
that the right index is being used
#heck the column order of the index
ith the $H%&% clause of the 'op
()* statements
&ebuild indexes ith 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. data!les
#onsider the usage of multiple bufer
pools and cache fre/uently used
indexes/tables in the 0%%1 pool
Inspect the execution plans of the
()* statements that access data
through indexes
Is it appropriate for the ()*
statements to access data through
index lookups2
Is the application an online transaction
processing 3O*'14 or decision
support system 35((42

$ould full table scans be more
e6cient2
'he Oracle process ants a block that is
currently not in the (78" and it is aiting for
the database block to be read into the (78
from disk9
(igni!cant db fle sequential read ait time
is most likely an application issue9
If the
5B8:I;5%<%(9#*U('%&I;7:F8#'O& of the
index approaches the number of blocks in
the table" then most of the ros in the table
are ordered9 'his is desirable9
Hoever" if the clustering factor approaches
the number of ros in the table" it means
the ros in the table are randomly ordered
and thus it re/uires more I/Os to complete
the operation9 =ou can improve the index.s
clustering factor by rebuilding the table so
that ros are ordered according to the index
key and rebuilding the index thereafter9
'he O1'I+I>%&:I;5%<:#O(':85? and
O1'I+I>%&:I;5%<:#8#HI;7 initiali,ation
parameters can in@uence the optimi,er to
favour the nested loops operation and
choose an index access path over a full table
scan9
'uning I/O related aits ;oteA BBCDDE9D
db !le se/uential read &eference ;oteA
CFGGH9D
5o the statements use the right driving
table2
'he optimi,ation goal is to minimi,e
both the number of logical and
physical I/Os9
db fle scattered reads
'he Oracle session has re/uested and is
aiting for multiple contiguous database
blocks 3up to 5B:FI*%:+U*'IB*O#0:&%85:#OU;'4
to be
read into the (78 from disk9
Full 'able scans
Fast Full Index (cans
Optimi,e multiIblock I/O by setting the
parameter
5B:FI*%:+U*'IB*O#0:&%85:#OU;'
1artition pruning to reduce number of
blocks visited
#onsider the usage of multiple bufer
pools and cache fre/uently used
indexes/tables in the 0%%1 pool
Optimi,e the ()* statement that
initiated most of the aits9 'he goal is
to minimi,e the number of physical
and logical reads9
(hould the statement access the data
by a full table scan or index FF(2
$ould an index range or uni/ue scan
be more e6cient2
5oes the /uery use the right driving
table2
8re the ()* predicates appropriate
for hash or merge Join2
If full scans are appropriate" can
parallel /uery improve the response
time2
'he obJective is to reduce the
demands for both the logical and
physical I/Os" and this is best
achieved through ()* and application
tuning9
If an application that has been running !ne
for a hile suddenly clocks a lot of time on
the db fle scattered read event and there
hasn.t been a code change" you might ant
to check to see if one or more indexes has
been dropped or become unusable9
db !le scattered read &eference ;oteA
CFGGK9D
+ake sure all statistics are
representative of the actual data9
#heck the *8(':8;8*=>%5 date
log fle parallel rite *7$& aits hile riting contents of the
redo log bufer cache to the online log !les
on disk
I/O ait on sub system holding the online
redo log !les
&educe the amount of redo being
generated
5o not leave tablespaces in hot
backup mode for longer than
necessary
5o not use &8I5 G for redo log !les
Use faster disks for redo log !les
%nsure that the disks holding the
archived redo log !les and the online
redo log !les are separate so as to
avoid contention
#onsider using ;O*O77I;7 or
U;&%#OL%&8B*% options in ()*
statements
&eference ;oteA CFGKC9D
log fle s!nc Oracle foreground processes are aiting
for a #O++I' or &O**B8#0 to complete
'une *7$& to get good throughput to
disk egM 5o not put redo logs on
&8I5G
&educe overall number of commits by
batching transactions so that there
are feer distinct #O++I' operations
&eference ;oteA CFGHB9D
High $aits on log !le sync ;oteA DBGBNH9D
'uning the &edolog Bufer #ache and
&esolving &edo *atch #ontention
;oteA DFEFED9D
bu"er bus! aits Bufer busy aits are common in an I/OI
bound Oracle system9
'he to main cases here this can occur
'he main ay to reduce bufer busy
aits is to reduce the total I/O on the
system
8 process that aits on the bufer busy waits
event publishes the reason code in the 1C
parameter of the ait event9
areM
8nother session is reading the block into the
bufer
8nother session holds the bufer in an
incompatible mode to our re/uest
'hese aits indicate read/read" read/rite"
or rite/rite contention9
'he Oracle session is aiting to pin a bufer9
8 bufer must be pinned before it can be
read or modi!ed9 Only one process can pin a
bufer at any one time9
'his ait can be intensi!ed by a large block
si,e as more ros can be contained ithin
the block
'his ait happens hen a session ants to
access a database block in the bufer cache
but it cannot as the bufer is Obusy
It is also often due to several processes
repeatedly reading the same blocks 3egM if
lots of people scan the same index or data
block4
5epending on the block type" the
actions ill difer
#ata $locks
%liminate HO' blocks from the
application9
#heck for repeatedly scanned /
unselective indexes9
'ry rebuilding the obJect ith a higher
1#'F&%% so that you reduce the
number of ros per block9
#heck for PrightI handIindexesP
3indexes that get inserted into at the
same point by many processes49
Increase I;I'&8;( and +8<'&8;(
and reduce 1#'U(%5 'his ill make
the table less dense 9
&educe the number of ros per block
%egment &eader
Increase of number of F&%%*I('s
and F&%%*I(' 7&OU1s
'ndo &eader
Increase the number of &ollback
(egments
'he Oracle +etalink note A CFFQG9D provides
a table of reference I codes DCQ and BBQ are
the most common9
&esolving intense and random bufer busy
ait performance problems9 ;oteA DGGHED9D
free bu"er aits 'his means e are aiting for a free bufer
but there are none available in the cache
because there are too many dirty bufers in
the cache
%ither the bufer cache is too small or the
5B$& is slo in riting modi!ed bufers to
&educe checkpoint fre/uency I
increase the si,e of the online redo
log !les
%xamine the si,e of the bufer cache
R consider increasing the si,e of the
bufer cache in the (78
Understanding and 'uning Bufer #ache and
5B$& ;oteA NBDEB9D
Ho to Identify a Hot Block ithin the
database Bufer #ache9
;oteA DNCFBF9D
disk
5B$& is unable to keep up to the rite
re/uests
#heckpoints happening too fast R maybe due
to high database activity and underIsi,ed
online redo log !les
*arge sorts and full table scans are !lling the
cache ith modi!ed blocks faster than the
5B$& is able to rite to disk
If the number of dirty bufers that need to be
ritten to disk is larger than the number that
5B$& can rite per batch" then these aits
can be observed
(et disk:asynch:io S true set
If not using asynchronous I/O
increase the number of db riter
processes or dbr slaves
%nsure hot spots do not exist by
spreading data!les over disks and
disk controllers
1reIsorting or reorgani,ing data can
help
enqueue aits 'his ait event indicates a ait for a lock
that is held by another session 3or sessions4
in an incompatible mode to the re/uested
mode9
() (ransaction *ock
7enerally due to table or application set up
issues
'his indicates contention for roIlevel lock9
'his ait occurs hen a transaction tries to
update or delete ros that are currently
locked by another transaction9
'his usually is an application issue9
(+ #+* enqueue lock
7enerally due to application issues"
particularly if foreign key constraints have
&educe aits and ait times
'he action to take depends on the lock
type hich is causing the most problems
$henever you see an enqueue ait
event for the '< en/ueue" the !rst
step is to !nd out ho the blocker is
and if there are multiple aiters for
the same resource
$aits for '+ en/ueue in +ode C are
primarily due to unindexed foreign key
columns9
#reate indexes on foreign keys T DQg
Folloing are some of the things you
can do to minimi,e (' lock contention
in your databaseM
Use locally managed tablespaces
+aximum number of en/ueue resources that
can be concurrently locked is controlled by
the %;)U%U%:&%(OU&#%( parameter9
&eference ;oteA CFGNN9D
'racing sessions aiting on an en/ueue
;oteA DQBHBG9D
5etails of LU*O#0 vie and lock modes
;oteMBHEKE9D
not been indexed9
%( lock
5atabase actions that modify the U%'U 3used
extent4 and F%'U 3free extent4 tables re/uire
the (' lock" hich includes actions such as
drop" truncate" and coalesce9
#ontention for the (' lock indicates there are
multiple sessions actively performing
dynamic disk space allocation or deallocation
in dictionary managed tablespaces
&ecreate all temporary tablespaces
using the #&%8'% '%+1O&8&=
'8B*%(18#% '%+1FI*%V command9

Cache bu"er chain latch 'his latch is ac/uired hen searching
for data blocks
Bufer cache is a chain of blocks and
each chain is protected by a child
latch hen it needs to be scanned
Hot blocks are another common
cause of cache bufers chains latch
contention9 'his happens hen
multiple sessions repeatedly access
one or more blocks that are
protected by the same child cache
bufers chains latch9
()* statements ith high
BUFF%&:7%'( 3logical reads4 per
%<%#U'IO;( are the main culprits
+ultiple concurrent sessions are
&educing contention for the cache
bufer chains latch ill usually re/uire
reducing logical I/O rates by tuning
and minimi,ing the I/O re/uirements of
the ()* involved9 High I/O rates could
be a sign of a hot block 3meaning a
block highly accessed49
%xporting the table" increasing the
1#'F&%% signi!cantly" and importing
the data9 'his minimi,es the number of
ros per block" spreading them over
many blocks9 Of course" this is at the
expense of storage and full table
scans operations ill be sloer
'he default number of hash latches is
usually DQBF
'he number of hash latches can be adJusted
by the parameter
:5B:B*O#0(:H8(H:*8'#H%(
$hat are latches and hat causes
latch contention
executing the same ine6cient ()*
that is going after the same data set
+inimi,ing the number of records per
block in the table
For indexes" you can rebuild them
ith higher 1#'F&%% values" bearing
in mind that this may increase the
height of the index9
#onsider reducing the block si,e
(tarting in OracleHi 5atabase" Oracle
supports multiple block si,es9 If the
current block si,e is DN0" you may
move the table or recreate the index in
a tablespace ith an K0 block si,e9
'his too ill negatively impact full
table scans operations9 8lso" various
block si,es increase management
complexity9
Cache bu"er *R' chain latch 1rocesses need to get this latch hen they
need to move bufers based on the *&U
block replacement policy in the bufer cache
'he cache bufer lru chain latch is ac/uired
in order to introduce a ne block into the
bufer cache and hen riting a bufer
back to disk" speci!cally hen trying to
scan the *&U 3least recently used4 chain
containing all the dirty blocks in the bufer
cache9
#ompetition for the cache bufers lru chain
latch is symptomatic of intense bufer cache
activity caused by ine6cient ()*
statements9 (tatements that repeatedly scan
#ontention in this latch can be
avoided implementing multiple
bufer pools or increasing the
number of *&U latches ith the
parameter 5B:B*O#0:*&U:*8'#H%(
3'he default value is generally
su6cient for most systems49
Its possible to reduce
contention for the cache bufer
lru chain latch by increasing the
si,e of the bufer cache and
thereby reducing the rate at
hich ne blocks are
introduced into the bufer cache
large unselective indexes or perform full
table scans are the prime culprits9
Heavy contention for this latch is generally
due to heavy bufer cache activity hich
can be caused" for example" byM
&epeatedly scanning large unselective
indexes
#irect Path Reads 'hese aits are associated ith direct read
operations hich read data directly into the
sessions 178 bypassing the (78
'he Odirect path readO and Odirect path riteO ait
events are related to operations that are performed
in 178 like sorting" group by operation" hash Join
In 5(( type systems" or during heavy batch periods"
aits on Odirect path readO are /uite normal
Hoever" for an O*'1 system these aits are
signi!cant
'hese ait events can occur during sorting
operations hich is not surprising as direct path
reads and rites usually occur in connection ith
temporary tsegments
()* statements ith functions that re/uire sorts"
such as O&5%& B=" 7&OU1 B=" U;IO;" 5I('I;#'"
and &O**U1" rite sort runs to the temporary
tablespace hen the input si,e is larger than the
ork area in the 178
%nsure the O( asynchronous IO is con!gured
correctly9
#heck for IO heavy sessions / ()* and see if
the amount of IO can be reduced9
%nsure no disks are IO bound9
(et your 178:877&%78'%:'8&7%' to
appropriate value 3if the parameter
$O&08&%8:(I>%:1O*I#= S 8U'O4
Or set W:area:si,e manually 3like
sort:area:si,e and then you have to set
5efault si,e of H8(H:8&%8:(I>% is tice
that of (O&':8&%8:(I>%
*arger H8(H:8&%8:(I>% ill in@uence
optimi,er to go for hash Joins instead of
nested loops
Hidden parameter
5B:FI*%:5I&%#':IO:#OU;' can impact the
direct path read performance9It sets the
maximum I/O bufer si,e of direct read and
rite operations9 5efault is D+ in Hi
Ho to identify resource intensive ()*
statements2
$O&08&%8:(I>%:1O*I#= S +8;U8*
$henever possible use U;IO; 8** instead of
U;IO;" and here applicable use H8(H ?OI;
instead of (O&' +%&7% and ;%('%5 *OO1(
instead of H8(H ?OI;9
+ake sure the optimi,er selects the right
driving table9 #heck to see if the composite
index.s columns can be rearranged to match
the O&5%& B= clause to avoid sort entirely9
8lso" consider automating the ()* ork
areas using 178:877&%78'%:'8&7%' in
OracleHi 5atabase9
)uery LU(%(('8'X to identify sessions ith
high Ophysical reads directO
#irect Path Writes 'hese are aits that are associated ith
direct rite operations that rite data from
users. 178s to data !les or temporary
tablespaces
5irect load operations 3egM #reate 'able as
(elect 3#'8(4 may use this4
1arallel 5+* operations
If the !le indicates a temporary
tablespace check for unexpected disk
sort operations9
%nsure
T1arameterM5I(0:8(=;#H:IOX is
'&U% 9 'his is unlikely to reduce ait
times from the ait event timings but
may reduce sessions elapsed times
3as synchronous direct IO is not
accounted for in ait event timings49
(ort IO 3hen a sort does not !t in memory
%nsure the O( asynchronous IO is
con!gured correctly9
%nsure no disks are IO bound
*atch ,ree Waits
'his ait indicates that the process is
aiting for a latch that is currently busy
3held by another process49
$hen you see a latch free ait event in the
LU(%((IO;:$8I' vie" it means the
process failed to obtain the latch in the
illingItoIait mode after spinning
:(1I;:#OU;' times and ent to sleep9
$hen processes compete heavily for
latches" they ill also consume more #1U
resources because of spinning9 'he result is
a higher response time
If the 'I+% spent aiting for latches is
signi!cant then it is best to determine
hich latches are sufering from
contention9
8 latch is a kind of lo level lock9
*atches apply only to memory
structures in the (789 'hey do not
apply to database obJects9 8n Oracle
(78 has many latches" and they
exist to protect various memory
structures from potential corruption
by concurrent access9
'he time spent on latch aits is an
efect" not a causeY the cause is that
you are doing too many block gets"
and block gets re/uire
cache bufer chain latching
$hat are *atches and hat causes
*atch contention
5atabase *ock and *atch Information
0noledge Broser 1roduct 1age
*ibrar! cache latch 'he library cache latches protect the
cached ()* statements and obJects
*atch is to ensure that the application
is reusing as much as possible ()*
*arger shared pools tend to have
long free lists and processes that
de!nitions held in the library cache ithin the
shared pool9 'he library cache latch must be
ac/uired in order to add a ne statement to
the library cache
8pplication is making heavy use of literal
()*I use of bind variables ill reduce this
latch considerably
statement representation9 Use bind
variables henever possible in the
application
=ou can reduce the library cache
latch hold time by properly setting the
(%((IO;:#8#H%5:#U&(O&( parameter
#onsider increasing shared pool
need to allocate space in them must
spend extra time scanning the long
free lists hile holding the shared
pool latch
if your database is not yet on
OracleHi 5atabase" an oversi,ed
shared pool can increase the
contention for the shared pool latch9
%hared pool latch 'he shared pool latch is used to protect
critical operations hen allocating and
freeing memory in the shared pool
#ontentions for the shared pool and library
cache latches are mainly due to intense hard
parsing9 8 hard parse applies to ne
cursors and cursors that are aged out and
must be reIexecuted
'he cost of parsing a ne ()* statement is
expensive both in terms of
#1U re/uirements and the number of times
the library cache and shared pool latches
may need to be ac/uired and released9
$ays to reduce the shared pool latch
are" avoid hard parses hen
possible" parse once" execute many9
%liminating literal ()* is also useful to
avoid the shared pool latch9 'he si,e
of the shared:pool and use of +'(
3shared server option4 also greatly
in@uences the shared pool latch9
'he orkaround is to set the
initiali,ation parameter
#U&(O&:(H8&I;7 to FO&#%9 'his
allos statements that difer in literal
values but are otherise identical to
share a cursor and therefore reduce
latch contention" memory usage" and
hard parse9
-.ote /0123415 explains ho to
identify and correct problems ith the
shared pool" and shared pool latch9
Ro cache ob6ects latch 'his latch comes into play hen user
processes are attempting to access the
cached data dictionary values9
It is not common to have contention in
this latch and the only ay to reduce
contention for this latch is by
increasing the si,e of the shared pool
3(H8&%5:1OO*:(I>%49
Use *ocally +anaged tablespaces for
your application obJects especially
indexes
#on!guring the library cache to an
acceptable si,e usually ensures that
the data dictionary cache is also
properly si,ed9 (o tuning *ibrary
#ache ill tune &o #ache indirectly
&evie and amend your database
logical design " a good example is to
merge or decrease the number of
indexes on tables ith heavy inserts