基于时间模型统计信息，不仅可以确定数据库实例(会话或容器)花费了多少时间处理，也能知道这个处理使用了多少CPU。当这两个值相等时，代表数据库实例并没有经历类似磁盘I/O操作、网络回路或者锁的等待。然而，当这两个值不同时，为了分析性能问题，你需要知道服务器进程正在等待哪些资源。而这个信息就来自等待事件。
由于等待事件非常多(在12.1版本中有超过1500个),为了简化分析产品的资源使用，等待事件被分成13个等待级别(注意，10.2版本中是12个)。通过查询v$event_name视图可以得知当前版本有哪些等待事件及其等待级别。例如，以下查询显示了在12.1.0.1版本中存在的等待级别，每个级别包含的等待事件数以及一些等待事件(Commit)所属的等级级别：
select wait_class, count(*)
from v$event_name
group by rollup(wait_class)
order by wait_class;
select name from v$event_name where wait_class = 'Commit';
select * from v$event_name where name like '%enq: TX%';
v$system_wait_class和v$session_wait_class视图分别记录了系统级别与所有连接会话的等待事件级别。此外，在12.1多租户环境下，v$con_system_wait_class显示容器级别的统计信息。这些动态性能视图有下面三个关键列。
wait_class标识等待级别。
toal_waits提供对应组件(数据库实例、会话或容器)从初始化开始累积的等待事件数。
time_waited提供对应组件(数据库实例、会话或容器)从初始化开始累积的总等待时间(单位：百分之一秒)。
当然，对于会话级别的统计信息(v$session_wait_class),同样存在列(sid)用来标识对应的会话，并且在12.1多租户环境下，存在列(conid)用来标识容器。接下来的例子使用与之前例子一样的会话(在CPU上花费4.4%的DBtime)。用这个例子说明，如何对会话执行处理以生成一个简要的资源使用分析。可以在系统级别和容器级别使用类似的查询。只需要将查询涉及的动态性能视图更改为对应的级别即可。
select wait_class,
round(time_waited, 3) as time_waited,
round(1e2 * ratio_to_report(time_waited) over(), 1) as "%"
from (select sid, wait_class, time_waited / 1e2 as time_waited
from v$session_wait_class
where total_waits > 0
union all
select sid, 'CPU', value / 1e6
from v$sess_time_model
where stat_name = 'DB CPU')
where sid = 42
order by 2 desc;
即便已经开始基于等级级别的资源使用分析，大多数时候你仍然需要准确的信息。你需要等待事件。为此，数据库引擎分别通过v$system_event和v$session_event视图来提供系统级别和所有连接会话的等待事件信息。此外，在12.1多租户环境下，v$con_system_event视图提供容器级别信息。以下查询用来说明如何对会话执行处理以生成详细的资源使用分析(可以在系统级别和容器级别使用类似的查询。只需要将查询涉及的动态性能视图更改为对应的级别),使用的是与前面例子相同的会话。
select event,
round(time_waited, 3) as time_waited,
round(1e2 * ratio_to_report(time_waited) over(), 1) as "%"
from (select sid, event, time_waited / 1e2 as time_waited
from v$session_event
where total_waits > 0
union all
select sid, 'CPU', value / 1e6
from v$sess_time_model
where stat_name = 'DB CPU')
where sid = 42
order by 2 desc;
在上面的输出中，你可以注意到DB time只占用了总执行时间的39.8%(100-60.2)。实际上，剩下的60.2%被空闲等待事件占用(SQL*Net message from client)。这表示在60.2%的时间里，数据库引擎在等待应用提交作业。这个资源使用分析提供的另一个重要的信息是，当数据库引擎处理用户调用时，它总是单块读来执行磁盘I/O操作(db file sequential read)。 所有其他的等待事件和CPU使用率都可忽略不计。
对于一些等待事件，比如与磁盘I/O操作有关的，你或许想要知道平均延迟的信息。实际上，如果你有这些信息，就可以对比当前性能与预期性能(你应该知道用来存储数据库的磁盘I/O子系统的预期性能)。比如，可以基于视图(比如v$system_event)执行查询来计算某一等待事件的平均延迟。
select time_waited_micro / total_waits / 1e3 as avg_wait_ms
from v$system_event
where event = 'db file sequential read';
上面这个查询计算出来的平均值隐藏了很多信息，Oracle数据库提供了一个视图，该视图可以在系统级别为每个等待事件提供直方图。这个视图就是v$event_histogram。它有下面三个关键列。
event是等待事件的名称。
wait_time_milli代表每个直方图桶的上限值(不包含在内)。
wait_count是与等待事件关联的直方图桶数。
比如，接下来的查询显示多数(45.7%)等待事件在4毫秒和8毫秒的桶内，约24%(3.27+2.75+18.37)在小于4毫秒的桶内，约10%(5.96+2.66+1.34+0.17+0.01)在16毫秒以及更大的桶内。
select wait_time_milli,
wait_count,
round(100 * ratio_to_report(wait_count) OVER(), 2) AS "%"
from v$event_histogram
where event = 'db file sequential read'
order by 1;
上面的信息主要显示最大值是多少。在本例中，一些磁盘I/O操作远远超出预期(在64毫秒的桶与2秒的桶之间)。尽管这样的操作不多，却能表明要么磁盘I/O系统(或其中一个组件)太小，要么配置或硬件有问题。
