Resolving common Oracle Wait Events using the Wait Interface

Wait Event Possible Causes Actions Remarks

db file sequential reads Use of an unselective index Check indexes on the table to ensure
that the right index is being used
The Oracle process wants a block that is currently not
Fragmented Indexes
in the SGA, and it is waiting for the database block to be
Check the column order of the index
read into the SGA from disk.
High I/O on a particular disk or mount point with the WHERE clause of the Top
SQL statements
Bad application design Significant db file sequential read wait time is most likely
Rebuild indexes with a high clustering an application issue.
Index reads performance can be affected by factor
slow I/O subsystem and/or poor database If the
files layout, which result in a higher average http://www.oracle.com/technetwork/issue- DBA_INDEXES.CLUSTERING_FACTOR of the index
wait time archive/2012/12-sep/o52asktom-1735913.html approaches the number of blocks in the table, then
Use partitioning to reduce the amount most of the rows in the table are ordered. This is
of blocks being visited desirable.

Make sure optimizer statistics are up However, if the clustering factor approaches the
to date number of rows in the table, it means the rows in the
table are randomly ordered and thus it requires more
Relocate ‘hot’ datafiles I/Os to complete the operation. You can improve the
index’s clustering factor by rebuilding the table so that
Consider the usage of multiple buffer rows are ordered according to the index key and
pools and cache frequently used rebuilding the index thereafter.
indexes/tables in the KEEP pool
The OPTIMIZER_INDEX_COST_ADJ and
Inspect the execution plans of the OPTIMIZER_INDEX_CACHING initialization parameters
SQL statements that access data can influence the optimizer to favour the nested loops
through indexes operation and choose an index access path over a full
table scan.
Is it appropriate for the SQL
statements to access data through
Tuning I/O related waits Note# 223117.1
index lookups?

Is the application an online transaction db file sequential read Reference Note# 34559.1
processing (OLTP) or decision
support system (DSS)?
 http://www.oracle.com/technetwork/issue-
Would full table scans be more archive/2012/12-sep/o52asktom-1735913.html
efficient?

Do the statements use the right driving

table?

The optimization goal is to minimize

both the number of logical and
physical I/Os.

db file scattered reads Optimize multi-block I/O by setting the If an application that has been running fine for a while
parameter DB_FILE_MULTIBLOCK_READ_COUNT suddenly clocks a lot of time on the db file scattered
The Oracle session has requested and is
read event and there hasn’t been a code change, you
waiting for multiple contiguous database
Partition pruning to reduce number of might want to check to see if one or more indexes has
blocks (up to DB_FILE_MULTIBLOCK_READ_COUNT) to be
blocks visited been dropped or become unusable.
read into the SGA from disk.
Consider the usage of multiple buffer
Full Table scans pools and cache frequently used db file scattered read Reference Note# 34558.1
indexes/tables in the KEEP pool
Fast Full Index Scans
Optimize the SQL statement that
initiated most of the waits. The goal is
to minimize the number of physical
and logical reads.

Should the statement access the data

by a full table scan or index FFS?
Would an index range or unique scan
be more efficient?
Does the query use the right driving
table?
Are the SQL predicates appropriate
for hash or merge join?
If full scans are appropriate, can
parallel query improve the response
time?
The objective is to reduce the
demands for both the logical and
 physical I/Os, and this is best
achieved through SQL and application tuning.

Make sure all statistics are

representative of the actual data.
Check the LAST_ANALYZED date

log file parallel write LGWR waits while writing contents of the Reduce the amount of redo being Reference Note# 34583.1
redo log buffer cache to the online log files generated
on disk
Do not leave tablespaces in hot Ensure tablespaces are
backup mode for longer than
I/O wait on sub system holding the online
necessary
NOT left in HOT BACKUP
redo log files
mode longer than needed.
Do not use RAID 5 for redo log files
Tablespaces in HOT
Use faster disks for redo log files BACKUP mode cause more
Ensure that the disks holding the
redo to be generated for
archived redo log files and the online each change which can
redo log files are separate so as to
avoid contention
vastly increase the rate of
redo generarion.
Consider using NOLOGGING or Redo log members should
UNRECOVERABLE options in SQL
statements ideally be on high speed
disks
eg: RAID5 is not a good
candidate for redo log
members.
Redo log members should
be on disks with little/no IO
activity from other sources.
(including low activity from
 other sources against the
same disk controller)
NOLOGGING /
UNRECOVERABLE
operations may be possible
for certain operations to
reduce the overall rate of
redo generation

log file sync Oracle foreground processes are waiting Tune LGWR to get good throughput to Reference Note# 34592.1
for a COMMIT or ROLLBACK to complete disk eg: Do not put redo logs on
RAID5
High Waits on log file sync Note# 125269.1
Reduce overall number of commits by
batching transactions so that there
are fewer distinct COMMIT operations
You are experiencing
performance problems. Your
applications have lots of
COMMITs and ROLLBACKs.

Solution:
=========

1. Ensure that your redo log

buffer in the SGA is large
enough.

2. Over time (since database

startup), if you see
increasing values for:

select * from v$sysstat

where name like 'redo%space%';
 your redo log buffer is too
small.

"Redo log space requests"

event is the number of times
that the
background was requested to
allocate space in the redo
file.

This gives an indication of

how many times a user process
waited for
space in the redo logs.

3. Increase the redo log

buffer by increasing the
init.ora "log_buffer"
parameter.

4. Then bounce your instance.

Explanation:
============

The "log file sync" event is

often thought to be a disk-
only issue which is
not always true. This event
can be more than disk I/O
problems. If the redo
log buffer cannot be
flushed/allocated fast enough,
you experience memory
 contention rather than disk
contention.

Tuning the Redolog Buffer Cache and Resolving Redo

Latch Contention
Note# 147471.1

buffer busy waits Buffer busy waits are common in an I/O- The main way to reduce buffer busy A process that waits on the buffer busy waits event
bound Oracle system. waits is to reduce the total I/O on the publishes the reason code in the P3 parameter of the
system wait event.
The two main cases where this can occur
Depending on the block type, the The Oracle Metalink note # 34405.1 provides a table
are:
actions will differ of reference - codes 130 and 220 are the most common.
Another session is reading the block into the Data Blocks Resolving intense and random buffer busy wait
buffer
performance problems. Note# 155971.1
Eliminate HOT blocks from the
Another session holds the buffer in an application.
incompatible mode to our request
Check for repeatedly scanned /
unselective indexes.
These waits indicate read/read, read/write,
or write/write contention. Try rebuilding the object with a higher
PCTFREE so that you reduce the
The Oracle session is waiting to pin a buffer. number of rows per block.
A buffer must be pinned before it can be
read or modified. Only one process can pin a Check for 'right- hand-indexes'
buffer at any one time. (indexes that get inserted into at the
same point by many processes).
This wait can be intensified by a large block
size as more rows can be contained within Increase INITRANS and MAXTRANS
the block and reduce PCTUSED This will make
the table less dense .
This wait happens when a session wants to
access a database block in the buffer cache Reduce the number of rows per block
but it cannot as the buffer is "busy
Segment Header
It is also often due to several processes
repeatedly reading the same blocks (eg: if Increase of number of FREELISTs
and FREELIST GROUPs
 lots of people scan the same index or data
block) Undo Header

Increase the number of Rollback

Segments

free buffer waits This means we are waiting for a free buffer Reduce checkpoint frequency - Understanding and Tuning Buffer Cache and
but there are none available in the cache increase the size of the online redo
DBWR Note# 62172.1
because there are too many dirty buffers in log files
the cache
Examine the size of the buffer cache How to Identify a Hot Block within the
Either the buffer cache is too small or the – consider increasing the size of the database Buffer Cache.
DBWR is slow in writing modified buffers to buffer cache in the SGA Note# 163424.1
disk
Set disk_asynch_io = true set
DBWR is unable to keep up to the write
requests If not using asynchronous I/O

Checkpoints happening too fast – maybe due increase the number of db writer
to high database activity and under-sized
online redo log files processes or dbwr slaves

Large sorts and full table scans are filling the Ensure hot spots do not exist by
cache with modified blocks faster than the spreading datafiles over disks and
DBWR is able to write to disk disk controllers

If the number of dirty buffers that need to be Pre-sorting or reorganizing data can
written to disk is larger than the number that help
DBWR can write per batch, then these waits
can be observed

enqueue waits This wait event indicates a wait for a lock Reduce waits and wait times Maximum number of enqueue resources that can be
that is held by another session (or sessions) concurrently locked is controlled by the
in an incompatible mode to the requested The action to take depends on the lock ENQUEUE_RESOURCES parameter.
mode. type which is causing the most problems
Reference Note# 34566.1
TX Transaction Lock Whenever you see an enqueue wait
 event for the TX enqueue, the first Tracing sessions waiting on an enqueue Note#
Generally due to table or application set up step is to find out who the blocker is 102925.1
issues and if there are multiple waiters for
the same resource Details of V$LOCK view and lock modes
This indicates contention for row-level lock.
Note:29787.1
This wait occurs when a transaction tries to Waits for TM enqueue in Mode 3 are primarily due to
update or delete rows that are currently unindexed foreign key columns.
locked by another transaction.
Create indexes on foreign keys < 10g
This usually is an application issue.
Following are some of the things you
TM DML enqueue lock can do to minimize ST lock contention
in your database:
Generally due to application issues,
Use locally managed tablespaces
particularly if foreign key constraints have
Recreate all temporary tablespaces
not been indexed. using the CREATE TEMPORARY
TABLESPACE TEMPFILE… command.
ST lock

Database actions that modify the UET$ (used

extent) and FET$ (free extent) tables require

the ST lock, which includes actions such as

drop, truncate, and coalesce.

Contention for the ST lock indicates there are

multiple sessions actively performing

dynamic disk space allocation or deallocation

in dictionary managed tablespaces

Cache buffer chain latch This latch is acquired when searching The default number of hash latches is usually 1024
for data blocks
Reducing contention for the cache
Buffer cache is a chain of blocks and The number of hash latches can be adjusted by the
buffer chains latch will usually require
each chain is protected by a child parameter _DB_BLOCKS_HASH_LATCHES
reducing logical I/O rates by tuning
latch when it needs to be scanned
and minimizing the I/O requirements of
the SQL involved. High I/O rates could What are latches and what causes
Hot blocks are another common be a sign of a hot block (meaning a latch contention
cause of cache buffers chains latch block highly accessed).
contention. This happens when
multiple sessions repeatedly access
Exporting the table, increasing the
one or more blocks that are
PCTFREE significantly, and importing
protected by the same child cache
the data. This minimizes the number of
buffers chains latch.
rows per block, spreading them over
many blocks. Of course, this is at the
SQL statements with high expense of storage and full table
BUFFER_GETS (logical reads) per scans operations will be slower
EXECUTIONS are the main culprits

Multiple concurrent sessions are Minimizing the number of records per

executing the same inefficient SQL block in the table
that is going after the same data set

For indexes, you can rebuild them

with higher PCTFREE values, bearing
in mind that this may increase the
height of the index.

Consider reducing the block size

Starting in Oracle9i Database, Oracle

supports multiple block sizes. If the
current block size is 16K, you may
move the table or recreate the index in
a tablespace with an 8K block size.
This too will negatively impact full
table scans operations. Also, various
block sizes increase management
 complexity.

Cache buffer LRU chain latch Processes need to get this latch when they Contention in this latch can be
need to move buffers based on the LRU avoided implementing multiple
block replacement policy in the buffer cache buffer pools or increasing the
The cache buffer lru chain latch is acquired number of LRU latches with the
in order to introduce a new block into the parameter DB_BLOCK_LRU_LATCHES
buffer cache and when writing a buffer (The default value is generally
back to disk, specifically when trying to sufficient for most systems).
scan the LRU (least recently used) chain
containing all the dirty blocks in the buffer Its possible to reduce
cache. contention for the cache buffer
Competition for the cache buffers lru chain lru chain latch by increasing the
size of the buffer cache and
latch is symptomatic of intense buffer cache thereby reducing the rate at
which new blocks are
activity caused by inefficient SQL introduced into the buffer cache

statements. Statements that repeatedly scan

large unselective indexes or perform full

table scans are the prime culprits.

Heavy contention for this latch is generally

due to heavy buffer cache activity which

can be caused, for example, by:

Repeatedly scanning large unselective

indexes

Direct Path Reads These waits are associated with direct read operations which Default size of HASH_AREA_SIZE is twice that of
read data directly into the sessions PGA bypassing the SGA SORT_AREA_SIZE
The "direct path read" and "direct path write" wait events are Larger HASH_AREA_SIZE will influence optimizer to go
Ensure the OS asynchronous IO is configured correctly.
related to operations that are performed in PGA like sorting, for hash joins instead of nested loops
group by operation, hash join
Hidden parameter DB_FILE_DIRECT_IO_COUNT can
In DSS type systems, or during heavy batch periods, waits on impact the direct path read performance.It sets the
"direct path read" are quite normal Check for IO heavy sessions / SQL and see if the maximum I/O buffer size of direct read and write
amount of IO can be reduced. operations. Default is 1M in 9i
However, for an OLTP system these waits are significant
How to identify resource intensive SQL
These wait events can occur during sorting operations which is statements?
not surprising as direct path reads and writes usually occur in
connection with temporary tsegments Ensure no disks are IO bound.

SQL statements with functions that require sorts, such as ORDER

BY, GROUP BY, UNION, DISTINCT, and ROLLUP, write sort runs to
the temporary tablespace when the input size is larger than the Set your PGA_AGGREGATE_TARGET to appropriate
work area in the PGA value (if the parameter WORKAREA_SIZE_POLICY =
AUTO)

Or set *_area_size manually (like sort_area_size and

then you have to set WORKAREA_SIZE_POLICY =
MANUAL

Whenever possible use UNION ALL instead of UNION,

and where applicable use HASH JOIN instead of SORT
MERGE and NESTED LOOPS instead of HASH JOIN.

Make sure the optimizer selects the right driving table.

Check to see if the composite index’s columns can be
rearranged to match the ORDER BY clause to avoid sort
entirely.

Also, consider automating the SQL work areas using

 PGA_AGGREGATE_TARGET in Oracle9i Database.

Query V$SESSTAT> to identify sessions with high

"physical reads direct"

Direct Path Writes These are waits that are associated with
direct write operations that write data from
If the file indicates a temporary
users’ PGAs to data files or temporary
tablespace check for unexpected disk
tablespaces
sort operations.

Direct load operations (eg: Create Table as

Select (CTAS) may use this)
Ensure
<Parameter:DISK_ASYNCH_IO> is
TRUE . This is unlikely to reduce wait
times from the wait event timings but
Parallel DML operations may reduce sessions elapsed times
(as synchronous direct IO is not
accounted for in wait event timings).

Sort IO (when a sort does not fit in memory

Ensure the OS asynchronous IO is

configured correctly.

Ensure no disks are IO bound

Latch Free Waits

A latch is a kind of low level lock.
This wait indicates that the process is If the TIME spent waiting for latches is
waiting for a latch that is currently busy significant then it is best to determine
 Latches apply only to memory
structures in the SGA. They do not
(held by another process). which latches are suffering from
apply to database objects. An Oracle
contention.
SGA has many latches, and they
exist to protect various memory
structures from potential corruption
When you see a latch free wait event in the by concurrent access.
V$SESSION_WAIT view, it means the
process failed to obtain the latch in the The time spent on latch waits is an
willing-to-wait mode after spinning effect, not a cause; the cause is that
_SPIN_COUNT times and went to sleep. you are doing too many block gets,
When processes compete heavily for and block gets require
latches, they will also consume more CPU cache buffer chain latching
resources because of spinning. The result is
a higher response time What are Latches and what causes
Latch contention

Database Lock and Latch Information

Knowledge Browser Product Page

Library cache latch The library cache latches protect the Latch is to ensure that the application Larger shared pools tend to have
cached SQL statements and objects is reusing as much as possible SQL long free lists and processes that
definitions held in the library cache within the statement representation. Use bind need to allocate space in them must
shared pool. The library cache latch must be variables whenever possible in the spend extra time scanning the long
acquired in order to add a new statement to application free lists while holding the shared
the library cache pool latch
You can reduce the library cache
Application is making heavy use of literal latch hold time by properly setting the if your database is not yet on
SQL- use of bind variables will reduce this SESSION_CACHED_CURSORS parameter Oracle9i Database, an oversized
latch considerably shared pool can increase the
Consider increasing shared pool contention for the shared pool latch.

Shared pool latch The shared pool latch is used to protect Ways to reduce the shared pool latch <Note 62143.1> explains how to
critical operations when allocating and are, avoid hard parses when identify and correct problems with the
freeing memory in the shared pool possible, parse once, execute many. shared pool, and shared pool latch.

Contentions for the shared pool and library Eliminating literal SQL is also useful to
cache latches are mainly due to intense hard avoid the shared pool latch. The size
parsing. A hard parse applies to new of the shared_pool and use of MTS
 cursors and cursors that are aged out and (shared server option) also greatly
must be re-executed influences the shared pool latch.

The cost of parsing a new SQL statement is

expensive both in terms of
The workaround is to set the
CPU requirements and the number of times
initialization parameter
the library cache and shared pool latches
CURSOR_SHARING to FORCE. This
may need to be acquired and released.
allows statements that differ in literal
values but are otherwise identical to
share a cursor and therefore reduce
latch contention, memory usage, and
hard parse.

Row cache objects latch This latch comes into play when user It is not common to have contention in Configuring the library cache to an
processes are attempting to access the this latch and the only way to reduce acceptable size usually ensures that
cached data dictionary values. contention for this latch is by the data dictionary cache is also
increasing the size of the shared pool properly sized. So tuning Library
(SHARED_POOL_SIZE). Cache will tune Row Cache indirectly

Use Locally Managed tablespaces for

your application objects especially
indexes

Review and amend your database

logical design , a good example is to
merge or decrease the number of
indexes on tables with heavy inserts