Oracle RAC Wait Events

本文来自:
Oracle database 11g RAC 手册》 ---10.7 Oracle RAC 等待事件
《Real Application Clusters Administration and Deployment Guide》

集群等待事件属于以下类别之一:
(1) 面向块的等待
(2) 面向消息的等待
(3) 面向争用的等待
(4) 面向负载的等待

1. 面向块的等待

面向块的等待是最常见的集群等待事件。面向块的等待事件统计信息表明所请求的块是从其他实例提供的。在两节点集群环境中,一条消息被传送到块的当前拥有者,这个拥有者将块传递给请求者。在具有两个以上节点的集群环境中,这个快的请求通过资源主控者传递给块的拥有者,其中拥有附加信息。
这些事件通常在没有块争用时最为频繁,等待时间长度区域于它在物理网络上花费的时间、在服务实例中处理请求的时间、在数据库到达之后唤醒请求进程所花费的时间。
如果这些特定的等待对性能具有严重影响,那么应当考虑平均等待时间和总等待时间。我们通常会发现,互联问题、负载问题或针对大型共享工作集执行SQL操作可能是根本原因。
下面是最常见的面向块的等待:
1 gc current block 2-way
2 gc current block 3-way
3 gc cr block 2-way
4 gc cr block 3-way

1. gc current block 2-way

一个实例请求对当前节点中的一个数据库进行授权,以修改该数据块。主控相应资源的实例接收到这一请求。主控者拥有这个块的当前版本,通过“缓存融合机制”将这个数据块的当前版本发生到请求者。这个事件表明存在“写/写”争用。
Gc current block 2-way出现不一定表明存在性能问题,它只是表明这些实例只是在访问对方缓存中的数据副本,但是,如果每个事件的平均等待时间非常长,那可能会影响性能,需要进一步分析。
(1)分析争用。AWR中Current Blocks Received部分内容应当可以帮助确认争用严重的对象。
(2)确保对争用最严重的对象采用了良好的数据库对象设计实践、数据库对象布局和空间管理实践。
(3)使用适当的应用程序分区方案,对应用程序争用进行优化。

2. gc current block 3 -way

一个实例请求以当前模式访问一个数据块的授权。主控相应资源的实例接收请求,并将消息转发给当前拥有者,告诉他放弃所有权。这个拥有实例通过缓存融合机制将数据块当前版本的副本发送给请求方,并将独占锁传送给发出请求的实例。这个事件表明存在“写/写”争用。

3. gc cr block 2-way

一个实例请求以CR模式访问一个数据块的授权。主控相应资源的实例接收这个请求。这个主控者拥有这个数据块的当前版本。它是以当前块和它拥有的撤销数据制作CR副本,并通过互联将这个块的CR副本传送到请求方,这个事件表明存在“写/读”争用。
如果这个等待事件出现在“前5个最耗时的事件”列表中,那么可执行以下操作:
(1)分析争用。AWR报告中的“Segment by CR Blocks Received”部分应当可以帮助确定争用最严重的对象。
(2)使用适当的应用程序分区方案,对应用程序争用进行优化。

4.gc cr block 3-way

一个实例请求以CR模式访问一个数据块的授权。主控相应资源的实例接收此请求。主控者将请求转发给这个块的当前拥有者。这个拥有实例通过缓存融合机制将这个数据块的CR副本发送给请求方。这个事件表明存在“写/读”争用。

2. 面向消息的等待

面向消息的等待事件统计信息表明没有接收到数据块。原因是在任何实例中没有缓存它。但对发出请求的实例授予全局访问权限,允许它从磁盘中读取数据块或者修改它。这些等待之后通常跟着一个磁盘读取事件,如db file sequential read或db file scattered read。
如果这些等待事件占用的时间很长,那么可以假定是频繁执行的SQL导致了大量磁盘I/O(在cr授权情况下),或者是工作量插入了大量数据,需要经常查找和格式化新块(在当前授权情况下)。
下面是最常见的面向消息的等待:
1 gc current grant 2-way
2 gc current grant 3-way
3 gc cr grant 2-way
4 gc cr grant 3-way

1 gc current grant 2-way

当一个实例需要当前模式的一个数据块时,它将这个请求发送给主控实例,主控实例发现所有实例(包含它自己在内)目前都没有锁定被请求的块。向发出请求的实例发回一条消息,授予它对这个数据块的共享锁。发出请求的实例随后从磁盘中读取块。这一事件不代表任何争用。

如果这个等待事件出现在“前5个最耗时的事件”列表中,那么表明这个实例在获取锁时花费大量事件。下面给出应当采取的操作列表:
对SQL进行调优,以优化这个应用程序访问的块数,从而减少它请求的块数。

3面向争用的等待

面向争用的等待事件统计信息表明所接收的块是由另一个节点上的会话固定的,由于还没有向磁盘刷新某一修改,因此该数据库被延迟,或者因为高度并发而被延迟。从而可能无法立即交付。这种等待事件通常在对索引块执行并发DML操作时发生,当索引块在拥有者中保持频繁状态时,其他实例需要等待当前块添加索引项。在这种情况下,在面向争用的等待gc current block busy后面会跟着gc current split或gc buffer busy事件。
如果一个会话已经启动了一个“缓存融合”操作并等待这一操作的完成,而同一个节点上的另一个会话正在尝试读取和修改同一数据,那么一个缓冲区可能会是本地频繁的。在Oracle 11g中可能发生这种等待,例如前台进程正在等待反对锁广播更新主读(read-mostly)对象。
如果在全局缓存中交换数据块所花费的服务时间过长,那么可能使争用进一步加剧。
下面是最常见面向争用的等待:
1 gc current block busy
2 gc cr block busy
3 gc buffer busy acquire/release
等待事件block busy意味着“某一个”会话请求访问一个特定的数据库,而这个数据块在一个远程节点上(因为前面给出的各种原因)被认为处于“繁忙”状态。“缓冲区忙”意味着“多个”会话正在等待一个远程节点上的“繁忙”的数据块。换句话说,“缓冲区忙”的情景涉及多个因为同一数据块而导致争用的会话,所需要的调优方法类似于处理“buffer busy waits”或“read by other sessions”事件,只不过是在Oracle RAC环境中进行处理。

1 gc current block busy

当一个请求需要当前模式的数据块时,它向主控实例发送一条请求。这个请求最终通过缓存融合传送获得数据块:但是,由于以下原因之一会使数据块传递延迟:
(1) 这个块正被另一个实例上的会话使用。
(2) 由于拥有这个数据块的实例不能马上将相应的重做记录写到联机重做日志中,因此数据块传递被延迟。
我们可以使用会话级别的动态性能视图v$session 和 v$session_event 来查找导致这一事件最长等待时间的程序和会话:
Selecte.sid,e.time_waited,s.program,s.module
fromv$session_event e,v$session s
Wheres.sid =e.sid
ande.event ='gc current block busy'
orderbye.time_waited;

Selectst.sid,st.value,s.program,s.module
fromv$sesstat st,v$session s,v$statname n
wheres.sid =st.sid
andst.statistic# =n.statistic#
andn.name ='gc CPU used by this session'
orderbyst.value;
在解读这个查询结果时,一定要多加小心,因为一个会话运行的时间越长,总等待时间和统计信息的值越大。为了消除这个谬误,应当将这个查询运行多次,间隔几秒运行一次,并对比其差值( 也就是说,不要对比绝对值 ) 。在确认了一些可能导致性能问题的会话之后,应当将分析的重点放在这些会话的所有等待事件和统计信息上。
这个事件表明存在严重的写/ 写争用。如果这个事件出现在 AWR 前 5 个最耗时事件列表中,那么进行如下操作:
确保对日志写入进程LGWR 进行了调优。
利用适当的应用程序 分区来避免争用。

2 gc cr block busy

这个事件与gc current block busy事件相同,只是在这种情况下,发出请求的事件已经请求CR模式的块。

3 gc buffer busy acquire/release

11g开始将gc buffer busy分为gc buffer busy acquire和gc buffer busy release:
https://blog.csdn.net/stevendbaguo/article/details/46323279
gc buffer busy acquire是当session#1尝试请求访问远程实例(remote instance) buffer,但是在session#1之前已经有相同实例上另外一个session#2请求访问了相同的buffer,并且没有完成,那么session#1等待gc buffer busy acquire。
gc buffer busy release是在session#1之前已经有远程实例的session#2请求访问了相同的buffer,并且没有完成,那么session#1等待gc buffer busy release。
原因/解决方法

- 热点块(hot block)
在AWR中Segments by Global Cache Buffer Busy 记录了访问频繁的gc buffer.
解决方法可以根据热点块的类型采取不同的解决方法,比如采取分区表,分区索引,反向index等等。这点与单机数据库中的buffer busy waits类似。
- 低效SQL语句
低效SQL语句会导致不必要的buffer被请求访问,增加了buffer busy的机会。在AWR中可以找到TOP SQL。解决方法可以优化SQL语句减少buffer访问。这点与单机数据库中的buffer busy waits类似。
- 数据交叉访问
RAC数据库,同一数据在不同数据库实例上被请求访问。
如果应用程序可以实现,那么我们建议不同的应用功能/模块数据分布在不同的数据库实例上被访问,避免同一数据被多个实例交叉访问,可以减少buffer的争用,避免gc等待。
- Oracle bug
建议安装Oracle推荐的最新Patch Set和PSU。
Patch set和PSU信息请参考:Oracle Recommended Patches -- Oracle Database (Doc ID 756671.1)

4面向负载的等待

面向负载的等待事件表明已经在GCS中发生了处理延迟,它通常是由于负载过高、CPU饱和导致的,必须通过添加CPU、负载均衡或者在不同时间进行卸载处理或转移到新集群节点等方法加以解决。对于新提及的事件,等待时间包括从会话在发出块请求后开始等待的时候算起。直到数据块到达时刻所经历的整个往返时间。
无论是块传输请求,还是消息传输请求,只要它在进程间通信(IPC)层之后的内部队列中的等待时间超过一毫秒,就认为这个系统“过载”。这一现象的典型发生情景是:一个LMS进程无法跟上到达速度,从而使消息排队等待LMS处理。
在一个良好负载均衡的集群环境中,应当很少看到拥塞等待。下面是最常见的面向负载的等待,这些等待的存在意味着系统过载或者能力不足:
1 gc current block congested
2 gc cr block congested
3 gc current grant congested
4 gc cr grant congested

1 gc current block congested

当一个实例需要当前模式的块时,它向主控实例发生请求。请求者通过缓存融合获得该块;但是,由于“集群组服务”(GCS)的工作量过重而使块传递过延迟。与我们前面看到的一样,如果IPC队列中的任何消息传输或块传输在被LMS进程选的等待时间超过1毫秒,就会看到拥塞等待。
这一事件并不意味着在块级别存在任何并发或争用。但是,它的确表明GCS的负载过多,参与其工作的后台进程需要更多的CPU时间,如果拥有块的实例上缺少CPU资源,那么可能会导致这一问题。添加更多的LMS进程有时也可以帮助克服这一情景。

2 gc cr block congested

这个事件和gc current block congested事件相同,但在这种情况下,发出请求的实例已经请求了CR模式的块。

Wait events for Oracle RAC include the following categories:

Block-Related Wait Events

Message-Related Wait Events

Contention-Related Wait Events

Load-Related Wait Events

Block-Related Wait Events

The main wait events forblock-related waits are:
1 gc current block 2-way
2 gc current block 3-way
3 gc cr block 2-way
4 gc cr block 3-way
The block-related wait event statistics indicate that a block was received as either the result of a 2-way or a 3-way message, that is, the block was sent from either the resource master requiring 1 message and 1 transfer, or was forwarded to a third node from which it was sent, requiring 2 messages and 1 block transfer.

Message-Related Wait Events

The main wait events formessage-related waits are:
1 gc current grant 2-way
2 gc cr grant 2-way
The message-related wait event statistics indicate that no block was received because it was not cached in any instance. Instead a global grant was given, enabling the requesting instance to read the block from disk or modify it.
If the time consumed by these events is high, then it may be assumed that the frequently used SQL causes a lot of disk I/O (in the event of thecr grant) or that the workload inserts a lot of data and needs to find and format new blocks frequently (in the event of the current grant).

Contention-Related Wait Events

The main wait events forcontention-related waits are:
1 gc current block busy
2 gc cr block busy
3 gc buffer busy acquire/release
The contention-related wait event statistics indicate that a block was received which was pinned by a session on another node, was deferred because a change had not yet been flushed to disk or because of high concurrency, and therefore could not be shipped immediately. A buffer may also be busy locally when a session has already initiated a cache fusion operation and is waiting for its completion when another session on the same node is trying to read or modify the same data. High service times for blocks exchanged in the global cache may exacerbate the contention, which can be caused by frequent concurrent read and write accesses to the same data.
Thegc current block busyandgc cr block busywait events indicate that the local instance that is making the request did not immediately receive a current or consistent read block. The term busyin these events' names indicates that the sending of the block was delayed on a remote instance. For example, a block cannot be shipped immediately if Oracle Database has not yet written the redo for the block's changes to a log file.
In comparison toblock busywait events, agc buffer busyevent indicates that Oracle Database cannot immediately grant access to data that is stored in the local buffer cache. This is because a global operation on the buffer is pending and the operation has not yet completed. In other words, the buffer is busy and all other processes that are attempting to access the local buffer must wait to complete.
The existence ofgc buffer busyevents also means that there is block contention that is resulting in multiple requests for access to the local block. Oracle Database must queue these requests. The length of time that Oracle Database needs to process the queue depends on the remaining service time for the block. The service time is affected by the processing time that any network latency adds, the processing time on the remote and local instances, and the length of the wait queue.
The average wait time and the total wait time should be considered when being alerted to performance issues where these particular waits have a high impact. Usually, either interconnect or load issues or SQL execution against a large shared working set can be found to be the root cause.

Load-Related Wait Events

The main wait events forload-related waits are:
1 gc current block congested
2 gc cr block congested
The load-related wait events indicate that a delay in processing has occurred in the GCS, which is usually caused by high load, CPU saturation and would have to be solved by additional CPUs, load-balancing, off loading processing to different times or a new cluster node.For the events mentioned, the wait time encompasses the entire round trip from the time a session starts to wait after initiating a block request until the block arrives.

文章来源:chenoracle

最后修改:2022 年 02 月 27 日
如果觉得我的文章对你有用,请随意赞赏