Beruflich Dokumente
Kultur Dokumente
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.
query1:
AUDIENCE
SELECT *
FROM v$event_name;
This paper is intended for database administrators,
application developers, and performance analysts The query returns the names and associated
tasked with ensuring the performance of Oracle- parameters of all wait events. Version 7.3 includes
based applications and systems. Familiarity with 105 wait events. It is important to note the
RDBMS concepts, performance analysis, and Oracle ephemeral use of specific wait events across Oracle
terminology is assumed. releases and versions2. The caveat has been, and
continues to be: "wait events are tied to the internal
OBJECTIVES implementation of Oracle and therefore subject to
change or deletion without notice."3 This speaks to
This paper provides: the interface's roots as an internal diagnostic tool.
This also suggests that its reliability and accuracy
• An overview of Oracle wait event management; need careful scrutiny.
• A description of database objects related to the
wait event interface; PERFORMANCE VIEWS
• Practical methods to observe wait events;
• Interpretations of common wait events; and If you have ever tuned an Oracle database the V$
• High-level tuning considerations to mitigate performance views are immediately familiar. The
excessive waiting. performance views associated with wait event
management include:
BACKGROUND
• V$EVENT_NAME (Oracle7.3+)
The Oracle database server records the occurrence • V$SESSION_EVENT
of blocking procedures and associated wait times. • V$SESSION_WAIT
Blocking procedures are synchronous operations • V$SYSTEM_EVENT
that create a wait in user SQL processes or instance
processes. The execution of a blocking procedure V$SYSTEM_EVENT provides a high-level system
generates a “wait event”. Wait events are recorded view and is used by the performance scripts
in database objects known as dynamic performance utlbstat.sql and utlestat.sql (collectively referred to as
views, or V$ (pronounced “vee dollar”) tables. bestat). The view contains grouped statistics about
wait events recorded since instance startup. Use it
In addition to V$ tables, applications can record wait to acquire a system-level viewpoint.
event records in a trace file. This is sometimes called
“10046 trace” after the statement used to enable it:
Applications written using Oracle pre-compilers such It is important to understand why elapsed wait time is
as Pro*C6 use embedded SQL (ESQL) statements to zero. There are two reasons for a zero value.
access the database engine. The following ESQL TIMED_STATISTICS may not be set to TRUE.
statements enable and disable trace: Alternatively, timed statistics may be enabled but the
actual wait time was less than .01 second. Time
exec sql ALTER SESSION SET SQL_TRACE TRUE;
exec sql ALTER SESSION SET SQL_TRACE FALSE;
granularity is limited to .01 second, commonly known
as a “tick”. This second case occurs quite
Wait events are not written to trace files by default. frequently, especially with “SQL*Net” wait events.
To enable trace and include wait events, use the Be careful not to ignore zero value waits, as their
following ESQL statement: cumulative value can be significant. Ten thousand
zero value events, for example, represent close to
exec sql ALTER SESSION SET EVENTS '10046 trace one hundred elapsed seconds.
name context forever, level 12';
INTERPRETING WAIT EVENTS
This is referred to as “10046” trace and is not
documented by Oracle. Harrison7 and Velpuri8 The following query executed against a Version 7.3
address event 10046 and other aspects of the trace database shows 105 unique wait events.
facility. Oracle support personnel routinely use event
trace capability and consider it safe. SELECT COUNT(*)
FROM v$event_name;
Oracle Version 7.3 allows trace to be enabled in a
COUNT(*)
session from svrmgr. This is useful but it does not ----------
enable the session to record wait events. To enable 105
trace for a session use this procedure:
Samples taken from production systems, however,
DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION reveal an average of twenty-five common events. Of
these twenty-five, we are concerned with only those
The procedure requires that you obtain the values of that represent significant session wait time.
columns SID and SERIAL# from V$SESSION for the
PID or user in question. See Version 7.3 Client message | SQL*Net9 message from
documentation for details on this procedure. client
Oracle provides a utility called tkprof to format raw “Client message” is observed prior to Version 7.3. It
trace files. Unfortunately the utility ignores wait is superseded by “SQL*Net message” in Versions
7.3 and above. Both events occur when an Oracle
6
Pro*C is a registered trademark of Oracle Corporation server (shadow) process awaits a message from its
7
[HARR96] Guy Harrison, “Getting the most from the client (foreground) process.
SQL_TRACE Facility”, OTJ, Winter 1996
8 9
[RAMA95] Rama Velpuri, “Oracle Backup & Recovery SQL*Net is a registered trademark of Oracle
Handbook”, 1995 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
DB file [sequential | scattered] read Several techniques may be used to reduce “db file
wait”. First, identify and, if possible, optimize
These wait events occur every time a user session offensive SQL statements. Use the output of tkprof
waits while reading database blocks. Sequential to identify resource intensive statements. The
reads are associated with indexed access and queries listed at the end of this section identify SQL
scattered reads with scan (multi-block read) statements resulting in high I/O. Next, physically
operations. These waits are unavoidable, but do not separate files. Aronoff et al.10 suggest separating
ignore them. Excessive wait time suggests I/O the following objects: tables from indexes; rollback
contention. segments from tables; rollback segments from online
redo logs; online redo logs from archived redo log
Drill-down analysis involves two tasks. The first step files; temporary tablespaces from data tablespaces;
is to identify wait parameters P1 (file#) and P2 and SYSTEM tablespace from the rest of the
(block#) and resolve them to a specific database database. Other techniques to explore include the
table. The next step is to map the table to SQL use of operating system file striping (if available) and
11
sessions accessing it. table partitioning (an option with Oracle8 ).
CONCLUSION