ITPub博客

首页 > 数据库 > Oracle > ORACLE 常见等待事件

ORACLE 常见等待事件

原创 Oracle 作者:zr2095 时间:2015-10-11 09:47:41 0 删除 编辑
 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 存在瓶颈,可以考虑使用写入速度更快的磁盘。在允许的条件下设置可以考虑使用裸设备来存放日志文件,提高写入效率。在一般的系统中,最低的标准是,不要把日志文件和数据文件存放在一起,因为通常日志文件只写不读,分离存放可以获得性能提升。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/30208428/viewspace-1813736/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2015-04-15

  • 博文量
    163
  • 访问量
    420220