DB 与OS 之间，设计思想异曲同工，理解了，也不那么神秘了。

 

os 和 oracle 都一样，在空间和时间的资源消耗中寻找平衡。试图去理解 设计者的意图，是很重要的学习方法。

比如10G 的 flashback database ，为什么推出这个功能，是为了节约恢复时间，那么他的代价是什么，就是增加了 磁盘消耗来记录变化的 block ，这样就用增加 IO 和存储的代价（包括数据库运行是消耗的cpu时间）来节约了恢复时候的时间和资源。随着硬件性能和容量的不断提升，思想已经转变，把 正常运行中可以拿出来的资源(对于10年前的oracle来说 内存、磁盘、 cpu 都是需要尽量节约的)来弥补恢复时间太长的不足。

IXDBA.NET技术社区

下面对比几个方面：

oracle 的 ASSM 在逻辑上和 文件系统 相似，当然和 linux 下 ext3 思想更相近一些

os 本来是根据 512 bytes block 作为扩展单元以防止碎片节约磁盘，但现在存储的容量的发展早已日新月异，不再需要为几k的空间费劲了，出了ext2/ext3 就是类似oracle 的extent 作为扩展单元，这样更有利于IO。 这方面朝数据库走近了一步。 而oracle由 DMT 走向 LMT 再走向ASSM ,则如果把extent看做block的话，有点类似索引的结构，或者说类似文件系统的 i-node 索引结构。这个可以看作 数据库和os 都朝中间走了一步。

oracle 的 buffer cache 的管理 和 os 共享内存的 管理思想很相似

这个我更倾向于说 LRU / hash table /list 。对于 SUN solaris 来说，use_ism 本质上就是允许多个进程共享页表入口访问page list 以达到并发的目的，跟oracle的 cache buffer chain 类似了。

oracle slaves 就是模拟 AIO

oracle 假如不使用 AIO ，则 dbwr 是 write /wait /write /wait ，下一个写必须等上一个写完成，而io_slaves的作用则是 dbwr 把要写的buffer交给 slaves ，由slaves写完成，那么写还没有完成的时候dbwr可以去做下一步事情，搜集dirty buffer 并提交下一个写请求。而oracle 的 AIO 的概念，就是让 DBWR 可以 write/write/write 不必等上一个写完成就可以提交下一个写请求，达到 并行写的目的以充分利用空闲的硬件资源

 

另外还有一些：

oracle 的 redo log 和 文件系统的log作用类似

oracle的事务和 os 文件系统的事务

oracle DMT 的 数据字典表、LMT 的 bitmap/extent map 和文件系统的 i-node 。 数据库这些空间控制的变化的日志 文件系统的 intent log 。

在内存管理方面，使用 hash table + list

原文讨论可参考：

http://www.itpub.net/showthread.php?threadid=308541