当前位置：首页 > 数据库 > Oracle教程 > ORACLE 常见等待事件 > 正文

ORACLE 常见等待事件

来源：这里教程网 时间：2026-03-03 11:42:55 作者：
1、db file sequential read
将数据读到连续的内存,等待时间是由于执行对索引，回滚（undo）段，和表（当借助rowid来访问），控制文件和数据文件头的单块读操作SQL语句（用户和递归）引起的。
db file sequential read的优化方法：
从读取开始，增加SGA中buffer cache的大小，避免每次都从硬盘中去读数；
优化sql语句，减少不必要的块读取；
db file scattered read  
db file scattered read发出离散读，将存储上连续的数据块离散的读入到多个不连续的内存位置。这个事件表明用户进程正在读数据到Buffer Cache中，等待直到I/O调用返回引起的等待。
2、direct path read/write （直接路径读／写）：
直接路径读（direct path read）通常发生在Oracle直接读数据到进程PGA时，这个读取不需要经过SGA。
DB file Sequential ReadDB file Scattered ReadDirect Path Read
这类读取通常在以下情况被使用：
1.磁盘排序IO操作；
2.并行查询从属进程；
3.预读操作。
直接路径写（direct path write）通常发生在Oracle直接从PGA写数据到数据文件或临时文件，这个写操作可以绕过SGA。
这类写入操作通常在以下情况被使用：
1.直接路径加载；
2.并行DML操作；
3.磁盘排序；
优化方法：1.增加pga_aggregate_target  2.并行查询导致性能问题，修改并行度
3、Buffer busy waits  ---hot block
这个等待事件的产生仅说明了一个会话在等待一个Buffer（数据块）， 当多个用户频繁地读取或者修改同样的数据块时，这个等待事件就会产生。如果等待的时间很长，我们在AWR或者statspack报告中就可以看到。
这个等待事件有三个参数。查看有几个参数我们可以用以下SQL:
SQL> select name,parameter1,parameter2,parameter3,wait_class 
        from v$event_name 
        where name='direct path write';
P1 P2 P3别代表文件号、起始数据块号、数据块的数量
解决hot block的方法有：
1、出现此情况通常可能通过几种方式调整：增大data  buffer；
2、增加freelist，减小pctused；怎样的目的是将一个block上可以使用的空间减少，这样的话：一个block上的数据存放的较少，可以提高应用的访问并发率，减少hot block的产生；
3、增加回滚段数目，增大initrans，考虑使用LMT, 确认是不是由于热点块造成(如果是可以用反转索引,或者用更小块大小)；
3、可以建立block较小的表空间，见热点对象移动到此表空间上去；
4、优化应用，优化索引，提高索引的命中率；
◎ Oracle会话正在等待钉住一个缓冲区。必须在读取或修改缓冲区前将它钉住。在任何时刻只有一个进程可以钉住一个缓冲区。
◎ buffer busy waits表明读/读、读/写、写/写争用。
◎ 采取的适当措施取决于P3参数中的原因码。
   
A、如果等待处于字段头部，应增加自由列表（freelist）的组数，或者增加pctused到pctfree之间的距离。
B、如果等待处于回退段（undo）头部块，可以通过增加回滚段(rollback segment)来解决缓冲区的问题；
C、如果等待处于回退段（undo）非头部块上，就需要降低驱动一致读取的表中的数据密度,或者增大DB_CACHE_SIZE；
D、如果等待处于数据块，可以将数据移到另一数据块以避开这个"热"数据块、增加表中的自由列表或使用LMT表空间；
E、如果等待处于索引块，应该重建索引、分割索引或使用反向键索引。
4、log file sync
等待时间发生在redo log从log buffer写入到log file期间。
此等待事件用户发出提交或回滚声明后,等待提交完成的事件,提交命令会去做日志同步,也就是写日志缓存到日志文件， 在提交命令未完成前,用户将会看见此等待事件.
解决办法：
当发生log file sync等待后,判断是否由于缓慢的日志I/O造成的,可以查看两个等待事件的等待时间,如果比较接近,就证明 日志I/O比较缓慢或重做日志过多,这时,造成log file sync的原因是因为log file parallel write。
如果log file sync的等待时间很高,而log file parallel write的等待时间并不高,这意味着log file sync的原因并不是缓慢的日志I/O,而是 用户过多的提交造成。
  当log file sync的等待时间和 log file parallel write等待时间基本相同，说明是IO问题造成的log file sync等待事件。
5、Log File Switch等待事件  
这个等待出现时，表示所有的提交(commit)的请求都需要等待"日志文件切换"的完成。
Log file Switch 主要包含两个子事件:
log file switch (archiving needed)
log file switch (checkpoint incomplete)
其中log file switch (archiving needed)
这个等待事件出现时通常是因为日志组循环写满以后，第一个日志归档尚未完成，出现该等待。出现该等待，可能表示io 存在问题。解决办法:
可以考虑增大日志文件和增加日志组
移动归档文件到快速磁盘
调整log_archive_max_processes
而log file switch (checkpoint incomplete)-日志切换(检查点未完成)
当你的日志组都写满以后，LGWR 试图写第一个log file，如果这时数据库没有完成写出记录在第一个log file 中的dirty 块时(例如第一个检查点未完成)，该等待事件出现。
该等待事件通常表示你的DBWR 写出速度太慢或者IO 存在问题。
为解决该问题，你可能需要考虑增加额外的DBWR 或者增加你的日志组或日志文件大小。
6、log buffer space
日志缓冲(log buffer)产生重做日志的速度比LGWR 的写出速度快，或者是当日志切换(log switch)太慢时，就会发生这种等待。这个等待出现时，通常表明redo log buffer 过小，为解决这个问题，可以考虑增大日志文件的大小，或者增加日志缓冲器的大小。
    另外一个可能的原因是磁盘I/O 存在瓶颈，可以考虑使用写入速度更快的磁盘。在允许的条件下设置可以考虑使用裸设备来存放日志文件，提高写入效率。在一般的系统中，最低的标准是，不要把日志文件和数据文件存放在一起，因为通常日志文件只写不读，分离存放可以获得性能提升。

编辑推荐：

相关推荐

最新软件资讯

一步一步搭建oracle 11gR2 rac+dg之环境准备(二)
一步一步搭建oracle 11gR2 rac+dg之环境准备(二)

热文推荐

天极热推