倾力大奉献——ASSM内部存储研究大揭密

piner

这么说还有点对，但是图还是感觉不该这么画

这里的root就是段头的位图块了，这个树只有三层，代表了位图块的三个级别。
Last Level 1 BMB: 0x06800079
Last Level II BMB: 0x0680000a
Last Level III BMB: 0x00000000
但是，真正的第三层的BMB我还没有实际发现过。可能在update时产生？？？

Fenng

有些类似B-tree索引的结构

估计在设计的时候也是一种折衷的方案吧

细节上我很少研究的.呵呵

BruDog

够强，我还看不太懂，oracle被你们研究到这个程度，也算无撼了，呵呵。

biti_rainy

不过粗略的感觉，就是unix file system 的结构原理  

eygle

这实际上是DSI402中的内容
根据Segment Header的结构，Oralce把BMB又分为L1,L2,L3三个级别！

piner

DSI402也是ORACLE官方文档吗？
我怎么没有见？
文档有这么详细？我看不可能吧！

google

每个块有多少剩余空间根据位图的状态来确定，如>75%,50%-75%,25%-50%和<25%，也就是说位图其实采用了四个状态位来代替以前的pctused

问题1
4个状态起码要用两个BIT来做定义吗？那就是两个BIT定义一个BLOCK？这样说来就算整个SEGMENT有10万个BLOCK=80万K＝800M，那么按道理BITMAP BLOCK只需要2BITx10万=25kbyte只要4个BLOCK就行了，为什么你说每个BITMAP BLOCK只能定义下16个BLOCK的剩余空间呢？
能否画个详细的图进行说明？最后那位大侠说的图看不到了

问题2
ASSM号称对FREELIST竞争做了修改，但是从程序员的角度看：
对于从同一个BITMAP BLOCK里面获取FREE BLOCK的进程来说，他们之间仍然会需要排斥锁来获取和修改一个BIT，请问ORACLE对于这种锁的机制是怎样实现的？还是说每个进程独占某个BITMAP BLOCK？

biti_rainy

最初由 google 发布
[B]每个块有多少剩余空间根据位图的状态来确定，如>75%,50%-75%,25%-50%和<25%，也就是说位图其实采用了四个状态位来代替以前的pctused

问题2
ASSM号称对FREELIST竞争做了修改，但是从程序员的角度看：
对于从同一个BITMAP BLOCK里面获取FREE BLOCK的进程来说，他们之间仍然会需要排斥锁来获取和修改一个BIT，请问ORACLE对于这种锁的机制是怎样实现的？还是说每个进程独占某个BITMAP BLOCK？ [/B]

assm 中  freelist  的功能被分散到多个 block中去了，甚至很多block中去了  。
以前freelist的header都是存放在segment header 中的 （freelist group > 1 也不过是一组freelist放一个block而已）

另： bitmap 的修改 比 freelist header 的修改速度快的多，不存在 锁 的问题，而是仅仅可能少量block存在着 cache  buffer chain 的竞争  和  buffer   pin 的竞争，这些都是 latch 一级而不是 lock 一级。


另：  和你第一个问题相关，若过多的block的剩余空间信息存储在同一个bitmap  block中，则可能导致 cache  buffer  chain  / buffer  pin 等过度的latch的竞争从而导致和 freelist 一样的效果 。

我没确认是不是 一个 bitmap  任何情况下始终只保存 16个block的空间状态信息，bitmap也是一个树状的分级结构，是不是所有接点都这样没研究过，即使真的如此。 1/16 的空间，也不是什么太大的问题。

piner

补充一下，
一个bitmap不一定是管理16个block的空间状态信息，表的前部分与后部分甚至都不一样，不过这个不是重要的东西

重要的东西是很多分布的bitmap在表中，已经不是以前的1个甚至几个freelist

Fenng

奇怪,刚才这个帖子做操作居然不可以

现在又行了