ITPub博客

首页 > 数据库 > Oracle > Oracle数据库技术实用详解学习笔记:Buffer Cache

Oracle数据库技术实用详解学习笔记:Buffer Cache

原创 Oracle 作者:gulunhua 时间:2016-01-25 18:34:30 0 删除 编辑

 

Oracle之所以需要buffer cache,主要有下面3个原因:

a、访问内存的效率远高于从磁盘读取数据的效率,通过缓存数据,减少IO。

b、多进程能共享这些数据,当然,为了保证数据的一致性,需要通过lock、latch机制。

c、通过构造CR 一致性读块,从而提供读一致性功能。

 

下面举个例子说明:

客户端1发送一个sql语句,那么执行语句时,需要从磁盘读取数据放到内存,用完后就把内存中的数据清理掉了,根本不缓存在内存,那么当下次运行相似的语句,也需要访问这些数据时,还得再次从磁盘里读取数据到内存,再进行其他的计算。显然,如果能把这些数据缓存在内存中,那么就不必每次都从缓慢的磁盘中访问数据了,效率大大提高。

如果这时客户端2也发出一个sql语句,那么执行语句时也需要从磁盘读取数据到内存,这些数据被缓存在内存中,过一会又执行相似的语句,就可以很快的访问内存中的数据,但有个问题是,它只能访问自己的内存区域,而不能访问其他服务器进程的私有内存区域,那么怎么办呢?

这时就把这些每个服务器进程都需要共享的内存区域抽取出来,构成一个内存区域,就是buffer cache,当然有些独立于每个服务器进程的信息,还是继续放到每个服务器进程自己私有的内存区域,也就是PGA。这样一来,所有服务器进程在访问数据时,首先要做的就是看看buffer cache里有没有想要的数据,因为虽然它自己没有把需要的数据从硬盘读取到内存,但说不定有其他的服务器进程已经把数据读到内存里了呀,呵呵,运气好的时候,数据已经在内存,于是直接用这些数据就好了。

 

当然啦,虽然可以共享数据,但需要一个内存结构来存储这些数据,同时也需要一个算法来管理这些数据。

 

1、buffer cache的内存结构

buffer cache就像一个水池,水池的最小单位是数据块,当每个数据块被读入到buffer cache时,oracle都会在内存中构建buffer header,并将这些buffer header串联为链表,每个buffer header里的指针指向了所对应的数据块。

在管理buffer header时,oracle用hash算法,把buffer header里记录的数据块地址和数据类型,做为hash函数的参数,得到数据块所属数组号。

把属于同一个hash bucket的所有数据块的buffer header串联起来,构成hash chain,每个hash bucket 都是通过不同的hash chain来体现的。当有多个进程并发访问一个hash chain时,必须要持有cache buffers chain latch。

 

启动数据库后,由oracle自己计算,需要多少个hash bucket。

当执行sql语句时,获取数据块的大致过程:

客户端进程发出select或其他dml语句,oralce会根据sql语句的执行计划,找到符合条件的数据块,然后把请求的数据块地址、数据块的类型做为hash函数的参数,取得数据块所在的hash bucket号,然后进入这个hash chain,从链表上第一个buffer header开始,根据buffer header中记录的指针,找到数据块,然后扫描其中的数据以确认是否是sql语句所需要的块,如果是,则返回块所需的数据;如果不是,则继续往下搜索,一直搜索到最后一个buffer header为止。如果没找到,则调用IO,从数据文件中把该块复制一份到一个可用的buffer里,并构建相应的buffer header,然后把这个buffer cache挂到hash chain上去。

 

上述只是大概的过程,并不准确,只是希望更易于理解,比如,关于如何根据执行计划,找到符合条件的数据块,并没有描述。

实际的情况,肯定是极其复杂的。

 

2、buffer cache 的管理机制

上面讲到的,获取数据块的过程中,如果没找到后,需要调用IO,从磁盘拷贝一个块到可用的buffer,如果有可用的内存空间,当然就没问题,如果找了一段时间,还是没有可用的块,那该怎么办呢?

这里首先需要知道在buffer cache中,有2个list,一个是LRU list,一个是Write list。

LRU list中的数据块分为如下几类:

a、干净的数据块:buffer cache中为空的内存数据块。

b、空闲数据块:buffer cache中没有修改过的数据块。

c、钉住的数据块:buffer cache 中当前正在使用的数据块。

d、脏数据库:buffer cache中已经被修改过的数据块。

 

LRU list中存放了空闲数据块、干净数据块、钉住的数据块,还没有移入write list的脏块。空闲数据块和干净数据块,是可用块。buffer是按照被使用的先后顺序挂到LRU链表上,当某个服务器进程访问一块缓冲区时,就会将其移动到LRU 列表的最近使用(most recently used,MRU)端。随着更多被访问的缓冲区移动到 LRU 列表的 MRU 端,较早前被访问过的脏缓冲区就会逐渐向 LRU 列表的 LRU 端移动。

当服务器进程需要把磁盘的数据块复制到内存时,需要空闲的数据块,于是开始搜索LRU链表,LRU list上的数据块都会受到cache buffers lru chain latch的保护:

a、在搜索过程中遇到脏数据块时,会把脏数据块移入write list和checkpoint list,之后继续搜索。

b、如果扫描到的buffer正在被使用,那么跳过。

c、当找到可用的缓冲区时,就将数据块从磁盘写入缓冲区,并将此缓冲区移入LRU list的MRU端。

d、如果扫描了一定数量(40%的LRU list)的buffer后,还是没有找到可用的buffer,说明脏块太多了,于是触发DBWn进程,将脏块刷新到数据文件里,刷新完成后,buffer的内容与数据文件里的一致,这些脏块就变为干净的buffer了,于是乎,服务器进程从磁盘中读取数据块,覆盖这个干净的buffer,然后再把这个块挂到LRU list的MRU端。除此之外,当write list超过阀值,也就是达到25%,那么服务器进程就会通知DBWn去写出脏数据块。

 

除了上面d说提到的条件,会触发DBWn去写出脏数据外:

a、每个3秒钟启动一次DBWn。

b、发出完全检查点、增量检查点时,也会触发DBWn。

 

那么这里的检查点是什么呢?

在oracle 8i之前,完全检查点启动时,会标识出buffer cache中所有的脏数据块,然后以最高级启动DBWn进程将这些脏数据写入数据文件。日志切换也会引起完全检查点。在oracle 8i以后,完全检查点只有在两种情况下才会触发:

a、alter   syste   checkpoint命令

b、除了shutdown  abort之外的正常关闭数据库。

注意,日志切换不会触发完全检查点,而是触发增量检查点,增量检查点的条件:

a、每隔3秒

b、发生日志切换。

 

下面举例说明:

现在有个客户端发了一条update语句,服务器端进程收到语句后开始解析、生成了执行计划,接下来开始执行。首先,需要在buffer cache查找到数据;然后,根据修改操作先生成一条重做记录,包含了3个改动向量:回滚段中段头中的事务表的被改动数据块的地址、事务操作代码、数据块的版本号,回滚段中被修改的块的地址、事务操作码、数据块版本号,表中被修改的块地址、事务操作码、版本号,lgwr会把重做记录写入联机日志文件。然后,服务器进程修改数据,提交事务,但这个脏数据块还没有写入磁盘。

 

需要注意的是在checkpoint list上的buffer header还记录了:脏数据块在第一次修改时,所对应的重做条目,在重做日志文件中的地址,也就是LRBA( Low redo block address)。

 

这时,系统发出了增量检查点,ckpt进程会找出当前检查点队列上的第一个buffer header,并将该buffer header 中所记录的LRBA记录到控制文件中去,如果是增量检查点,则还会将LRBA写到每个数据文件头中

 

然后调用DBWn进程,DBWn也会主动扫描LRU list,将发现的脏块移入write list 和checkpoint list中,这里就会把刚才那个脏块移入write list和checkpoint list,然后把checkpoint list中的脏数据写入文件,每个检查点都会由checkpoint queue latch来保护。

 

此时,刚才的脏数据还没有写入文件时,系统突然断电了,系统重启后,从联机日志文件中读取重做记录,那应该从何处开始重做呢?

这里的关键就是ckpt进程写入控制文件的LRBA,会从这个地址开始应用重做记录就可以了,这样需要把检查点之前的重做日志重做,因为这样是没有必要的,由于这个检查点之间的前面一个检查点已经把脏数据写到磁盘了,所以这部分重做记录就不用再应用了,节省了恢复时间。

 

3、实例恢复原理

当系统突然断电,还没有将buffer cache中的脏数据块写入磁盘,同时正在运行的事务也突然中断,事务为中间状态,也就是既没有提交也没有回滚,这样关闭的数据库不是一致的。

下次启动实例时,oracle会有smon进程自动进行实例的恢复:

a、实例启动时,smon进程回去检查控制文件、每个在线的可读写的数据文件的end scn号。数据库在正常运行时,end scn号为空,因为系统还没有正常关闭,只有在关闭时发生了完全检查点时,才会更新end scn。 由于是系统突然断电,系统没有正常关闭,所以来不及更新end scn,所以end scn为空,smon进程就知道实例上次没有正常关闭,于是smon开始进行实例恢复。

b、smon进程首先会从控制文件获取上次检查点的位置,也就是Lrba Low redo block address,于是,在联机日志文件中找到这个地址,从这个位置开始,应用重做日志条目,从而在buffer cache中又恢复了实例在突然断电时的状态,这个过程就是前滚,这个时候buffer cache里,既有已经提交但还没有写入数据文件的脏数据,也还有事务突然中断,这个事务既没有提交也没有回滚所产生的脏数据。

c、前滚后,smon进程立即打开数据库。但是,这时的数据库中还包含那些中间状态的、既没有提交也没有回滚的脏块,于是smon进程开始在后台进行回滚。

d、这时,客户端发出了读取这些数据的请求,这时服务器进程在将这些数据返回时,会由服务器进程进行回滚,回滚完成后再将数据返回给用户。

 

oracle提供了初始化参数 fast_start_mttr_target让我们指定完成实例恢复所花费的时间,这个时间只包含了前滚并打开数据库的时间,不包含回滚时间,这个参数以秒为单位。在数据库运行时,会根据这个时间来估算,在这个时间内大致产生多少量的重做记录,也就决定了检查点的位置。

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

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

注册时间:2011-08-01

  • 博文量
    41
  • 访问量
    30430