Oracle Buffer-cache (数据高速缓存)作用概述

旧城等待， 2022-03-19 13:12 430阅读 0赞

这篇文章是参考甲骨论老相老师所做的教学视频所做的学习笔记.  
http://v.youku.com/v\_show/id\_XMzkyMTk3ODM2.html  
  
  
  
首先简单说明一下Oracle数据库的结构.  
  
**1. 数据库的作用:**  
1.存储数据  
2.方便地检索和处理数据.  
  
**2.Oracle的简单结构**  
1.存储数据( **Oracle 文件**)  
2.方便地检索和处理数据. ( **Oracle 实例**)  
  
可见对于Oracle数据库来讲, 数据都是存放在Oracle文件中的.  
而前面章节也提到过,  Oracle文件分3大类,  控制文件/ **数据文件**/ 重做日志文件 --> 归档日志文件  
实际上数据库所有数据都存放在数据文件中的,   重做日志文件只不过是记录了 **数据文件的数据变化**,而不是数据文件的一份copy.  
  
  
**3. 数据文件的3层结构(block, extend, segment)**  
详细可以参考我翻译的官方文档啦:  
http://nvd11.blog.163.com/blog/static/200018312201282354948602/  
  
下面是简单介绍:  
     Oracle 的数据文件在物理上可以分3层结构,就是块(block)/区(extend)/段(segment) 啦.  
 其中最基本的单位是block  
 而extend是由一段 **物理上连续的block**组成的单位.  
 segment是由若干个extend(无需物理连续)的extend组成的.  
  
大概结构如下图:

![Oracle Buffer-cache (数据高速缓存)作用概述 - 饥民 - 饥民2011][Oracle Buffer-cache _ - _ - _2011]

如上图,可以看出一个表空间内有两个数据文件, 里面3个extends组成1个数据段  
仔细观察可以分析出:  
  
\* **1个表空间可以有多个数据文件. 但1个数据文件只能存在于1个表空间内(不能跨表空间)**  
\* 在1个表空间内每个block的 **大小是相同**的  
\* 每个extend 都是由连续的blocks组成,  **所以1个extend只能在1个数据文件中**(不同数据文件中的block肯定不连续的啦).  
\* 1个segment 由若干个extends组成, 这些extends不必物理连续, 所以 **segment可以跨数据文件保存.**  
\* 1个segment只能存放在1个表空间内 , **不能跨表空间**  
  
**一般来讲, 一个segment就用来存放1张表或索引的数据,  如果这个segment是存放表的就叫数据段, 如果是存放索引的就叫索引段.**  
  
Oracle 1个segment只能存放在1个表空间内 ,是不是代表1张表不能跨表空间存放数据呢.  
  
**大部分表都是存放在1个表空间内的,但是有例外, 这就是分区表**.  
  
有些表由于数据量实在过大,   可以根据一些规则(如地区), 分开存放在若干个表空间, **每个表空间中有1个(只能有1个)**segment内存放这个分区表的数据. 这样的话 检索1个地区的数据就只访问1个表空间内的数据文件就ok了.  
  
也就是说 **分区表可以又多个segments组成,  但是每1个segment都存放在不同的表空间中.**  
  
如下图啦:

![Oracle Buffer-cache (数据高速缓存)作用概述 - 饥民 - 饥民2011][Oracle Buffer-cache _ - _ - _2011 1]  
  
**4,段区块的分配**

**    ** 当user建立一张表, Oracle就会为这种表分配1个数据段, 同时分配1个extend,     这张表的数据就存放在这个extend的blocks中,  当其blocks用完时,  Oracle会重新1个extend到这个数据段,  而不会单独第分配个1个block.  
  
**5.Block是Oracle最少的磁盘IO单位**  
一般来讲, Oracle block 大小是8k, 也可设成12k, 16k等....  
可以用show parameter block; 来查看当前数据库的Blocksize.

![Oracle Buffer-cache (数据高速缓存)作用概述 - 饥民 - 饥民2011][Oracle Buffer-cache _ - _ - _2011 2]  
  
也就是说Oracle dbf被分成了很多个大小为8k的小块  
而Block是Oracle最小的磁盘IO单位.  
  
点讲咧~  
  
       其实我们知道oracle是将数据存放在block中的, 一般情况下, 1个block能存储对应表的多个数据行.  而不会将1个数据行分开存放到多个blocks中, 除非这个数据行是在太大(行链接), 或者其他原因(行迁移)  
  
        假如这个时用户要访问这张表1条数据行的数据,  而且提交了sql语句, Oracle经过计算,  算出了这个数据行存放在哪个block中, **虽然这个block存放了多个数据行.  但是Oracle并不会只访问这1条数据行的数据, 而是将整1个block从dbf文件中读取到Data buffer cache中.**

![Oracle Buffer-cache (数据高速缓存)作用概述 - 饥民 - 饥民2011][Oracle Buffer-cache _ - _ - _2011 3]

如上图,  即使这个block有多个数据行的数据, 但是为了读取其中1行, oracle都会将整个block的数据读入db buffer cache.  
然后server process 会在database buffer cache的这个block的数据里提取出用户想要的数据行, 并将其发送给用户.  
  
实际上, 当用户修改了这个数据行, Oralce也会把缓存中整个block的数据一次写入回DBF文件  
  
所以讲block是oracle的最小磁盘IO单位.  
  
**6. 同样地, 对应dbf文件. sga里的 database buffer cache也被划分成许多个小块.**  
       可以理解,在sga中, Database buffer cache就是用来专门用来缓存dbf文件的数据的,  而dbf文件是1个1个block(最小IO单位)地被读取入database buffer cache里的, 所以 database buffer cache也会被画成对应的许多个小块, 只不过这些块在database buffer cache被称为 **buffer**, buffer的大小与block是一致的.  
  
  
**7. dababase buffer cache 的意义.**  
     其实意义有两个  
      1. 减少物理IO        
      2. 构造CR块  
  
**7. 1 减少IO**  
        
      假如用户要检索一张表的第11条数据行, 那么Oracle经过计算后, 第11条数据行在某个block中, 那么Oracle会执行如下动作.  
  
1. Oracle计算这条数据行在对应表数据段的哪1个block中.  
2. 在内存(database buffer cache)里找, 看看有没有与那个block对应的buffer.  
3. database buffer cache中没有, 则Orocle会向操作系统发送1个物理IO请求.( **没有命中**)  
4. IO请求被发送到磁盘中,  Oracle会读取dbf文件中读取这个block, 放入db buffer cache中, 形成了与这个block对应的buffer( **物理读**)  
5. Oracle在database buffer cache中读取这个buffer的对应行,并返回给用户.( **逻辑读**)  
  
可以见到这个过程中发生了1次物理IO  
  
        这时,用户又想查看第12行, Oracle经过计算, 也算出了具体哪个block..

1. Oracle计算这条数据行在对应表数据段的哪1个block中.  
2. 在内存(database buffer cache)里找, 看看有没有与那个block对应的buffer.  
3. 这次找到了(11行和12行再同1个block中)( **命中了**),  读取这个buffer的对应行,并返回给用户.( **逻辑读**)  
  
可见第二次读取时, **避免了物理读.  
  
  
7. 2 构造CR(consistent read)块**  
  
这个跟事务有关了.  
  
假如一张表T1 , 里面有两行数据,  这两行数据都存放在1个block中.  
这时 有1个session 1 来访问这张表的所有数据(select \* from T1), 那么Oracle就会将这个block数据提取到database buffer cache中,形成1个buffer, 对应 session1 的 Server Process A就可以从这个buffer 中访问表T1的数据了.  
  
同时, 又有另1个session 2执行同样的语句(select \* from T2), 那么server process B就可直接在database buffer cache 找到这个buffer, 这样与session 1一样,  server processB 也可以访问这个buffer 找到T1的数据.  
  
如下图:

![Oracle Buffer-cache (数据高速缓存)作用概述 - 饥民 - 饥民2011][Oracle Buffer-cache _ - _ - _2011 4]  
  
  
          好了,  如果这时, session 1把 T1表其中的一行删除了, 那么对应buffer的row1数据就清除掉, 但是session 1并没有提交, 所以这个buffer就成了脏数据( **严格来讲, 即使session 1提交了, 但是DBWR未写回数据文件, 这个buffer还是脏的,只有与数据文件数据1至才是干净的**).

根据事务的原则,  session2 再去查看这张表是, 还是 会见到row1 在表T1中的, 因为session 1并没有提交嘛,  所以session 2不不能去访问这个被session 1修改后的buffer了.  
  
如图

![Oracle Buffer-cache (数据高速缓存)作用概述 - 饥民 - 饥民2011][Oracle Buffer-cache _ - _ - _2011 5]  
  
           那么session2 是否会再一次从数据文件中把对应block数据放入database buffer cache中呢(物理读)?  
            
           1.不是这样的, 因为session1 修改了数据的同时(删除row1), 虽然并没有commit,但是会产生undo log(撤销日志). **注意不是redo log(重做日志), 当commit之后就会产生redo log.  
 **  
           2. 这时session去检索这个buffer时, 发现数据已经被更改.  就会在database buffer cache申请多1个block size的空间, 并将被修改后buffer的数据copy一份放入这个新的buffer中.  
  
          3. 但是这个新的buffer数据还是跟旧的一样啊, 也就是脏的啊, 所以session2 会从undo log中找回对应删除row 1的数据, 将这个新buff回滚到初始状态, 这样session2 就能读取这个新buffer了, **而这个新的buffer 就是CR 块了(** **consistent read block)**. 而且避免了物理读.  
  
          如下图:

![Oracle Buffer-cache (数据高速缓存)作用概述 - 饥民 - 饥民2011][Oracle Buffer-cache _ - _ - _2011 6]  
  
    **      其实我们在这个流程中发现 undo log有两个作用, 第一就是帮助 session2 构造CR 块, 提高数据库并发性.  
         第二个作用也明显, 当session1 后悔了, 不想提交这个改动, rollback的时候就会通过undo log把数据修改撤销回到那个脏的buffer里啦.**

[Oracle Buffer-cache _ - _ - _2011]: http://img8.ph.126.net/J_fQsucuqQ54Gbz91kzDWw==/6597560148842961988.jpg
[Oracle Buffer-cache _ - _ - _2011 1]: http://img7.ph.126.net/ZpiRBWSkdsXIcKiYnuye7Q==/6597266579239674757.jpg
[Oracle Buffer-cache _ - _ - _2011 2]: http://img7.ph.126.net/fvpwfHr9M5yXfIV4jckzwQ==/672725194356300957.jpg
[Oracle Buffer-cache _ - _ - _2011 3]: http://img6.ph.126.net/WO6DrLH1Afs3onrVFq29Xg==/6597484282540434646.jpg
[Oracle Buffer-cache _ - _ - _2011 4]: http://img1.ph.126.net/86s-M_ab6C_j8Xzx8j9ydg==/6598141790493860041.jpg
[Oracle Buffer-cache _ - _ - _2011 5]: http://img9.ph.126.net/QsQWMQysf69bq5_oWNBk2g==/6597636015145295719.jpg
[Oracle Buffer-cache _ - _ - _2011 6]: http://img2.ph.126.net/J2KTZP1Yyk3wCoic6U-n9w==/6597741568261561852.jpg