buffer busy waits
当一个会话访问buffer cache中的某个数据块。而这个数据块被其他的会话正在从数据文件读取到buffer cache中,或者在buffer cache中修改这个数据库,那么就会产生buffer busy waits。
为了保证读取buffer cache中数据块的session读到一致的数据镜像。修改这个数据块的会话会在修改开始的时候在该块的块头插上一面小红旗,表示该块已经被占领。其他会话过来读取就会让他们等,一直到修改完成。
在Oracle 10gR1之前buffer busy waits只是表示为read by other session.而从10gR1开始buffer busy waits也包含数据块修改的情况。
从Oracle 10gR1开始出现了一个新的等待buffer busy,他和buffer busy waits不是一个东西,不能将他们混淆。buffer busy出现在使用ASM的数据库中会话访问数据库的缓存元数据时。
controlfile parallel write
controlfile parallel write等待事件发生在等待写所有控制文件请求完成的时候。服务器进程会并发的写控制文件。从Oracle 8.0.5开始,CKPT进程每隔3s将重做日志中的检查点信息写入到控制文件中。Oracle数据库在recovery的时候会用到这些信息。
还有,当你在NOLOGGING或者UNRECOVERABLE的情况下执行DML操作时,Oracle将记录unrecoverable SCN到控制文件里面。
Recovery Manager(RMAN)将来备份信息到控制文件里面。
没有会话阻塞在controlfile parallel write这个等待事件上。会话阻塞在等待OS和I/O子系统完成写所有控制文件的操作上。会话在写控制文件的时候将会持有一个CF队列,所以其他会话其实是在等这个队列。如果系统中这样的等待事件非常明显,表示写控制文件太频繁,且写控制文件的I/O太低。
db file parallel read
该等待事件的意义和名字相反,db file parallel read和并行操作没有任何关系。既不是并行的DML,也不是并行的查询。这个等待事件发生在数据库的恢复操作时,将需要恢复的数据块并行地从数据库文件中读取出来。也可能是服务器进程从一个或多个数据文件中读取多个非连续的单块。也是一个I/O方面的等待。
db file parallel write
跟db file parallel read一个意思,他并不表示数据库做任何的并行操作。没有任何的并行的DML操作。这个一个属于DBWn的进程等待。事实上这个唯一的一个将脏数据刷新到物理的数据文件中的后台进程。
DBWR将多个脏数据块编入到一组“write batch”中。然后发起多个I/O请求将write batch写入到数据文件中。在等待写操作完成的时候出现db parallel wirte等待事件。
db file scattered read
这个等待事件表示用户进程正在读取缓存到SGA buffer中,并且在等待I/O返回完成操作。db file scattered read表示读取多个块到到内存区域。这个等待事件一般出现在full table scans or index fast full scans
当出现db file scattered read的时候表示正在发生一个全扫描。当全扫描读取数据到buffer cache中的时候,数据在内存里面存放不是想物理的那样有序的,而是无序的。这就是为什么这个事件叫做”db file scagttered read”了。初始化参数db_file_multiblock_read_count决定了一次scattered read最多读多少数据块。
db file sequential read
数据文件单块读发生在进程等待I/O完成单块读的情况下。当使用索引,回滚段或者undo segment读取数据。通过rowid访问表,重建控制文件,dump数据文件头文件的时候会出现这样的等待事件。
db file single write
db file single write等待事件是由DBWR后台进程产生的。当出现更新数据文件头文件(一般是checkpoint)时可能会出现这个等待事件。当该等待时间过多的时候,你可能是数据文件太多了。
direct path read
direct path read发生在直接将数据读取到PGA中,而不经过SGA。直接路径读取可能执行在同步或异步的I/O模式下。取决于你的硬件,平台,和初始化参数DISK_ASYNCH_IO。直接路径读取的I/O通常是访问磁盘上的临时段。一般的操作包括排序,并行查询,hash joins.
如果你的系统不支持异步I/O,那么每一个等待就对应着一个物理读。
如果你的系统支持异步I/O,那么后台进程能够向PGA中存在的数据发出重叠读取请求。
direct path write
和direct patch read操作相反,改事件是有Oracle将PGA中的buffer写入到datafile中所产生的I/O等待。
enqueue
enqueue是Oracle用来序列访问数据库资源的共享内存结构。换句话说就是和事务相关了。这个等待事件意味着Oracle的会话正在等待一个被其他会话持有的锁。enqueue的命名规范是这样的:
enq:enqueue_type - related_details。在某些情况下相同的enqueue类型可以持有不同的目的。如下TX类型的情况:
■ enq: TX - allocate ITL entry
■ enq: TX - contention
■ enq: TX - index contention
■ enq: TX - row lock contention
可以通过访问视图V$SESSION_WAIT获得额外的信息
■ P1: Lock TYPE (or name) and MODE
■ P2: Resource identifier ID1 for the lock
■ P3: Resource identifier ID2 for the lock
如果系统中有排队等待,可以使用如下查询看到
SQL> SELECT * FROM V$LOCK WHERE request > 0;
SQL> set pagesize 1400
SQL> set linesize 140
SQL> SELECT DECODE(request, 0, 'Holder: ', 'Waiter: ') || sid sess,
id1,
id2,
lmode,
request,
type
FROM V$LOCK
WHERE (id1, id2, type) IN
(SELECT id1, id2, type FROM V$LOCK WHERE request > 0)
ORDER BY id1, request;
free buffer waits
free buffer waits这个等待事件发生在会话在database buffer cache中不能读取到空闲的缓存,或者不能建立一致性读的镜像。这可能是database buffer cache太小,或者是在database buffer cache中的脏数据块不能足够快地刷新到磁盘。DBWR刷新脏块到磁盘会受到这个等待事件的影响。
latch free
latch是oracle的一个轻量级锁。是Oracle用来保护数据库的内存结构的。轻量级并不是说他不重要。
一个进程在获得latch后,在同一时间只能修改或者查看内存数据结构。其他进程想要访问内存数据结构必须要先获得latch。和enqueue不同的是,当进程访问一个被其他会话持有的latch的时候之后等待很短的时间,然后继续尝试访问。短暂的等待时间我们称之为”spin”。如果在多次spin之后还是没有获得latch,进程将会休眠一段时间之后继续尝试访问。直到成功获取到latch。
library cache pin
library cache pin等待事件是和library cache的一致性有关的。当一个会话尝试去修改或者访问library cache里面的数据之前,必须持有一个pin来确认在同一时间该对象没有被其他会话修改。Oracle会在会话收集,解析PL/SQL存储过程和视图的时候出现这个等待事件。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26169542/viewspace-774049/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/26169542/viewspace-774049/