ITPub博客

首页 > 数据库 > Oracle > Oracle笔记----1 体系架构

Oracle笔记----1 体系架构

原创 Oracle 作者:htyro 时间:2010-06-07 15:25:42 0 删除 编辑
学习Oracle也大半年了,有些知识是反反复复的在看,现在也想把自己的学习过程记录下来也好对不足的地方加以总结。


这个第一帖就从体系架构开始吧:)~

 Oracle的整个体系架构是物理和逻辑两块组成,物理上的是指磁盘上的数据文件,日志文件,控制文件以及物理内存。
逻辑上的是指运行在后台的一组进程。
Oracle的官方资料则是把Oracle分为  Oracle数据库和Oracle实例, 数据库就是指存放在物理磁盘上的数据文件,日志文件和控制文件。   数据库实例则是由一部分共享的内存和一组Oracle的后台进程组成的。数据库实例负责对数据库进行存储,修改。所有的客户端要与数据库进行通信,必须经过数据库实例。

先不谈后台进程,来谈谈内存。 Oracle的内存是由操作系统分配给Oracle的,分为SGA和PGA,其中SGA是系统全局区,只有一个,是共享的,而PGA则是程序全局区,是由许多个小的PGA所组成的,是非共享的,在不同版本的concepts中,还把PGA细分为PGA+UGA,在专有模式下,UGA就在PGA中,而在共享模式下,UGA则是属于SGA。

先来讨论SGA:
SGA一般分为以下几个大的部分:
共享池(shared_pool)-----数据缓冲区(buffer_cache)------重做日志缓冲区(rebo buffer)-------JAVA池(java pool)--------大池(lagre pool)

顾名思义,JAVA池是存放跟JAVA程式有关的一些东西,我们不必去深入研究。
而大池就目前我学到的来说,是会存放RMAN的一些信息,在共享模式下,UGA也会存放在大池中,这个内存还是很重要的。

PGA与UGA的关系有些类似进程与会话的关系,一般情况下是1对1,但也有特殊情况是一个进程对应多个会话。


下面来说下SGA几个比较重要的内存区域:
共享池(shared_pool) :这个区域是用来存放sql语句,执行计划以及数据字典的,当某用户通过客户端进程连接上服务器进程,然后分配到一个PGA后,执行一个SQL语句,首先在PGA中对此SQL语句进行HASH运算,生成一个值,然后通过这个值在共享池的库缓存中申请对应HASH值的bucket的latch,用以查看是否有此语句的执行计划存在,如果有,在该执行计划的句丙上加上一个library cache lock,然后通过句丙所指向的地址找到执行计划,在执行计划所在的内存上加一个library cache pin,用于防止在执行的过程中该执行计划被移出内存了。

当用户在执行一个sql语句时,要进行语法分析,语义分析,其中语法分析是检查sql语句的格式是否正确,语义分析是检查所访问的对象是否存在,或者是否有权限。
语义分析阶段就要借助Oracle的数据字典了,因为数据字典里面存放着各个用户以及各个对象的信息,哪些对象存在,以及相应的权限记录信息都在 Directory 中。在需要的时候,Oracle会先从磁盘中把对应的数据字典读入 Directory cache中,然后再从directory cache中读取相应的数据进行检查。

在进行了语法分析和语义分析之后,Oracle就认为这是一个正确的SQL语句,从而就会对其进行HASH运算,生成一个HASH值,这3步都是在PGA中进行的,通过此HASH值,再去library cache中查找是否有对应的执行计划存在,如果有则直接执行,这个即是软解析。  如果没有该执行计划存在,则此进程会先释放掉library cache latch,来申请shared pool latch 来查找free list,找到一段适合的内存,然后重新申请library cache latch,在此latch所对应的bucket链上生成一个新的节点,该节点指向刚刚所申请的内存,用以存放执行计划。  然后调用CPU在PGA中生成执行计划,再把执行计划从PGA中 COPY到 library cache中, 这个过程即是硬解析。

硬解析会耗费很大的资源,特别在繁忙的数据库中,因为在生成执行计划的过程中,该进程会一直持有library cache latch,这样会造成 latch free的等待时间,而且硬解析还会耗费大量的CPU资源,造成其他的动作变慢,所以一个好的库,尽量减少硬解析的可能,这点可以通过帮定变量以及设置解析的参数来实现。
查看当前数据库中的游标共享模式:
show parameter cursor_sharing
一共有3种:
force: 强制执行方式不同,但是意思相同的语句共享一个执行计划。
similar:在有统计信息的情况下,使用exact模式,没有则使用force模式。
exact:只有完全一致的语句才共用一个执行计划。

Oracle建议采用 similar模式。


说完shared_pool下面来说说buffer_cache。
buffer_cache,顾名思义,是用来存放从数据文件中读入的数据块的,Oracle所有的操作都是在内存中进行的,然后在适当的时候再写入磁盘,因为物理的IO是一个很大的开销相比内存操作,所以当用户需求的数据在内存中找不到时,会由CPU(这里有点模糊,因为写是DBWR进程)读入该数据进内存,当然这个过程也涉及到几个latch的申请和相应的等待时间,我在以后再做详细描述。  反正,现在只需要知道buffer_cache存放的就是数据,其对应物理磁盘上的数据文件中的数据块,在修改一个数据块后,在某个特定的时间段由DBWR进程写入对应的数据块,比如 数据文件号,块号。  数据块是Oracle中最小的数据单位,一个数据块包含一行或多行数据,所以在对某一行数据进行修改的时候,会把这行所在的数据块整个读入内存,加锁进行修改,所以如果单个块出现争用,那么就加大此块的pctfree值,使得一个块里面所存放的行记录减少,从而降低争用的几率:)。
cache里面有两个比较重要的链, LRU 链和dirty 链,buffer_cache中所有的数据块不是在LRU上就是在dirty 上,LRU链用来管理free 内存块,而dirty链则用来管理修改过的脏块,通过这2个链,再结合 cache buffer chain latch,从而形成了cache buffer的管理机制,这个会在latch的笔记中作详细的说明。

最后是关于log buffer.
这部分内存也是至关重要的,用户对数据库的DML,DDL操作都会被记录下来,用于数据库崩溃或者异常关机之后的恢复,而log buffer则对应磁盘上的 log文件,一般由于log文件读写频繁,所以要放在RAW设备中,而且用RAID0的格式。
log buffer写的条件:
1.每3秒
2.达到1M
3. 1/3满
4.  用户commit


以上几个条件任意一种都会发生写操作,由此可见log buffer操作之频繁,所以这部分设备的好坏对于数据库的影响至关重要,切记切记。




好了,以上就是Oracle体系架构中有关Oracle实例的部分了,这个也是Oracle的核心。






































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

上一篇: 没有了~
全部评论

注册时间:2009-07-22

  • 博文量
    12
  • 访问量
    87257