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即可确定
文档
发布评论