在上大学的时候，学习操作系统感觉特别枯燥，都是些条条框框的知识点，感觉和实际的关联不大。发现越是工作以后，在工作中越想深入了解，发现操作系统越发的重要。像现在的RHCE市场反响不错，如果想深入地学习,就有很多操作系统的知识需要补补。在实践中结合理论还是不错的一种学习方法。自从接触数据库以后，越来越感觉到很多东西其实都是相通的，操作系统中的很多设计思想在数据库中也有借鉴和改进之处。所谓大道至简，其实就是这个道理。
说到存储管理，是操作系统中式最重要的资源之一。因为任何程序和数据等都需要占有一定的存储空间，存储管理会直接影响到系统的性能。
存储器是有主存和外存组成。对于外存，可能覆盖面更广，像硬盘，移动硬盘，光盘，磁带，SSD等等都是外存的覆盖范围。主存大家很熟悉，这些年主存的大小也有了极高的提升，现在的服务器配置中几百G的内存都是很正常的。
-->存储的管理技术
关于存储的管理技术，先讨论以下两个部分。
固定分区
先来点操作系统的知识。
关于固定分区管理技术，就是把主存分为若干个固定大小的存储区，每个分区提供给某一个作用使用，如果作业完成会把相应的存储区归还。
在多道作业系统中，主存中分区的个数是固定不变的，而且每个分区的大小也是固定不变的。如果分区总是大于作业，那么就有很多分区没有充分使用，产生碎片。
来结合数据库来看一看(shared pool中的free list)
在数据库中，shared pool中的free list(bucket)管理和固定分区管理很相似。
shared pool中存储单位是chunk,多个chunk组成一个链表，也叫做bucket.(free list),每个bucket都对chunk的大小都有一定的范围，是一个连续的值，没有交叉。
在10g，11g中都设置了255个bucket。
oracle的trace文件中，每个bucket的大小都是固定的，
ora11g@rac1 trace]$ grep Bucket *18155*.trc
Bucket 0 size=32
Bucket 1 size=40
Bucket 2 size=48
Bucket 3 size=56
。。。
oracle在早期的版本中也碰到了不少的问题，在10g,11g中都对bucket的数目做了提升，而且分区的大小也做了调整。这是一个比较均衡的比例，能够保证每次请求的大小都在bucket的范围之内，尽量提高效率。
回到操作系统中，我们再补充几点。
在存储的管理中，存储的分配和释放都需要根据分区来说明。在固定分区中采用了一个存储分块表(MBT)来维护而存储的区的信息，存储区的信息在操作系统中有一个专有名词叫做数据基，数据基听起来挺抽象，其实理解起来还是蛮简单的。
我们用下面的图标来说明。我们假设下面的这个表格就是存储分块表，其中数据基就包括，存储的分区大小，存储位置还有状态。
| 分区 | 大小 | 存储位置 | 状态 |
| 1 | 8k | xxxxx | used |
| 2 | 8k | xxxxx | free |
| 3 | 16k | xxxxx | used |
| 4 | 16k | xxxxx | free |
| 5 | 16k | xxxxx | used |
| 6 | 32k | xxxxx | used |
猛一看，上面的方式还是比较简单而且可行的。但是还是固定分区的硬伤，主存利用率不高，对于进入主存中的作业大小我们也没法预知，而且对于MBT表的管理冠绝还是不够清晰。如果需要查找哪些分区可用，需要重新分配的时候，就得遍历整个表，遍历了已经使用的分区，这样分配的过程就比较长了。
这个时候可以参考一下
可变分区的多道管理技术
这种技术在一定程度上解决了固定分区带来的问题，可变分区在主存中不会事先创建一个个分区，而是在作业进入主存的时候按照作业大小再来创建分区。
这样的话，分区个数不固定，分区大小不固定，在oracle中也有一些相似之处。
oracle中的deferred_segment_creation
比如说对于分区的不固定，在11g中有一个参数deferred_segment_creation,如果我们设定为true，那么在创建之初是不会分配对应的分区的，直到开始插入数据之后，它才会根据插入的数据来创建分区。
oracle中的interval partitoning(可以参见http://blog.itpub.net/23718752/viewspace-1346319/)
如果根据需要动态的创建分区，而且分区的大小也不固定。
比如在数据库的表空间管理中，我们可以指定分区的。
对于可变分区的数据基管理，是采用了两个存储分区表来管理的，已使用分区表(UBT)和空闲分区表(FBT)，这样就可以减少存储分配和释放的性能。
在这点上,oracle表空间中的数据字典管理方式是一致的。
oracle中是采用FET$, UET$ 两个数据字典表来维护分区的信息的。只是在数据基上会有一定的差别。
FET$和UET$的结构如下
SQL> desc fet$
Name Null? Type
----------------------------------------- -------- ----------------------------
TS# NOT NULL NUMBER
FILE# NOT NULL NUMBER
BLOCK# NOT NULL NUMBER
LENGTH NOT NULL NUMBER
SQL> desc uet$
Name Null? Type
----------------------------------------- -------- ----------------------------
SEGFILE# NOT NULL NUMBER
SEGBLOCK# NOT NULL NUMBER
EXT# NOT NULL NUMBER
TS# NOT NULL NUMBER
FILE# NOT NULL NUMBER
BLOCK# NOT NULL NUMBER
LENGTH NOT NULL NUMBER
这种方式在早期的oracle版本中采用，这种表空间管理方式叫数据字典管理。
但是在orale的不断改进中，发现这种方式还是存在一定的问题，这种方式的资源消耗还是比较高的。对于这两种数据字典表的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就能说明是连续的空闲分区，所以也不需要再合并相邻的可用分区了。
