说到存储管理,是操作系统中最重要的资源之一。因为任何程序和数据等都需要占有一定的存储空间,存储管理会直接影响到系统的性能。
存储器是由主存和外存组成。对于外存,可能覆盖面更广,像硬盘,移动硬盘,光盘,磁带,SSD等等都是外存的覆盖范围。主存大家很熟悉,这些年主存的大小也有了极高的提升,现在的服务器配置中几百GB的内存都是很正常的。
关于存储的管理技术,先讨论以下两个部分。
固定分区 先来点操作系统的知识。
关于固定分区管理技术,就是把主存分为若干个固定大小的存储区,每个分区提供给某一个作用使用,如果作业完成会把相应的存储区归还。
在多道作业系统中,主存中分区的个数是固定不变的,而且每个分区的大小也是固定不变的。如果分区总是大于作业,那么就有很多分区没有充分使用,产生碎片。
来结合数据库来看一看(shared pool中的free list)
在数据库中,shared pool中的free list(bucket)管理和固定分区管理很相似。
shared pool中存储单位是chunk,多个chunk组成一个链表,也叫做bucket,每个bucket都对chunk的大小都有一定的范围,是一个连续的值,没有交叉。
在10g,11g中都设置了255个bucket,可以通过trace文件来了解一下。
Bucket 0 size=32
Bucket 1 size=40
Bucket 2 size=48
Bucket 3 size=56
Bucket 4 size=64
Bucket 5 size=72
…
Bucket 250 size=12352
Bucket 251 size=12360
Bucket 252 size=16408
Bucket 253 size=32792
Bucket 254 size=65560
可能对于bucket的大小没有一个直观的感受,可以生成一个图来看看就很清楚了。
随着bucket的增长,对应的chunk大小都在递增,绝大多数的bucket中,chunk的大小都在5k以内。只有很小的一部分bucket的支持的chunk size很大,这个也是Oracle在不断的改进中得到的一个最优值,按照比例来划分,保证每次访问需要的chunk大小都能够合理的分配,尽量减少冗余。
同时不是每个bucket里面都是有chunk的,这个chunk的分配还是根据进入shared pool以后申请chunk大小紧密相关,bucket中的chunk数目可不是平均的。
Oracle在早期的版本中也碰到了不少的问题,在10g,11g中都对bucket的数目做了提升(目前都是255个),而且分区的大小也做了调整。这是一个比较均衡的比例,能够保证每次请求的大小都在bucket的范围之内,尽量提高效率。
回到操作系统中,我们再补充几点。
在存储的管理中,存储的分配和释放都需要根据分区来说明。在固定分区中采用了一个存储分块表(MBT)来维护而存储的区的信息,存储区的信息在操作系统中有一个专有名词叫做数据基,数据基听起来挺抽象,其实理解起来还是蛮简单的。
我们用下面的图标来说明。我们假设下面的这个表格就是存储分块表,其中数据基就包括,存储的分区大小,存储位置还有状态。
猛一看,上面的方式还是比较简单而且可行的。但是还是固定分区的硬伤,主存利用率不高,对于进入主存中的作业大小我们也没法预知,而且对于MBT表的管理感觉还是不够清晰。如果需要查找哪些分区可用,需要重新分配的时候,就得遍历整个表,遍历了已经使用的分区,这样分配的过程就比较长了。
这个时候可以参考一下:
- 可变分区的多道管理技术
这种技术在一定程度上解决了固定分区带来的问题,可变分区在主存中不会事先创建一个个分区,而是在作业进入主存的时候按照作业大小再来创建分区。
这样的话,分区个数不固定,分区大小不固定,在Oracle中也有一些相似之处。
- Oracle中的deferred_segment_creation
比如说对于分区的不固定,在11g中有一个参数deferred_segment_creation,如果我们设定为true,那么在创建之初是不会分配对应的分区的,直到开始插入数据之后,它才会根据插入的数据来创建分区。
- Oracle中的interval partitoning
如果根据需要动态的创建分区,而且分区的大小也不固定。
比如在数据库的表空间管理中,我们可以指定分区的。
对于可变分区的数据基管理,是采用了两个存储分区表来管理的,已使用分区表(UBT)和空闲分区表(FBT),这样就可以减少存储分配和释放的性能。
在这点上,Oracle表空间中的数据字典管理方式是一致的。
Oracle中早期是采用FET$,UET$ 两个数据字典表来维护分区的信息的。只是在数据基上会有一定的差别。
FET$和UET$的结构如下:
这种方式在早期的Oracle版本中采用,这种表空间管理方式叫数据字典管理。
但是在Oracle的不断改进中,发现这种方式还是存在一定的问题,资源消耗还是比较高的。对于这两种数据字典表的DML操作,会产生较多的递归SQL来间接完成对两个数据字典表的更新,在更新的过程中也会存在事务,存在事务也就会产生一定的undo和redo。最后就是对于相邻空闲空间的合并, 在Oracle中是通过SMON进程来实现的。
回到操作系统,操作系统中对于数据基的管理还有一种方式,就是空闲存储链表。
这种方式就是把空闲分区通过链表的形式串起来,形成了一条空闲存储块链。
这种技术在数据库中可有一个很响亮的名字,在buffer cache中叫做LRU链表。
在buffer cache中的实现方式也是类似的。当然在Oracle中会采用其它的算法和策略。Oracle中是把buffer按照被使用的先后顺序挂在LRU链表 上,先被使用的buffer放在了链表的后面,后被使用的buffer挂载LRU链表的前面,如果buffer被修改的时候,buffer就会从LRU链 表上取出。这样始终保持LRU链表中都是可用的数据块。
然后来简单说一下可变分区的存储算法。
目前主要有以下几种:
- 最佳适用算法
这种方式就是从所有未分配的分区中挑选一个最接近于作业尺寸且大于或者等于作业大小的分区分配。 - 最先适应法
按照分区序号从存储分块表中的第一个表目找找,把最先找到且大约等于作业大小的分区分配。 - 最坏适应法
把所有未分配的分区中挑选最大的且大于等于作业大小的分区分配。 - 位图法
把所有的分区使用一个位来表示状态,1表示块已经被使用,0表示分区空闲。
在Oracle中的存储算法可能更接近于最佳适应算法,唯一的不同的是在Oracle中采用了hash来该分配到哪个bucket。但是都会保证分配的空间是大于等于请求的大小。
而位图法在表空间管理中也有相似的使用方式。
表空间的管理有两种方式,数据字典管理和本地管理。
本地管理中会在数据文件的头部采用多个位来存放。这个bitmap类似下面的形式。
11110111001110100…..
1代表分区已被使用,0代表分区还是空闲,当进程需要分区的时候,只要扫描数据文件的头部的bitmap,就可以找到值为0的分区。分配了分区之后把它修 改为1,释放空间就会从1修改为0. 修改数据文件头部的操作速度快且不存在事务,就没有redo,undo,更不会有递归SQL。对于相邻分区的合并来说,两个连续的0就能说明是连续的空闲 分区,所以也不需要再合并相邻的可用分区了。
前面讨论了固定分区和可变分区管理的一些情况,它们的主要缺点就是主存使用的低效率和存储分配释放的低速。固定分区是分区内部的碎片造成主存利用率低,而可变分区是分区外部的碎片,往往小到无法使用,从而主存利用率不高。对于这个问题,分页是一种很有效的方法。
分页技术 分页技术主要是把主存分为许多同样大小的存储块,并以这种存储块作为存储分配单位。Oracle数据库中物理存储单位有段,区,数据块,这个时候所说的数据块和操作系统数据块存在着映射,一般都比操作系统块要大。数据库中默认为8K,数据的存储都是以8K的基本单位来存储的。如果把这一点继续延伸,Oracle中的区(extent)就和分页技术中所说的页很类似。
分页存储中的基本实现过程,有以下几点:
- 把主存分为相同大小的存储块,叫做页架,页架从0开始,编号依次是0,1,2….
- 用户逻辑地址的分页,用户逻辑地址可以划分为和页架大小相同的部分,叫做页。页号从0开始,依次为0,1,2…
- 逻辑地址的表示,既然说到了逻辑地址,表示方法也很重要。每一个逻辑地址都是相对地址,用一个数对(p,d)来表示,p代表页号,d代表逻辑地址在也好为p的页中相对的地址,也叫偏移量。
听起来挺枯燥啊,可以简单举个例子,我们常看的书就是一个很好的例子,书有很多大小,四开,八开,十六开,可以理解为页架,书中的每一页就是我们所说的页,逻辑地址可以这么理解,一本书有很多章节,小结,比如第二章第3页,我们就能够很快找到,这个时候,页号就是2,偏移量就是3,用(p,d)来表示就 是(2,3)
举一个严谨的例子,比如给定一个虚地址3456,假设页面大小为1000B,则第0页对应的地址为0-999,第1页为1000-1999,则虚地址3456=(3,456)
这一点和Oracle中创建表空间时指定的extent management管理方式很相似,比如我们创建一个表空间test指定分区大小为1M,表空间大小为100M,则语句如下:
这样我们指定分区大小为1M,如果存储了100M的数据,这样100M就会分为100个分区。如果数据大于分区1M,则可以存储在相应的分区上,不一定连续。
0M就会分为100个分区。如果数据大于分区1M,则可以存储在相应的分区上,不一定连续。