2024年6月15日发(作者:)

实用标准文案

我们可以通过视图v$session_wait来查看系统当前的等待事件,以及与等待事件相对

应的资源的相关信息

看书笔记db file scattered read DB ,db file sequential read DB,free buffer

waits,log buffer space,log file switch,log file sync

我们可以通过视图v$session_wait来查看系统当前的等待事件,以及与等待事件相对

应的资源的相关信息,从而可确定出产生瓶颈的类型及其对象。v$session_wait的p1、

p2、p3告诉我们等待事件的具体含义,根据事件不同其内容也不相同,下面就一些常见

的等待事件如何处理以及如何定位热点对象和阻塞会话作一些介绍。

<1> db file scattered read DB 文件分散读取 (太多索引读,全表扫描-----调整代码,

将小表放入内存)

这种情况通常显示与全表扫描相关的等待。当全表扫描被限制在内存时,它们很少会

进入连续的缓冲区内,而是分散于整个缓冲存储器中。如果这个数目很大,就表明该表找

不到索引,或者只能找到有限的索引。尽管在特定条件下执行全表扫描可能比索引扫描更

有效,但如果出现这种等待时,最好检查一下这些全表扫描是否必要。因为全表扫描被置

于LRU(Least Recently Used,最近最少适用)列表的冷端(cold end),所以应尽量存储

较小的表,以避免一次又一次地重复读取它们。

==================================================

该类事件的p1text=file#,p1是file_id,p2是block_id,通过dba_extents即可确定

出热点对象(表或索引)

文档

实用标准文案

select owner,segment_name,segment_type

from dba_extents

where file_id = &file_id

and &block_id between block_id and block_id + &blocks - 1;

==================================================

<2> db file sequential read DB 文件顺序读取 (表连接顺序不佳-----调整代码,特

别是表连接)

这一事件通常显示单个块的读取(如索引读取)。这种等待的数目很多时,可能显示表

的连接顺序不佳,或者不加选择地进行索引。对于大量事务处理、调整良好的系统,这一

数值大多是很正常的,但在某些情况下,它可能暗示着系统中存在问题。你应当将这一等

待统计量与Statspack 报告中的已知问题(如效率较低的SQL)联系起来。检查索引扫描,

以保证每个扫描都是必要的,并检查多表连接的连接顺序。DB_CACHE_SIZE 也是这些等

待出现频率的决定因素。有问题的散列区域(Hash-area)连接应当出现在PGA 内存中,

但它们也会消耗大量内存,从而在顺序读取时导致大量等待。它们也可能以直接路径读/

写等待的形式出现。

==================================================

=

该类事件的p1text=file#,p1是file_id,p2是block_id,通过dba_extents即可确定

文档