ITPub博客

首页 > 数据库 > Oracle > Buffer Busy Waits是怎么产生的?

Buffer Busy Waits是怎么产生的?

原创 Oracle 作者:wei-xh 时间:2018-08-25 18:54:59 0 删除 编辑

哪些场景会产生Buffer Busy Waits

Buffer Busy Waits是Oracle 数据库常见的一个等待,特别是在并发写比较频繁的环境里。作为一个Oracle DBA,如果你从未遇到过Buffer Busy Waits等待,那么你算不上一个真正的Oracle DBA。

产生这个等待的原因是,在内存级别,在同一时刻对同一内存块进行读写产生了争用。这里我以2个进程对数据块的操作为例,归纳出产生Buffer Busy Waits的场景:

  1. 写写,例如一个进程正在对内存块做更改,此时另一个进程也要修改这个内存块

  2. 写读,例如一个进程正在对内存块做更改,另一个进程此时想要读这个内存块。你可能会问,oracle为什么不去copy正在修改的块构造CR块,然后去读构造出的CR块,理由很简单,内存块正在写(变化)的过程中去做copy,是一个不安全的动作。

按照字符的排列组合,还剩”读读“、”读写“两个场景,这两个场景都不会导致产生Buffer Busy Waits(这里很重要的一个假设是2个进程),理由我们后面再给出,这里按住不表。

为什么要设计这个等待

Oracle为什么要设计这个等待,这是个好问题,本篇文章也主要是为了解答这个疑问。

“为什么”要比“是这样做的”的更重要,前者讲的是逻辑和洞见,后者描述的是过程和结果。

回答这个问题之前,首先设计一个场景,“假如没有这个等待,读写数据块是如何进行的”,当然这个场景是设计出来的,其实并不存在。

那我们开始,假设场景是这样子的,我们要对一个数据块做写入操作,遵循如下步骤:

  1. 首先依据数据块地址计算出(Hash算法)该块所在的Hash Bucket。

  2. 根据桶的编号,计算出保护这个桶的CBC Latch,然后申请CBC Latch,查找数据块在不在桶里,这里假设在内存里。

  3. 修改数据块。

  4. 释放CBC Latch。

以上的描述看似是非常通畅,但是存在一个问题,由于CBC Latch的持有是排他的,在持有CBC Latch的情况下,去修改数据块,那么这个Latch的持有时间就会比较长,这个长是相对于Latch的获取和释放这种CPU原子操作的,因此在持有CBC Latch的情况下修改数据块,对于读写频繁的数据库/块(热点块),那么势必会造成CBC Latch的争用,基于Latch的特性(自旋、休眠、再自旋),会造成大量CPU资源的浪费,导致数据库的性能低下。

为了解决这个问题,Oracle设计了Buffer Pin的功能。也就是说,Buffer Pin这个机制存在的价值,是为了降低CBC Latch的争用,节省CPU资源。

引入Buffer Pin后,修改数据块的大致步骤如下:

  1. 首先依据数据块地址计算出(Hash算法)该块所在的Hash Bucket。

  2. 然后申请CBC Latch,查找、定位到数据块

  3. 以X模式获取数据块的Buffer Pin。

  4. 释放CBC Latch

  5. 在Pin的保护下,修改数据块,完成后继续以下步骤

  6. 获得CBC Latch

  7. 释放Buffer Pin

  8. 释放CBC Latch

步骤复杂了许多,CBC Latch获取/释放共发生了两次,工作量似乎整整大了两倍。

可是极大程度降低了CBC latch的争用。 因为持有CBC Latch的时间变得极短。 持有CBC Latch,只是为了在buffer header上增加buffer pin,目的变得单纯和简单。

你可能会说,Oracle这种解决方案就是按了葫芦起了瓢,它只不过是转移了竞争,以前是CBC Latch的争用,现在是Buffer Pin的争用。

这句话并没错。

但是Buffer Pin的争用是不消耗CPU资源的。类似于队列锁的通知机制。而不会像Latch一样去做自旋。

读取数据块增加S模式的Buffer Pin,修改数据块增加X模式的Buffer Pin。S和S模式的Pin是兼容的,可以并发的读取,X和S模式是不兼容的,后来的读取会话需要产生等待。

文章的开头,我们举了2个进程操作同一内存块的例子,这里我们在有了一些知识之后,再做下总结和回顾。

  • 写读,同一个时刻,如果一个进程以X模式持有了数据块的Buffer Pin,另一个进程想以S模式持有,那么就会出现争用,因为道理很简单,X模式的Buffer Pin和S模式的Buffer Pin不兼容。

  • 写写,同理,两个同时欲修改同一个数据块的进程,只有一个进程可以获取X模式Buffer Pin,另一个会话产生Buffer Busy Waits等待。

我们平时经常说读不阻塞写,写不阻塞读,那是在物理的数据块级别,在内存里,在同一时刻对于同一个内存块的写读/写写都是互相阻塞的。

这里接着上面把场景补充完整,“读读”不会产生Buffer Busy Waits等待,因为Pin模式是兼容的。“读写”不会产生Buffer Busy Waits等待,一个进程正在读数据块,此时另一个进程要去写这个数据块,写进程很聪明,它会copy出一个current块出来(之前的块成为CR块),然后在current块上进行写操作,通过这种方式避免了竞争,规避了Buffer Busy Waits的争用。

因为前一个进程是在读取,而不是修改。这个场景下的copy就是安全的。

另外一点,因为读取数据库块需要在Buffer header上增加S模式的Buffer Pin,属于内存的修改操作,因此即使是读取操作,CBC Latch的持有也是排他的,但是这个增加Pin的时间极短,在压力正常的数据库环境中引起CBC Latch大量争用的可能性不大。

当然如果是大量进程对同一内存块频繁读取,就会引起CBC Latch的争用。

一些细节

最后,有必要对一些细节再做些补充:

  • 一旦进程Pin住了一个数据块,不需要立即去UNPin(移除Pin)。ORACLE认为在本次调用后还有可能继续去访问这个数据块,因此直到本次调用结束才会做UNPin操作。

  • Oracle在对唯一索引/undo块/唯一索引的回表/索引root、branch块的设计上,在访问(读取)的时候,获取的是共享的CBC Latch,不需要去对Buffer加Pin,直接在持有共享CBC Latch的情况下读取数据块。这样做的原因是这些类型的块,发生修改的可能性比较小,因此Oracle单独的采用这种机制。因此对于普通数据块的读取都是需要获取2次CBC Latch,而对于这种特殊的数据块,只获取一次共享CBC Latch就可以了。

  • 我们上面所说的情况都是在数据块已经存在在内存里的情况。如果数据块不在内存,有可能会产生Read By Other Session争用等待。

  • 上面描述只符合10G后的版本。在10G前读读也会产生Buffer Busy Waits,10G后把这方面的Buffer Busy Waits归到了Read By Other Session等待里。

总结

本文讲述了Buffer Busy Waits是如何产生的及其机制,但是并没有讲解如何对其进行调优。Buffer Busy Waits等待设计的本质是为了降低CBC Latch的争用。以两个进程操作内存块为例,在“写写”、“写读”场景下会产生Buffer Busy Waits,在“读读”场景下不会产生Buffer Busy Waits等待,在“读/写”场景下,发生写操作的服务器进程会去Copy出一个current块来继续写操作,而不会去等待Buffer Busy Waits。


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

下一篇: 没有了~
请登录后发表评论 登录
全部评论
Oracle ACE组成员,DBGeeK用户组发起人。曾在DTCC、ORACLE技术嘉年华、Gdevops等公开场合做过数据库技术专题分享,2017年应Oracle邀请在世界最大的数据库会议OOW上做技术分享。组织翻译了《拨云见日,解密Oracle ASM内核》一书。

注册时间:2009-07-04

  • 博文量
    422
  • 访问量
    2304857