Oracle Performance Analysis Using Wait Events

Pat Crain
Craig Hanson
CableData, Inc.

The Oracle RDBMS offers a rich set of well-known usage statistics that provide visibility into database
performance. Lesser-known is the fact that Oracle provides direct visibility of wait events encountered by the
RDBMS kernel. Unfortunately, wait events are not as well understood or documented as other statistics. This
paper presents a method to diagnose performance problems based on wait event observation and
interpretation.

AUDIENCE
This paper is intended for database administrators,
application developers, and performance analysts
tasked with ensuring the performance of Oracle-
based applications and systems. Familiarity with
RDBMS concepts, performance analysis, and Oracle
terminology is assumed.
OBJECTIVES
This paper provides:
• An overview of Oracle wait event management;
• A description of database objects related to the
wait event interface;
• Practical methods to observe wait events;
• Interpretations of common wait events; and
• High-level tuning considerations to mitigate
excessive waiting.
BACKGROUND
The Oracle database server records the occurrence
of blocking procedures and associated wait times.
Blocking procedures are synchronous operations
that create a wait in user SQL processes or instance
processes. The execution of a blocking procedure
generates a “wait event”. Wait events are recorded
in database objects known as dynamic performance
views, or V$ (pronounced “vee dollar”) tables.
In addition to V$ tables, applications can record wait
event records in a trace file. This is sometimes called
“10046 trace” after the statement used to enable it:
query1:
SELECT *
FROM v$event_name;
The query returns the names and associated
parameters of all wait events. Version 7.3 includes
105 wait events. It is important to note the
ephemeral use of specific wait events across Oracle
releases and versions2. The caveat has been, and
continues to be: "wait events are tied to the internal
implementation of Oracle and therefore subject to
change or deletion without notice."3 This speaks to
the interface's roots as an internal diagnostic tool.
This also suggests that its reliability and accuracy
need careful scrutiny.
PERFORMANCE VIEWS
If you have ever tuned an Oracle database the V$
performance views are immediately familiar. The
performance views associated with wait event
management include:
• V$EVENT_NAME (Oracle7.3+)
• V$SESSION_EVENT
• V$SESSION_WAIT
• V$SYSTEM_EVENT
V$SYSTEM_EVENT provides a high-level system
view and is used by the performance scripts
utlbstat.sql and utlestat.sql (collectively referred to as
bestat). The view contains grouped statistics about
wait events recorded since instance startup. Use it
to acquire a system-level viewpoint.

exec sql ALTER SESSION SET EVENTS '10046 trace

name context forever, level 12';
Like any form of tracing, 10046 trace is resource
intensive; however, it provides a detailed session-
level view of resource contention which is invaluable
in many situations.
A complete list of the wait events for the version of
Oracle being used can be viewed with the following
1
This and all subsequent SQL queries and scripts are
intended for illustrative purposes only. Each query and
script has been tested and appears to work as intended.
2
This paper is based on work performed with Oracle
Release 7. The concepts and conclusions presented are
applicable to the latest Oracle version, Release 8.
3
[LANE97] Paul Lane, “Oracle8 Server Reference”,
Oracle Corporation, 1997

Table 1. V$SYSTEM_EVENT
Column Description
Event Name of the wait event.
Total_waits Total number of times this specific
event was logged since instance
startup.
Total_timeouts Total number of times the wait
resulted in a timeout. Not all wait
events use a timeout.
Time_waited Total time in centiseconds (.01s)
all sessions have waited for Event
since instance startup.
Average_wait Mean time in centiseconds (.01s)
all sessions have waited for Event
since instance startup.
V$SESSION_EVENT view is similar to
V$SYSTEM_EVENT with the addition of session
identifier (SID) as the high order key.
V$SESSION_WAIT provides a real-time view of
session-level waits. Oracle frequently updates the
view making observation difficult. Each query of the
view returns a snapshot that is immediately stale
because system state has changed. This view is
very useful but keep its transitory nature in mind.
Table 2. V$SESSION_WAIT
Column Description
SID Session identifier.
Seq# This is a sequence number that
functions as a counter. It
increments each time the session
identified by SID logs an occurrence
of the wait event identified by Event.
Event The event name. There are 105
events as of Oracle7.3.
P[1-3] Parameters describing Event or
pointing to details about Event.
P[1-3]Raw The raw value of Pn.
P[1-3]Text The name of Pn. A value is not
always present.
State Describes the event’s state as
being one of the following: “Waiting”
– currently waiting for this event;
“Waited unknown time” - the
initialization parameter
TIMED_STATISTICS is set to false;
“Waited short time” - session woke
up in the same clock tick it went
sleep (<.01 seconds); “Waited
known time” – session waited the
value of column Wait_time.
Wait_time If the value of the column State is
“waited known time” this value
represents actual wait time in .01s.
If State is anything other than
“waited known time” the value of
this column is unreliable.
Seconds_in If the value of the column State is
_wait “waiting” this value represents wall-
clock time recorded when the wait
began. If State is anything other
than “waiting” the value of this
column is unreliable.
OBSERVING WAIT EVENTS
Utlbstat and Utlestat
The simplest way to observe wait events is with
“canned” performance measurement scripts called
utlbstat.sql and utlestat.sql, collectively referred to as
bestat. The advantage of bestat is the ability to
measure intervals or “rate of change” without having
to create a custom SQL script. The disadvantage is
bestat’s system orientation, which prohibits session-
level analysis.
On Unix systems the scripts reside in
$ORACLE_HOME/rdbms/admin. Utlbstat begins a
measurement by creating temporary tables and
populating them with the begin values of metrics
from several V$ tables. Utlestat ends a
measurement by populating the temporary tables
with end values, calculating the delta, and writing
results to a file called report.txt located in
$ORACLE_HOME/rdbms/admin/.
Prior to running bestat, ensure the initialization
parameter TIMED_STATISTICS is set to TRUE.
This enables time-based data collection. When and
how long to measure depends on the workload type
and volume. Avoid spanning unlike workloads with a
single measurement. Both scripts can be run as the
SYS user from SQL*Plus4 or Server Manager. You
can also run the scripts from Server Manger (svrmgr)
after connecting as “internal”.
Among other information, bestat reports utilization
statistics about:
• Library cache
• System wide usage
• System wide wait events
• File I/O
• Tablespace I/O
• Latches
• Rollback segments
The wait event section reports the difference
between begin and end values of
V$SYSTEM_EVENT. Following is an example of
bestat’s wait event section5.
>Rem System wide wait events.
> select n1.event "Event Name",
> n1.event_count Count",
> n1.time_waited "Total Time",
> (n1.time_waited/n1.event_count)
4
SQL*Plus is a registered trademark of Oracle
Corporation.
5
Formatting was changed to fit the page.
> "Average Time" COLUMN program FORMAT A20 HEADING 'Prog'
> from stats$event n1 COLUNM username FORMAT A12 HEADING 'DBUsr'
> where n1.event_count > 0 COLUMN osuser FORMAT A10 HEADING 'OSUsr'
> order by n1.time_waited desc; SELECT s.sid,
p.spid,
Event Name Count Total Time Average s.process,
---------- ------ ---------- ------- p.program,
rdbms ipc m 4316 886325 205.357 p.username,
Null event 1785 537302 301.009 s.osuser
smon timer 6 180006 30001 FROM v$process p, v$session s
pmon timer 692 178991 258.657 WHERE p.addr = s.paddr;
pipe get 372 178056 478.645
db file seq 130240 113824 .873
latch free 63632 29334 .460
Using the SID value you have obtained, execute the
db file sca 32865 14795 .450 following to view wait events.
db file par 572 5006 8.751
log file syn 2593 4450 1.716 COLUMN sid FORMAT 999 HEADING 'Sid'
log file par 2769 4352 1.571 COLUMN event FORMAT a25 HEADING 'Event'
enqueue 10 997 99.7 COLUMN totwaits FORMAT 9999999 HEADING 'Count'
write comple 61 443 7.262 COLUMN timouts FORMAT 9999999 HEADING 'TimOuts'
control file 66 55 .833 COLUMN timwait FORMAT 9999999 HEADING 'TotTime'
buffer busy 26 49 1.884 COLUMN avgwait FORMAT 9999999 HEADING 'AvgTime'
db file sin 50 16 .32 SELECT sid,
row cache lock 1 1 1 event,
library cach 5 1 .2 total_waits totwaits,
control file 18 0 0 total_timeouts timouts,
client mess 910634 0 0 time_waited timwait,
average_wait avgwait
Bestat execution steps are outlined below: FROM v$session_event
WHERE sid = &sid;

1. Set the parameter TIMED_STATISTICS to

TRUE. The database instance must be stopped
and started for any parameter change to take
affect.
2. Run utlbstat.sql from svrmgrl:
> svrmgrl
SVRMGR> connect internal;
Connected
SVRMGR> @$ORACLE_HOME/rdbms/admin/utlbstat
3. Wait the desired measurement interval.
4. Run utlestat.sql from svrmgrl:
> svrmgrl
SVRMGR> connect internal;
Connected
SVRMGR> @$ORACLE_HOME/rdbms/admin/utlestat
Automating bestat execution is often desirable. In
Unix, use the cron utility to run utlbstat and utlestat
at specified times.
Using V$ Queries to Locate Wait Events
You can directly query V$ tables with SQL
statements from SQL*Plus or svrmgr. This is
particularly handy to take snapshots of
V$SESSION_EVENT using a known SID.
Remember that V$SESSION_EVENT is updated by
Oracle in real-time. You must take several samples
to develop a representative picture. Given a client or
server process id, use the following query to obtain
SID.
COLUMN sid FORMAT 9999999 HEADING 'SID'
COLUMN spid FORMAT 9999999 HEADING 'SvrPID'
COLUMN process FORMAT 9999999 HEADING 'CltPID'
Using Trace to Locate Wait Events
The Oracle trace facility profiles SQL statements
associated with a specific user SQL session
(process). Trace records contain execution statistics
by default and may include wait event records if
explicitly enabled.
The advantage of trace over other tools such as
bestat or V$ queries is two-fold. First, applications
can be instrumented to enable and disable trace on
the fly. This allows analysts to focus on specific
sessions and users. Second, trace combines wait
event statistics with execution statistics. This
facilitates quick isolation of problematic SQL
statements and contention for shared resources.
Three global Oracle initialization parameters affect
trace:
• TIMED_STATISTICS must be set to TRUE;
otherwise, time-based statistics are not
recorded. Gathering timed statistics introduces
overhead into SQL statement processing.
However, unless a system is CPU bound, timed
statistics should have a negligible impact to
performance.
• USER_DUMP_DEST specifies the location of
trace files. The default Unix path is
/home/oracle/admin/SID/udump. The name of
the trace file is platform specific. On Unix, the
naming convention is ora_PID.trc. PID is a
numeric identifier used by the operating system
to manage processes.
• MAX_DUMP_FILE_SIZE specifies the maximum
trace file size in operating system blocks.
Traces that include wait events capture a
 tremendous amount of data. Set the file size to
at least 100 megabytes.
One way to leverage trace is simply to include the
ability to enable trace in your application. Ideally, you
want the ability to enable trace in a running program
from a command line. For example, a Unix
application can include code to toggle trace on or off
upon receiving the signal SIGUSR1. In this way, a
DBA can easily control trace with the command:
kill -usr1 PID
Given a trace-enabled application a DBA could
research poor response time with the following
steps:
1. Identify the application's PID.
2. Signal the process to enable trace.
3. Have the user execute the problem transaction.
4. Signal the application to disable trace.
5. Analyze the trace output.
Applications written using Oracle pre-compilers such
as Pro*C6 use embedded SQL (ESQL) statements to
access the database engine. The following ESQL
statements enable and disable trace:
exec sql ALTER SESSION SET SQL_TRACE TRUE;
exec sql ALTER SESSION SET SQL_TRACE FALSE;
Wait events are not written to trace files by default.
To enable trace and include wait events, use the
following ESQL statement:
exec sql ALTER SESSION SET EVENTS '10046 trace
name context forever, level 12';
This is referred to as “10046” trace and is not
documented by Oracle. Harrison7 and Velpuri8
address event 10046 and other aspects of the trace
facility. Oracle support personnel routinely use event
trace capability and consider it safe.
Oracle Version 7.3 allows trace to be enabled in a
session from svrmgr. This is useful but it does not
enable the session to record wait events. To enable
trace for a session use this procedure:
DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION
The procedure requires that you obtain the values of
columns SID and SERIAL# from V$SESSION for the
PID or user in question. See Version 7.3
documentation for details on this procedure.
Oracle provides a utility called tkprof to format raw
trace files. Unfortunately the utility ignores wait
6
Pro*C is a registered trademark of Oracle Corporation
7
[HARR96] Guy Harrison, “Getting the most from the
SQL_TRACE Facility”, OTJ, Winter 1996
8 9
[RAMA95] Rama Velpuri, “Oracle Backup & Recovery
Handbook”, 1995
event records; therefore, you must extract and
format wait event records from trace files. Wait
records are recorded in the format:
WAIT #CURSOR: nam="EVENT" ela=n p1=n p2=n
p3=n
CURSOR = Cursor number
Nam = Wait event name
Ela = Elapsed wait time in centiseconds
p[1-3] = Event-specific parameters
For example, the following record indicates the
session waited less than .01 seconds for the event
“SQL*Net message from client” during the execution
of cursor number one. Parameter P1 is the “driver
ID”, which is not too useful. Parameter P2 is the
number of bytes received by the server from the
client.
WAIT #1: nam='SQL*Net message from client' ela=
0 p1=537277696 p2=1 p3=0
It is important to understand why elapsed wait time is
zero. There are two reasons for a zero value.
TIMED_STATISTICS may not be set to TRUE.
Alternatively, timed statistics may be enabled but the
actual wait time was less than .01 second. Time
granularity is limited to .01 second, commonly known
as a “tick”. This second case occurs quite
frequently, especially with “SQL*Net” wait events.
Be careful not to ignore zero value waits, as their
cumulative value can be significant. Ten thousand
zero value events, for example, represent close to
one hundred elapsed seconds.
INTERPRETING WAIT EVENTS
The following query executed against a Version 7.3
database shows 105 unique wait events.
SELECT COUNT(*)
FROM v$event_name;
COUNT(*)
----------
105
Samples taken from production systems, however,
reveal an average of twenty-five common events. Of
these twenty-five, we are concerned with only those
that represent significant session wait time.
Client message | SQL*Net9 message from
client
“Client message” is observed prior to Version 7.3. It
is superseded by “SQL*Net message” in Versions
7.3 and above. Both events occur when an Oracle
server (shadow) process awaits a message from its
client (foreground) process.
SQL*Net is a registered trademark of Oracle
Corporation
 p2 block
FROM v$session_wait
As of Version 7.3, interprocess communication (IPC) WHERE event like ‘db file%’;
between client and server processes occurs via
SQL*Net. SQL*Net is an application and session The following query resolves file# and block# to a
level communication interface which uses native database object name which is usually a table.
operating system IPC mechanisms and network
communication protocol stacks such as TCP/IP. The COLUMN owner FORMAT a15 HEADING “Owner"
use of SQL*Net does not necessarily imply the use COLUMN sname FORMAT a20 HEADING “TableName"
of networked communication. COLUMN stype FORMAT a10 HEADING “SegType"
COLUMN tbsn FORMAT a10 HEADING “TblSpcName”
COLUMN fname FORMAT a40 HEADING “FileName”
This event is a product of a client process' SELECT owner,
synchronous relationship with the server process. segment_name sname,
The wait can be viewed as server idle time -- segment_type stype,
e.tablespace_name tbsn,
implying client busy time, user think time or, to a far file_name fname
less extent, IPC latency. It is a common, from dba_extents e,
unavoidable event consistently observed as one of dba_data_files f
where e.file_id = f.file_id
the top three wait events during extensive sampling and e.file_id = &file_id
of Version 7.1.6 production databases and Version and e.block_id <= &block_id
7.3 development databases. and e.block_id + e.blocks > &block_id

Null event Use the following query to identify SQL sessions

accessing the table identified by “tablename”.
Presence of the Null event indicates that a user SELECT buffer_gets,
session performed an unspecified event resulting in sql_text
a wait. Oracle indicates this event should not be FROM v$sqlarea
WHERE sql_text like &tablename
used and a bug reported if observed. Several ORDER BY buffer_gets desc;
observations of a large 7.1.6 database revealed
multiple occurrences of this event with an average The following query identifies SQL statements
wait time of three seconds. This event has not been resulting in the largest number of physical reads:
observed in Version 7.3. The number of null event
occurrences was always very close to the usage SELECT disk_reads,
statistic “background timeout” count, suggesting that sql_text
it is not a user session wait. Report occurrence of FROM v$sqlarea
WHERE disk_reads > &threshold
this event to Oracle. ORDER BY disk_reads desc;

DB file [sequential | scattered] read
These wait events occur every time a user session
waits while reading database blocks. Sequential
reads are associated with indexed access and
scattered reads with scan (multi-block read)
operations. These waits are unavoidable, but do not
ignore them. Excessive wait time suggests I/O
contention.
Drill-down analysis involves two tasks. The first step
is to identify wait parameters P1 (file#) and P2
(block#) and resolve them to a specific database
table. The next step is to map the table to SQL
sessions accessing it.
Several techniques may be used to reduce “db file
wait”. First, identify and, if possible, optimize
offensive SQL statements. Use the output of tkprof
to identify resource intensive statements. The
queries listed at the end of this section identify SQL
statements resulting in high I/O. Next, physically
separate files. Aronoff et al.10 suggest separating
the following objects: tables from indexes; rollback
segments from tables; rollback segments from online
redo logs; online redo logs from archived redo log
files; temporary tablespaces from data tablespaces;
and SYSTEM tablespace from the rest of the
database. Other techniques to explore include the
use of operating system file striping (if available) and
11
table partitioning (an option with Oracle8 ).

If the wait is observed using trace, file# and block# Enqueue

are available. Bestat, however, is driven by
V$SYSTEM_EVENT which does not include P1 or An enqueue is a locking mechanism that permits
P2. Look for wait parameters by sampling many processes to concurrently share a resource.
V$SESSION_WAIT with the following query: Enqueue waits occur when a session waits to obtain
a lock. This usually occurs when a session attempts
COLUMN sid FORMAT 9999 HEADING ‘SID’
COLUMN event FORMAT a25 HEADING ‘Event’ to modify data that is locked.
COLUMN filenum FORMAT 99999999 HEADING ‘File#’
COLUMN block FORMAT 99999999 HEADING ‘Block#’ 10
SELECT sid, [ARNO97] Aronoff, Loney, and Sonawalla, “Advanced
event, Oracle tuning and Administration”, 1997
p1 filenum, 11
Oracle8 is a registered trademark of Oracle Corporation

One common enqueue is the data manipulation
language (DML) enqueue. The DML enqueue is
represented in the enqueue wait parameter P1 as
“TM”. A TM enqueue is acquired during the
execution of a transaction that references a table
with a DML statement. The enqueue protects the
object from being altered by another session. There
need to be enough enqueues to support multiple
DML statements executed against multiple objects
by multiple sessions. Oracle suggests
enqueue_resources should equal the product of
database objects and the number of concurrent DML
operations executed against the objects plus about
twenty for kernel overhead.
Memory consumed by enqueue resources is
negligible relative to the database instance as a
whole. If enqueue waits are observed, significantly
increase enqueue_resources parameter and
measure again.
If excessive enqueue waits persist, drill-down
analysis is required. Identify specific enqueue
names and locking modes and contact Oracle for
interpretation.
To determine enqueue name and mode, query
V$SESSION_WAIT. P1 contains name|mode.
Enqueue names are always two characters. The
following SQL statement returns names:
SELECT chr(bitand(p1, -16777216)/16777215)||
chr(bitand(p1,16711680)/65535) Enqueue
FROM v$session_wait
WHERE event = ‘enqueue’;
This statement returns mode:
SELECT bitand(p1, 65535)
FROM v$session_wait
WHERE event = ‘enqueue’;
Latch Free
Latches are analogous to semaphores. Latches
ensure certain operations are executed by a single
session. Requestors waiting for a latch concurrently
retry so any process may get the latch; the net effect
is random assignments. It is possible for the first
process attempting to acquire a latch to be the last to
acquire it.
Total latch free waits equals the total of all sleeps as
reported in the latch section of bestat. Waits
definitely indicate latch contention. Latches held too
long suggest the resources they protect are being
held too long, implying higher level contention.
Oracle suggests that latch contention may affect
performance if the ratio of MISSES to GETS
exceeds 1%.
The “redo allocation” latch controls the allocation of
space for entries in the redo log buffer. To allocate
space, a user process must obtain the latch. After
allocating space for a redo entry, the entry must be
copied into the redo log buffer. This is called “redo
copy”. This can only be done if the redo entry is less
than the size defined by
LOG_SMALL_ENTRY_MAX_SIZE. If the entry is
too large, the process must acquire another latch
called “redo copy latch”. Heavy redo log buffer
access can result in redo buffer latch contention,
possibly impacting overall performance.
“Library cache”, “library cache pin”, and “shared
pool” latches protect access to shared pool objects.
Shared pool latches allocate and release space in
the shared pool. Library cache and library cache pin
latches are used during SQL statement parsing and
execution. Oracle cites the practice of not using bind
variables as the primary reason for library cache
contention. Bind variables allow values to be bound
during statement execution rather than during
parsing. Statements can then be reused without the
need to re-parse.
Access to database block buffer cache is protected
by “cache buffer chain” and “cache buffer lru”
latches. A cache buffer chain latch is acquired when
sessions access a block in the buffer. Access
requires the session compute a hash value of the
block address to locate it. If the buffer is not found or
has been modified, it must read the buffer from disk
or create a read consistent clone. Doing so requires
it locate a free buffer using the LRU mechanism.
The cache buffer lru latch controls access to the
LRU buffer.
Buffer busy
This event occurs when a session cannot access a
block in buffer cache. A buffer is considered busy
when another session is reading it or the block is
being converted into a “cleaned up” state. The most
common causes of this wait are insufficient free lists
for a table or too few rollback segments.
This wait is commonly seen when jobs are migrated
from a single execution thread to multiple execution
threads. The following illustrates the increase in
buffer busy waits as more execution threads are
made available to an application architected for fan-
out parallelism:
Threads Waits Wait Seconds
1 1 .01
2 15,060 80.09
3 22,634 154.93
4 31,013 123.96
Drill down by querying V$WAITSTAT.
SELECT *
FROM V$WAITSTAT;
CLASS COUNT TIME
------------------ ---------- ----------
data block 46 173
sort block 0 0
save undo block 0 0
segment header 0 0
save undo header 0 0
free list 0 0
system undo header 0 0
system undo block 0 0
undo header 37 468
undo block 5 8
If the count for “data block” or “free list” is high,
consider adding “free lists” to tables subject to
concurrent insert operations. If “undo header” or
“undo block” counts are high, you may consider
adding rollback segments.
Log file sync
This is the unavoidable wait a session encounters at
transaction commit when redo log entries are flushed
from the redo log buffer in memory to redo log files
on disk.
The wait is the time it takes the LGWR process to
complete the I/O. LGWR writes to disc at user
commit and at a timed interval occurring about every
three seconds. The count for this event should
equal the value of “user commits” statistic plus
(measurement interval / 3). Average wait time
generally should not exceed .050 seconds. If higher
waits impact performance, investigate several
possible problem areas and consider employing an
appropriate tuning strategy.
Redo log files may exist on a slow device or a device
connected to a slow I/O subsystem. Move the redo
log files to a faster device or I/O subsystem.
Similarly, the device where redo log files reside may
be too busy. Reduce I/O activity by physically
separating frequently accessed files from the redo
log files. Ideally, redo log files should be placed on a
dedicated disk and I/O channel. Finally, refer to
Oracle’s tuning guidelines for optimum redo log
configuration.
Log file space/switch
This wait encountered by LGWR occurs when an
online redo log file is full but a log file switch cannot
be performed. The log switch is probably waiting for
archiving to complete. Another reason for the wait
could be that LGWR couldn’t wrap into the next log
file because the checkpoint for that log is incomplete.
Oracle documentation indicates a separate wait
event for the latter, called “log file switch (checkpoint
incomplete)”. This event was not observed during
research for this paper.
Several sample observations revealed average wait
time of log file space/switch ranging from .007
seconds to .050 seconds with a peak frequency of
one wait every 12 seconds. If this wait is frequent
and long, it may indicate online redo logs are too
small or too few. Oracle documentation suggests
increasing the value of LOG_BUFFER. This is the
number of bytes allocated to the redo log buffer in
the SGA. In general, larger values reduce I/O
frequency to on-line redo log files. I/O is reduced
because LGWR writes when the buffer is 1/3 full –
bigger buffer means less frequent writes.
Log file parallel write
This event is analogous to “log file sync” but instead
of a session wait, it is encountered by LGWR. The
number of waits should equal the value of the
statistic “redo writes” as reported by bestat.
Generally the wait count and total wait time will be
very close to “log file sync”. See section “Log file
sync”, for drill down considerations.
Free buffer waits
This event appears to be rare. It represents “inward”
pressure on the database buffer cache. Waits occur
when a session attempts to read a block from disk
into cache. If free (clean) buffers are not available,
DBWR must write dirty buffers to disk. Waits simply
suggest that DBWR is not writing enough buffers to
disk.
Quantify physical disk I/O activity to ensure I/O is
distributed. You will often find DBWR is slow simply
because your I/O system is slow or not balanced.
Use the following query to view I/O distribution
across data files:
COLUMN name FORMAT a40 HEADING 'File'
COLUMN phyrds FORMAT 999999 HEADING 'PhysReads'
COLUMN phywrts FORMAT 999999 HEADING 'PhyWrites'
SELECT name,
phyrds,
phywrts
FROM v$filestat f,
v$datafile d
WHERE f.file# = d.file#;
If this wait becomes problematic, consider employing
one or more of the following tuning strategies:
• Use asynchronous I/O for DBWR.
• Configure multiple DBWR processes.
• Enlarge the data block buffer cache.
• Stripe data files across multiple physical disks.
• Use “raw” disk devices. Raw disc devices are a
configuration option offered by some Unix
vendors. Raw devices allow applications to
bypass operating system managed disc cache
and may result in performance improvement.
Also examine the wait event “db file parallel write”.
This event indicates the time DBWR takes to write
buffers to disc. DBWR writes dirty buffers to disc in
several scenarios.
The first scenario is a simple timeout event directing
DBWR to write if it has not been active for three
seconds. In busy systems DBWR rarely stands idle.
A more common scenario occurs when a server puts
a block on the dirty list and finds the list has reached
a threshold equal to half the value of the parameter
DB_BLOCK_WRITE_BATCH. DBWR is also
directed to write when a server searches the LRU list
looking for free buffers and fails to find one within a
threshold defined by the value of the configuration
parameter DB_BLOCK_MAX_SCAN_CNT. Finally,
DBWR writes upon receipt of a checkpoint from
LGWR.

The count for this event should be close to the sum

of statistics “DBWR checkpoints”, “DBWR make free
requests”, and “DBWR timeouts”. High average wait
time indicates an I/O bottleneck or that
DB_BLOCK_WRITE_BATCH is too large.

CONCLUSION

Diagnosing performance problems in an Oracle

database is a challenge. The RDBMS is a complex
system. However, visibility into the complexity is
possible using Oracle’s robust tracing capabilities,
including the wait event interface. By enabling this
functionality and learning to leverage its valuable
output, analysts have the ability to determine exactly
why a user SQL session or database processing
waits.