You are on page 1of 3

Oracle Wait Events

When Oracle executes an SQL statement, it is not constantly executing. Sometimes it has to wait for
a specific event to happen befor it can precede.

For example, if Oracle (or the SQL statement) wants to modify data, and the corresponding database
block is not currently in the SGA, Oracle waits for this block to be available for modification. All
possible wait events can be found in v$event_name.

In Oracle 10g R1, there are some 806 different wait events.
What Oracle waits for and how long it has totally waited for these events can be monitored through
the following views:

v$session_event
v$session_wait
v$system_event

The V$SESSION_WAIT view displays the events for which sessions have just completed waiting or
are currently waiting.

The V$SYSTEM_EVENT displays the total number of times all the sessions have waited for the
events in that view.

The V$SESSION_EVENT is similar to V$SYSTEM_EVENT, but displays all waits for each
session. For more information on these views, see "V$SESSION_EVENT", "V$SESSION_WAIT",
and "V$SYSTEM_EVENT".

Many of these wait events are tied to the internal implementation of Oracle and therefore are subject
to change or deletion without notice. This may even happen during a bug fix patch release.
Application developers should be aware of this and write their code to tolerate missing or extra wait
events.

This appendix describes the event name, wait time, and parameters for each event.

Important events:

buffer busy waits


db file scattered read
db file sequential read
free buffer waits
latch free
log buffer space
log file sync
enqueue
SQL*Net more data from client
SQL*Net more data to client
write complete waits
response_time_breakdown.sql :

This script can be used to focus tuning attention on the most important issues.
It reports a breakdown of total foreground response time into four major categories: CPU usage, disk
I/O, resource waits, and routine latencies. These categories are broken down further into sub-
categories, and the component wait events are shown.

session_times.sql

When a user reports an episode of poor performance, this script can be used to determine whether
their session has been working (say on an inefficient query) or waiting for resources, and if so, which
resources they have been waiting for. Idle waits are not excluded. To select a session before running
this script,please see the first three scripts on the Session Scripts page.

resource_waiters.sql

If there has been extensive waiting for a particular type of resource, then this script can be used to
determine which extant sessions have contributed to or been affected by the problem.

trace_waits.sql

This script is one of our favorites. It finds the top N sessions that have been affected by a particular
type of resource wait, and enables event 10046, level 8 in those sessions for the specified period.
This event captures every wait event and its wait parameters, and writes the information to the
process trace file together with the normal sql_trace output.The wait parameters can then be
analyzed to understand exactly what is causing the performance problem.

waiters.sql

During short-term performance problems, a standard diagnostic procedure is to count the number of
session in V$SESSION_WAIT that are waiting (or have recently waited)for each non-idle type of
wait event. However, it is difficult to query this view quickly enough to profile most such
problems.This script addresses this difficulty by selecting the information 10 times in very quick
succession within a single query.It still misses a lot, but is quick enough to identify some interesting
patterns. View sample listing.

resource_waits.sql

Resource waits can often be (nearly) eliminated by database server level tuning.
This script shows the major resource types waited for over the life of the instance, in order of
severity.It can be used to focus reactive tuning. The average waiting time shown is the average
waiting time for each logical wait. A logical wait may be composed of multiple distinct waits, all but
the last of which timed out.
routine_waits.sql

The average waiting time for routine waits, such as I/O waits, can also be improved by database
server level or operating system level tuning. This script reports the average waiting time for these
routine waits.

system_times.sql

This script reports the total waiting time for both routine and resource waits,
together with the CPU time used. The relative contribution of each type of wait to overall response
times, and the potential benefit of tuning actions, can be estimated from this information.
View sample listing.

You might also like