Oracle 常见的等待事件<二>

Oracle优化大师 2016-11-24

954

续

Free buffer waits

当一个会话将数据块从磁盘读到内存中时，它需要到内存中找到空闲的内存空间来存放这些数据块，当内存中没有空闲的空间时，就会产生这个等待；除此之外，还有一种情况就是会话在做一致性读时，需要构造数据块在某个时刻的前映像（image），此时需要申请内存来存放这些新构造的数据块，如果内存中无法找到这样的内存块，也会发生这个等待事件。

当数据库中出现比较严重的free buffer waits等待事件时，可能的原因是：

data buffer 太小，导致空闲空间不够
内存中的脏数据太多，DBWR无法及时将这些脏数据写到磁盘中以释放空间

这个等待事件包含2个参数：

File#：需要读取的数据块所在的数据文件的文件号。
Block#：需要读取的数据块块号。
查询阻塞的语句：

SELECT *+ ORDERED USE_HASH(H,R) */

h.sid hold_sid,

holds.username h_user,

holds.lockwait h_lockwait,

holds.status h_status,

holds.module h_module,

holds.row_wait_obj# h_obj,

holds.row_wait_row# h_row,

r.sid wait_sid,

waits.username w_user,

waits.lockwait w_lockwait,

waits.status w_status,

waits.module w_module,

waits.row_wait_obj# w_obj,

waits.row_wait_row# w_row,

h.type h_type,

h.id1 h_id1,

h.id2 h_id2,

h.lmode h_lmode,

h.request h_request,

h.ctime h_ctime,

h.block h_block,

r.type r_type,

r.id1 r_id1,

r.id2 r_id2,

r.lmode r_lmode,

r.request r_request,

r.ctime r_ctime,

r.block r_block,

'alter system kill session ''' || holds.sid || ',' || holds.serial# || '''; -- kill -9 ' ||

nvl(holdp.spid,

'null') killhold,

holdsql.sql_text hsql,

waitsql.sql_text wsql

FROM v$lock h,

v$lock r,

v$session holds,

v$session waits,

v$process holdp,

v$sqlarea holdsql,

v$sqlarea waitsql

WHERE h.block = 1

AND r.block = 0

AND h.type <> 'MR'

AND r.type <> 'MR'

AND h.id1 = r.id1

AND h.id2 = r.id2

AND h.sid = holds.sid

AND r.sid = waits.sid

AND holds.paddr = holdp.addr(+)

AND holds.sql_address = holdsql.address(+)

AND holds.sql_hash_value = holdsql.hash_value(+)

AND waits.sql_address = waitsql.address(+)

AND waits.sql_hash_value = waitsql.hash_value(+);

Latch free

在10g之前的版本里，latch free 等待事件代表了所有的latch等待，在10g以后，一些常用的latch事件已经被独立了出来：

这个等待事件有三个参数：

Address: 会话等待的latch 地址。
Number： latch号，通过这个号，可以从v$latchname 视图中找到这个latch 的相关的信息。

Library cache lock

这个等待时间发生在不同用户在共享中由于并发操作同一个数据库对象导致的资源争用的时候，比如当一个用户正在对一个表做DDL 操作时，其他的用户如果要访问这张表，就会发生library cache lock等待事件，它要一直等到DDL操作完成后，才能继续操作。

这个事件包含四个参数：

Handle address: 被加载的对象的地址。
Lock address：锁的地址。
Mode：被加载对象的数据片段。
Namespace：被加载对象在v$db_object_cache 视图中namespace名称。

Library cache pin

这个等待事件和library cache lock 一样是发生在共享池中并发操作引起的事件。通常来讲，如果Oracle 要对一些PL/SQL 或者视图这样的对象做重新编译，需要将这些对象pin到共享池中。如果此时这个对象被其他的用户特有，就会产生一个library cache pin的等待。

这个等待事件也包含四个参数：

Handle address: 被加载的对象的地址。
Lock address：锁的地址。
Mode：被加载对象的数据片段。
Namespace：被加载对象在v$db_object_cache 视图中namespace名称。

Log file parallel write

后台进程LGWR 负责将log buffer当中的数据写到REDO 文件中，以重用log buffer的数据。如果每个REDO LOG组里面有2个以上的成员，那么LGWR进程会并行地将REDO 信息写入这些文件中。

如果数据库中出现这个等待事件的瓶颈，主要的原因可能是磁盘I/O性能不够或者REDO 文件的分布导致了I/O争用，比如同一个组的REDO 成员文件放在相同的磁盘上。

这个等待事件有三个参数：

Files：操作需要写入的文件个数。
Blocks：操作需要写入的数据块个数。
Requests：操作需要执行的I/O次数。

Log buffer space

当log buffer 中没有可用空间来存放新产生的redo log数据时，就会发生log buffer space等待事件。如果数据库中新产生的redo log的数量大于LGWR 写入到磁盘中的redo log 数量，必须等待LGWR 完成写入磁盘的操作，LGWR必须确保redo log写到磁盘成功之后，才能在redo buffer当中重用这部分信息。

如果数据库中出现大量的log buffer space等待事件，可以考虑如下方法：

增加redo buffer的大小。
提升磁盘的I/O性能

Log file sequential read

这个等待事件通常发生在对redo log信息进行读取时，比如在线redo 的归档操作，ARCH进程需要读取redo log的信息，由于redo log的信息是顺序写入的，所以在读取时也是按照顺序的方式来读取的。

这个等待事件包含三个参数：

Log#：发生等待时读取的redo log的sequence号。
Block#：读取的数据块号。
Blocks：读取的数据块个数。

Log file single write

这个等待事件发生在更新redo log文件的文件头时，当为日志组增加新的日志成员时或者redo log的sequence号改变时，LGWR 都会更新redo log文件头信息。

这个等待事件包含三个参数：

Log#：写入的redo log组的编号。
Block#：写入的数据块号。
Blocks：写入的数据块个数。

Log file switch(archiving needed)

在归档模式下，这个等待事件发生在在线日志切换（log file switch）时，需要切换的在线日志还没有被归档进程（ARCH）归档完毕的时候。当在线日志文件切换到下一个日志时，需要确保下一个日志文件已经被归档进程归档完毕，否则不允许覆盖那个在线日志信息（否则会导致归档日志信息不完整）。出现这样的等待事件通常是由于某种原因导致ARCH 进程死掉，比如ARCH进程尝试向目的地写入一个归档文件，但是没有成功（介质失效或者其他原因），这时ARCH进程就会死掉。如果发生这种情况，在数据库的alert log文件中可以找到相关的错误信息。

这个等待事件没有参数。

Log file switch(checkpoint incomplete)

当一个在线日志切换到下一个在线日志时，必须保证要切换到的在线日志上的记录的信息（比如一些脏数据块产生的redo log）被写到磁盘上（checkpoint），这样做的原因是，如果一个在线日志文件的信息被覆盖，而依赖这些redo 信息做恢复的数据块尚未被写到磁盘上（checkpoint），此时系统down掉的话，Oracle将没有办法进行实例恢复。

在v$log 视图里记录了在线日志的状态。通常来说，在线日志有三种状态。

Active: 这个日志上面保护的信息还没有完成checkpoint。
Inactive：这个日志上面保护的信息已完成checkpoint。
Current：当前的日志。

如果系统中出现大量的log file switch（checkpoint incomplete）等待事件，原因可能是日志文件太小或者日志组太少，所以解决的方法是，增加日志文件的大小或者增加日志组的数量。

这个等待事件没有参数。

Log file sync

这是一个用户会话行为导致的等待事件，当一个会话发出一个commit命令时，LGWR进程会将这个事务产生的redo log从log buffer里面写到磁盘上，以确保用户提交的信息被安全地记录到数据库中。会话发出的commit指令后，需要等待LGWR将这个事务产生的redo 成功写入到磁盘之后，才可以继续进行后续的操作，这个等待事件就叫作log file sync。

以下几种情况，可能产生这个等待：

高提交频率
解决方法是简单的消除不必要的提交，事务是工作单元。工作单元应该是全部成功或全部失败。
缓慢的I/O子系统
较高的IO吞吐良可以改善log file sync和log file parallel write事件的平均等待时间。频繁的提交会弄乱数据库布局和IO子系统。解决办法是将日志文件放裸设备上或绑定在RAID 0或RAID 0+1中，而不是绑定在RAID 5中。
过大的日志缓冲区
过大的日志缓冲区也可能延长log file sync等待。大型的日志缓冲区减少后台写入的数量，允许LGWR变得懒惰，并导致更多的重做条目堆积在日志缓冲区中。同时可以调整参数_LOG_IO_SIZE参数，其默认值是LOG_BUFFER的1/3或1MB，取两者之中较小的值。换句话说，你可以具有较大的日志缓冲区，但较小的_LOG_IO_SIZE将增加后台写入，从而减少log file sync的等待时间.
过小的日志缓冲区
过小的日志缓冲区，还会导致log buffer space等待
日志组多少与日志大小不合适
这个等待事件包含一个参数：
Buffer#: redo buffer 中需要被写入到磁盘中的buffer。

SQL*Net break/reset to client

当出现这个等待事件时，说明服务器端在给客户端发送一个断开连接或者重置连接的请求，正在等待客户的响应，通常的原因是服务器到客户端的网络不稳定导致的。

这个等待事件包含两个参数：

Driver id: 服务器和客户端连接使用的协议信息。
Breaks：零表示服务端向客户端发送一个重置（reset）信息，非零表示服务器端向客户端发送一个断开（break）消息。

SQL*Net break/reset to dblink

这个等待事件和SQL*Net break/reset to client 相同。不过它表示的是数据库通过dblink访问另一台数据库时，他们之间建立起一个会话，这个等待事件发生在这个会话之间的通信过程中，同样如果出现这个等待事件，需要检查两台数据库之间的通信问题。

这个等待事件有两个参数：

Driver id: 服务器和客户端连接使用的协议信息。
Breaks：零表示服务端向客户端发送一个重置（reset）信息，非零表示服务器端向客户端发送一个断开（break）消息。

SQL*Net message from client

这个等待事件基本上是最常见的一个等待事件。当一个会话建立成功后，客户端会向服务器端发送请求，服务器端处理完客户端请求后，将结果返回给客户端，并继续等待客户端的请求，这时候会产生SQL*Net message from client 等待事件。很显然，这是一个空闲等待，如果客户端不再向服务器端发送请求，服务器端将一直处于这个等待事件状态。

这个等待事件包含两个参数：

Driver id: 服务器端和客户端连接使用的协议信息。
#bytes: 服务器端接收到的来自客户端消息的字节数。

SQL*Net message from dblink

这个等待事件和SQL*Net message from client相同，不过它表示的是数据库通过dblink 访问另一个数据库时，他们之间会建立一个会话，这个等待事件发生在这个会话之间的通信过程中。

这个等待事件也是一个空闲等待事件。

这个事件包含两个参数：

Driver id: 服务器端和客户端连接使用的协议信息。
#bytes: 服务器端通过dblink 收到的来自另一个服务器端消息的字节数。

期待下期更精彩！

http://www.7daysgps.com/

本文分享自微信公众号 - Oracle优化大师，如有侵权，请联系 service001@enmotech.com 删除。

oracle

最后修改时间：2019-12-20 10:53:33

文章转载自Oracle优化大师，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

Oracle 常见的等待事件<二>

评论