性能诊断与调优之V$--V$SYSTEM_EVEN

V$SYSTEM_EVENT View

该视图显示了自实例启动以来所有会话所有事件的累计值，包括各事件的总等待次数，总等待时间。

包括如下列：

SQL> desc  V$SYSTEM_EVENT;
Name              Type         Nullable Default Comments
----------------- ------------ -------- ------- --------
EVENT             VARCHAR2(64) Y
TOTAL_WAITS       NUMBER       Y
TOTAL_TIMEOUTS    NUMBER       Y
TIME_WAITED       NUMBER       Y
AVERAGE_WAIT      NUMBER       Y
TIME_WAITED_MICRO NUMBER       Y                 Starting Oracle9i
EVENT_ID          NUMBER       Y                 Starting Oracle10g
WAIT_CLASS_ID     NUMBER       Y
WAIT_CLASS#       NUMBER       Y
WAIT_CLASS        VARCHAR2(64) Y

EVENT 等待事件的名称

TOTAL_WAITS 总的等待次数,

TOTAL_TIMEOUTS 请求资源失败时的等待时间.

TIME_WAITED 总的等待时间

AVERAGE_WAIT 平均等待时间 = TIME_WAITED / TOTAL_WAITS.

9i之前是以厘秒（1/100 a second）为单位， 从9i开始以微秒(1/10000 a second)为单位。EVENT_ID是10g Release 1 加进来的。

How to Use V$SYSTEM_EVENT
View

The V$SYSTEM_EVENT view is a good place to start if you want to perform a quick health check on the database instance. This quick health check may be helpful when you must diagnose a poorly

performing database instance, especially if you are unfamiliar with it and the application. You will quickly discover the top n bottlenecks that plague the database instance since startup. However,

don’t judge performance or make any tuning decisions based on these bottlenecks just yet. The information is cumulative since the instance startup. You must keep the following three things in

mind when querying this view:

The V$SYSTEM_EVENT view provides instance-level wait event statistics. At this level, it does not offer details such as what sessions suffered the major bottlenecks and when they

occurred, rendering it unsuitable for root cause analysis. You cannot always associate the worst event reported by this view with a session that is currently running very slowly.

You should always order the data from this view by the TIME_WAITED column, as shown in the following example. The values in the TOTAL_WAITS column can easily misguide you. In

Chapter 1, we said you should never base your tuning decisions on quantity; rather, you should focus on time. Certain events such as the latch free event may show high TOTAL_WAITS,

but each wait is very short and therefore, the TIME_WAITED may be insignificant. Other events, such as enqueue, may have low TOTAL_WAITS, but each wait might be long.

You need to evaluate the wait time with respect to the instance startup time. Don’t be alarmed by high TIME_WAITED values. Chances are, the longer the instance uptime, the more you

will see wait events having high TOTAL_WAITS and TIME_WAITED values.

可以快速通过V$system_event来定位一个性能糟糕的系统的top n 瓶颈，但是不能依靠这些信息来判断性能并对调优作出决定，因为这些值是自实例启动以来的累计值。在使用这个视图时你必须清楚

如下几点：

该视图是实例级别的事件统计信息，不能作为会话级别的相关数据分析。
不要被TOTAL_WAITS列的高数值所误导，代表等待的次数，第一章中就已说明不要只注意数量，要同响应时间来作出决定。因为有可以等待次数多，但总的等待时间并不长，所以性能不一定有问题。
不要被TIME_WAITED列的高数值所吓倒，因为这是一个累计值，实例启动的时间越长，该值越大。

不同版本可以查看信息方式如下：

Prior to Oracle10g:

set lines 130
set numwidth 18
col event for a30
col total_waits for 999,999,999
col total_timeouts for 999,999,999
col time_waited for 999,999,999,999
col average_wait for 999,999,999,999
select a.*, b.startup_time
from v$system_event a,
v$instance b
order by a.time_waited;

Starting Oracle10g:

set lines 160
set numwidth 18
col class for a15
col event for a30
col total_waits for 999,999,999

col total_timeouts for 999,999,999
col time_waited for 999,999,999,999
col average_wait for 999,999,999,999
select b.class, a.*, c.startup_time
from v$system_event a,
v$event_name b,
v$instance c
where a.event = b.name
order by b.class, a.time_waited;

Pay attention to the AVERAGE_WAIT column of I/O related events (the User I/O and System I/O classes in Oracle Database 10g Release 1), which are reported in centiseconds. It can shed some light

on the speed of your I/O subsystem. More importantly, it represents your average I/O cost. As shown in the following partial example output from an Oracle8i Database instance, on average it

costs a session 0.103029259 centiseconds (10ms) for each single block read and 0.061187607 centiseconds (6ms) for each multiblock read. So you may be able to tolerate higher I/O calls if the

average costs are low. (There is more discussion on this subject in Chapter 5.)

EVENT TOTAL_WAITS TIME_WAITED AVERAGE_WAIT

------------------------- ----------- ----------- ------------

db file sequential read 63094601 650059 0 .103029259

db file scattered read 103809207 6351837 0 .061187607

要注意与I/O相关事件的AVERAGE_WAIT 值,

The data in the V$SYSTEM_EVENT view persists throughout the life of the instance. Oracle doesn’t store information from this view for historical analysis as it does for the V$LOG_HISTORY view.

该视图中的信息在实例的生命期内是一直存在的，要想对历史数据进行分析，则要查看V$LOG_HISTORY视图