resolving-common-oracle-wait-events-using-the-wait-interface.doc

7/29/2019 resolving-common-oracle-wait-events-using-the-wait-interface.doc

1/12

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 byslow I/O subsystem and/or poor database

files layout, which result in a higher averagewait time

Check indexes on the table to ensurethat the right index is being used

Check the column order of the indexwith the WHERE clause of the TopSQL statements

Rebuild indexes with a high clusteringfactor

Use partitioning to reduce the amountof blocks being visited

Make sure optimizer statistics are upto date

Relocate hot datafiles

Consider the usage of multiple bufferpools and cache frequently usedindexes/tables in the KEEP pool

Inspect the execution plans of theSQL statements that access datathrough indexes

Is it appropriate for the SQLstatements to access data throughindex lookups?

Is the application an online transaction

processing (OLTP) or decisionsupport system (DSS)?Would full table scans be moreefficient?

Do the statements use the right driving

The Oracle process wants a block that iscurrently not in the SGA, and it is waiting forthe database block to be read into the SGAfrom disk.

Significant db file sequential read wait time ismost likely an application issue.

If theDBA_INDEXES.CLUSTERING_FACTOR of theindex approaches the number of blocks inthe table, then most of the rows in the tableare ordered. This is desirable.

However, if the clustering factor approachesthe number of rows in the table, it means therows in the table are randomly ordered andthus it requires more I/Os to complete theoperation. You can improve the indexsclustering factor by rebuilding the table sothat rows are ordered according to the indexkey and rebuilding the index thereafter.

The OPTIMIZER_INDEX_COST_ADJ andOPTIMIZER_INDEX_CACHING initializationparameters can influence the optimizer tofavour the nested loops operation and choosean index access path over a full table scan.

Tuning I/O related waits Note#223117.1

db file sequential read Reference Note#34559.1
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=223117.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=223117.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=34559.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=223117.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=34559.1


2/12

table?

The optimization goal is to minimizeboth the number of logical andphysical I/Os.

db file scattered reads

The Oracle session has requested and iswaiting for multiple contiguous databaseblocks (up to DB_FILE_MULTIBLOCK_READ_COUNT)to beread into the SGA from disk.

Full Table scans

Fast Full Index Scans

Optimize multi-block I/O by setting theparameterDB_FILE_MULTIBLOCK_READ_COUNT

Partition pruning to reduce number ofblocks visited

Consider the usage of multiple bufferpools and cache frequently usedindexes/tables in the KEEP pool

Optimize the SQL statement thatinitiated most of the waits. The goal isto minimize the number of physicaland logical reads.

Should the statement access the databy a full table scan or index FFS?Would an index range or unique scanbe more efficient?Does the query use the right drivingtable?Are the SQL predicates appropriatefor hash or merge join?If full scans are appropriate, canparallel query improve the responsetime?

The objective is to reduce thedemands for both the logical and

physical I/Os, and this is bestachieved through SQL and applicationtuning.

Make sure all statistics arerepresentative of the actual data.

If an application that has been running finefor a while suddenly clocks a lot of time onthe db file scattered read event and therehasnt been a code change, you might wantto check to see if one or more indexes hasbeen dropped or become unusable.

db file scattered read Reference Note#34558.1
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=34558.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=34558.1


3/12

Check the LAST_ANALYZED date

log file parallel write LGWR waits while writing contents of theredo log buffer cache to the online log fileson disk

I/O wait on sub system holding the onlineredo log files

Reduce the amount of redo beinggenerated

Do not leave tablespaces in hotbackup mode for longer thannecessary

Do not use RAID 5 for redo log files

Use faster disks for redo log files

Ensure that the disks holding thearchived redo log files and the onlineredo log files are separate so as toavoid contention

Consider using NOLOGGING orUNRECOVERABLE options in SQLstatements

Reference Note#34583.1

log file sync Oracle foreground processes are waitingfor a COMMIT or ROLLBACK to complete

Tune LGWR to get good throughput todisk eg: Do not put redo logs onRAID5

Reduce overall number of commits bybatching transactions so that thereare fewer distinct COMMIT operations


High Waits on log file sync Note# 125269.1

Tuning the Redolog Buffer Cache andResolving Redo Latch ContentionNote#147471.1

buffer busy waits Buffer busy waits are common in an I/O-bound Oracle system.

The two main cases where this can occurare:

The main way to reduce buffer busywaits is to reduce the total I/O on thesystem

Depending on the block type, theactions will differ

A process that waits on the buffer busy waitsevent publishes the reason code in the P3parameter of the wait event.

The Oracle Metalink note #34405.1providesa table of reference - codes 130 and 220 arethe most common.
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=34583.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=34583.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=34592.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=34592.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=125269.1http://metalink.oracle.com/metalink/plsql/showdoc?db=Not&id=147471.1http://metalink.oracle.com/metalink/plsql/showdoc?db=Not&id=147471.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=34405.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=34405.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=34405.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=34583.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=34592.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=125269.1http://metalink.oracle.com/metalink/plsql/showdoc?db=Not&id=147471.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=34405.1


4/12

Another session is reading the block into thebuffer

Another session holds the buffer in anincompatible mode to our request

These waits indicate read/read, read/write,or write/write contention.

The Oracle session is waiting to pin a buffer.A buffer must be pinned before it can beread or modified. Only one process can pin abuffer at any one time.

This wait can be intensified by a large blocksize as more rows can be contained within

the block

This wait happens when a session wants toaccess a database block in the buffer cachebut it cannot as the buffer is "busy

It is also often due to several processesrepeatedly reading the same blocks (eg: iflots of people scan the same index or datablock)

Data Blocks

Eliminate HOT blocks from theapplication.

Check for repeatedly scanned /unselective indexes.

Try rebuilding the object with a higherPCTFREE so that you reduce thenumber of rows per block.

Check for 'right- hand-indexes'(indexes that get inserted into at thesame point by many processes).

Increase INITRANS and MAXTRANSand reduce PCTUSED This will makethe table less dense .

Reduce the number of rows per block

Segment Header

Increase of number of FREELISTsand FREELIST GROUPs

Undo Header

Increase the number of RollbackSegments

Resolving intense and random buffer busywait performance problems. Note# 155971.1

free buffer waits This means we are waiting for a free bufferbut there are none available in the cachebecause there are too many dirty buffers inthe cache

Either the buffer cache is too small or theDBWR is slow in writing modified buffers todisk

DBWR is unable to keep up to the write

Reduce checkpoint frequency -increase the size of the online redolog files

Examine the size of the buffer cache consider increasing the size of thebuffer cache in the SGA

Set disk_asynch_io = true set

Understanding and Tuning Buffer Cache andDBWR Note# 62172.1

How to Identify a Hot Block within the

database Buffer Cache.Note#163424.1
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=155971.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=62172.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=62172.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=62172.1http://var/www/apps/conversion/tmp/scratch_2/Documents%20and%20Settings/bb17120/Local%20Settings/Temp/notes9248D0/ml2_documents.showDocument?p_database_id=NOT&p_id=163424.1http://var/www/apps/conversion/tmp/scratch_2/Documents%20and%20Settings/bb17120/Local%20Settings/Temp/notes9248D0/ml2_documents.showDocument?p_database_id=NOT&p_id=163424.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=163424.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=163424.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=155971.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=62172.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=62172.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=62172.1http://var/www/apps/conversion/tmp/scratch_2/Documents%20and%20Settings/bb17120/Local%20Settings/Temp/notes9248D0/ml2_documents.showDocument?p_database_id=NOT&p_id=163424.1http://var/www/apps/conversion/tmp/scratch_2/Documents%20and%20Settings/bb17120/Local%20Settings/Temp/notes9248D0/ml2_documents.showDocument?p_database_id=NOT&p_id=163424.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=163424.1


5/12

requests

Checkpoints happening too fast maybe dueto high database activity and under-sizedonline redo log files

Large sorts and full table scans are filling thecache with modified blocks faster than theDBWR is able to write to disk

If the number of dirty buffers that need to bewritten to disk is larger than the number that

DBWR can write per batch, then these waitscan be observed

If not using asynchronous I/O

increase the number of db writer

processes or dbwr slaves

Ensure hot spots do not exist byspreading datafiles over disks anddisk controllers

Pre-sorting or reorganizing data canhelp

enqueue waits This wait event indicates a wait for a lockthat is held by another session (or sessions)in an incompatible mode to the requested

mode.

TX Transaction Lock

Generally due to table or application set upissues

This indicates contention for row-level lock.This wait occurs when a transaction tries to

update or delete rows that are currentlylocked by another transaction.

This usually is an application issue.

TM DML enqueue lock

Generally due to application issues,

particularly if foreign key constraints have

not been indexed.

Reduce waits and wait times

The action to take depends on the lock

type which is causing the most problems

Whenever you see an enqueue waitevent for the TX enqueue, the firststep is to find out who the blocker isand if there are multiple waiters forthe same resource

Waits for TM enqueue in Mode 3 areprimarily due to unindexed foreign keycolumns.

Create indexes on foreign keys < 10g

Following are some of the things youcan do to minimize ST lock contention

in your database:

Use locally managed tablespaces

Recreate all temporary tablespacesusing the CREATE TEMPORARY

Maximum number of enqueue resources thatcan be concurrently locked is controlled bythe ENQUEUE_RESOURCES parameter.


Tracing sessions waiting on an enqueueNote#102925.1

Details of V$LOCK view and lock modesNote:29787.1
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=34566.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=34566.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=102925.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=102925.1http://metalink.oracle.com/metalink/plsql/showdoc?db=Not&id=29787.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=34566.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=102925.1http://metalink.oracle.com/metalink/plsql/showdoc?db=Not&id=29787.1


6/12

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

TABLESPACE TEMPFILE command.

Cache buffer chain latch This latch is acquired when searching

for data blocksBuffer cache is a chain of blocks andeach chain is protected by a childlatch when it needs to be scanned

Hot blocks are another commoncause ofcache buffers chains latchcontention. This happens whenmultiple sessions repeatedly accessone or more blocks that are

protected by the same child cachebuffers chains latch.

SQL statements with highBUFFER_GETS (logical reads) per

EXECUTIONS are the main culprits

Multiple concurrent sessions areexecuting the same inefficient SQLthat is going after the same data set

Reducing contention for the cachebuffer chains latch will usually requirereducing logical I/O rates by tuningand minimizing the I/O requirements ofthe SQL involved. High I/O rates couldbe a sign of a hot block (meaning ablock highly accessed).

Exporting the table, increasing thePCTFREE significantly, and importingthe data. This minimizes the number ofrows per block, spreading them overmany blocks. Of course, this is at theexpense of storage and full tablescans operations will be slower

Minimizing the number of records perblock in the table

The default number of hash latches is usually

1024

The number of hash latches can be adjustedby the parameter

_DB_BLOCKS_HASH_LATCHES

What are latches and what causeslatch contention
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=22908.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=22908.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=22908.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=22908.1


7/12

For indexes, you can rebuild themwith higher PCTFREE values, bearingin mind that this may increase theheight of the index.

Consider reducing the block size

Starting in Oracle9i Database, Oraclesupports multiple block sizes. If thecurrent block size is 16K, you maymove the table or recreate the index ina tablespace with an 8K block size.

This too will negatively impact fulltable scans operations. Also, variousblock sizes increase managementcomplexity.

Cache buffer LRU chain latch Processes need to get this latch when theyneed to move buffers based on the LRUblock replacement policy in the buffer cache

The cache buffer lru chain latch is acquiredin order to introduce a new block into thebuffer cache and when writing a bufferback to disk, specifically when trying toscan the LRU (least recently used) chaincontaining all the dirty blocks in the buffercache.Competition for the cache buffers lru chain

latch is symptomatic of intense buffer cache

activity caused by inefficient SQL

statements. Statements that repeatedly scan

large unselective indexes or perform full

table scans are the prime culprits.

Contention in this latch can beavoided implementing multiplebuffer pools or increasing thenumber of LRU latches with theparameter DB_BLOCK_LRU_LATCHES(The default value is generallysufficient for most systems).

Its possible to reducecontention for the cache bufferlru chain latch by increasing thesize of the buffer cache andthereby reducing the rate atwhich new blocks areintroduced into the buffer cache


8/12

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 readoperations which read data directly into thesessions PGA bypassing the SGA

The "direct path read" and "direct path write" waitevents are related to operations that are performedin PGA like sorting, group by operation, hash join

In DSS type systems, or during heavy batch periods,waits on "direct path read" are quite normal

However, for an OLTP system these waits aresignificant

These wait events can occur during sortingoperations which is not surprising as direct pathreads and writes usually occur in connection withtemporary tsegments

SQL statements with functions that require sorts,such as ORDER BY, GROUP BY, UNION, DISTINCT,and ROLLUP, write sort runs to the temporarytablespace when the input size is larger than thework area in the PGA

Ensure the OS asynchronous IO is configuredcorrectly.

Check for IO heavy sessions / SQL and see ifthe amount of IO can be reduced.

Ensure no disks are IO bound.

Set your PGA_AGGREGATE_TARGET toappropriate value (if the parameterWORKAREA_SIZE_POLICY = AUTO)

Or set *_area_size manually (likesort_area_size and then you have to setWORKAREA_SIZE_POLICY = MANUAL

Default size of HASH_AREA_SIZE is twice thatof SORT_AREA_SIZE

Larger HASH_AREA_SIZE will influenceoptimizer to go for hash joins instead ofnested loops

Hidden parameterDB_FILE_DIRECT_IO_COUNT can impact thedirect path read performance.It sets the

maximum I/O buffer size of direct read andwrite operations. Default is 1M in 9i

How to identify resource intensive SQLstatements?
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=232443.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=232443.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=232443.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=232443.1


9/12

Whenever possible use UNION ALL instead ofUNION, and where applicable use HASH JOINinstead of SORT MERGE and NESTED LOOPSinstead of HASH JOIN.

Make sure the optimizer selects the rightdriving table. Check to see if the compositeindexs columns can be rearranged to matchthe ORDER BY clause to avoid sort entirely.

Also, consider automating the SQL workareas using PGA_AGGREGATE_TARGET inOracle9i Database.

Query V$SESSTAT> to identify sessions withhigh "physical reads direct"

Direct Path Writes These are waits that are associated withdirect write operations that write data from

users PGAs to data files or temporarytablespaces

Direct load operations (eg: Create Table asSelect (CTAS) may use this)

Parallel DML operations

Sort IO (when a sort does not fit in memory

If the file indicates a temporarytablespace check for unexpected disksort operations.

Ensure is

TRUE . This is unlikely to reduce waittimes from the wait event timings butmay reduce sessions elapsed times(as synchronous direct IO is notaccounted for in wait event timings).

Ensure the OS asynchronous IO isconfigured correctly.


10/12

Ensure no disks are IO bound

Latch Free Waits

This wait indicates that the process iswaiting for a latch that is currently busy(held by another process).

When you see a latch free wait event in theV$SESSION_WAIT view, it means theprocess failed to obtain the latch in thewilling-to-wait mode after spinning

_SPIN_COUNT times and went to sleep.When processes compete heavily forlatches, they will also consume more CPUresources because of spinning. The result isa higher response time

If the TIME spent waiting for latches issignificant then it is best to determinewhich latches are suffering fromcontention.

A latch is a kind of low level lock.

Latches apply only to memorystructures in the SGA. They do notapply to database objects. An OracleSGA has many latches, and theyexist to protect various memorystructures from potential corruptionby concurrent access.

The time spent on latch waits is aneffect, not a cause; the cause is thatyou are doing too many block gets,and block gets requirecache buffer chain latching

What are Latches and what causesLatch contention

Database Lock and Latch InformationKnowledge Browser Product Page

Library cache latch The library cache latches protect thecached SQL statements and objects

definitions held in the library cache within theshared pool. The library cache latch must beacquired in order to add a new statement tothe library cache

Application is making heavy use of literal

Latch is to ensure that the applicationis reusing as much as possible SQL

statement representation. Use bindvariables whenever possible in theapplication

You can reduce the library cachelatch hold time by properly setting the

Larger shared pools tend to havelong free lists and processes that

need to allocate space in them mustspend extra time scanning the longfree lists while holding the shared

pool latch

if your database is not yet on
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=22908.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=22908.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=267887.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=267887.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=22908.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=22908.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=267887.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=267887.1


11/12

SQL- use of bind variables will reduce thislatch considerably

SESSION_CACHED_CURSORS parameter

Consider increasing shared pool

Oracle9i Database, an oversizedshared pool can increase thecontention for the shared pool latch.

Shared pool latch The shared pool latch is used to protectcritical operations when allocating andfreeing memory in the shared pool

Contentions for the shared pool and librarycache latches are mainly due to intense hardparsing. A hard parse applies to new

cursors and cursors that are aged out andmust be re-executed

The cost of parsing a new SQL statement isexpensive both in terms ofCPU requirements and the number of timesthe library cache and shared pool latchesmay need to be acquired and released.

Ways to reduce the shared pool latchare, avoid hard parses whenpossible, parse once, execute many.

Eliminating literal SQL is also useful toavoid the shared pool latch. The sizeof the shared_pool and use of MTS(shared server option) also greatlyinfluences the shared pool latch.

The workaround is to set theinitialization parameterCURSOR_SHARING to FORCE. Thisallows statements that differ in literal

values but are otherwise identical toshare a cursor and therefore reducelatch contention, memory usage, andhard parse.

explains how toidentify and correct problems with theshared pool, and shared pool latch.

Row cache objects latch This latch comes into play when userprocesses are attempting to access thecached data dictionary values.

It is not common to have contention inthis latch and the only way to reducecontention for this latch is byincreasing the size of the shared pool(SHARED_POOL_SIZE).

Use Locally Managed tablespaces foryour application objects especially

indexes

Review and amend your databaselogical design , a good example is tomerge or decrease the number ofindexes on tables with heavy inserts

Configuring the library cache to anacceptable size usually ensures thatthe data dictionary cache is alsoproperly sized. So tuning LibraryCache will tune Row Cache indirectly
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=62143.1http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=62143.1


12/12

resolving-common-oracle-wait-events-using-the-wait-interface.doc

Documents

Transcript of resolving-common-oracle-wait-events-using-the-wait-interface.doc