关于 freelist

owen

再添一句：
freelist管理的是HWM以下的used < PCTUSED的block，增加一个freelist肯定要多费些空间，不过应该不是主要问题。所有如果是多CPU系统，对于那些并行访问的表，应该使 freelist ＝cpu个数

Fenng

owen,你说的Freelist=CPu个数,也只是个一般情况吧?,CPU能达到的并行数不是简单的等于CPU数阿

zhoubf725

把freelist设置为2*cpu_count或者并发访问数总是够用的了。

zhoubf725

我见过一种说法
当pctused,pctfree设置有问题的时候（没有考虑记录的平均长度和块尺寸方面的问题）
系统将会在freelist中填入死块  
也就是说没有足够的空间来容纳新的记录块。
导致很明显的运行滞后。

大家可以谈谈如何避免这种情况的发生。

biti_rainy

所有的一切已经解决了

包括oracle的空间管理的时候的算法，也多谢CP提供的支持！

假设 freelists = 10,则实际 还存在一个master freelist,当HWM移动的时候会移动 (10 + 1)*5(or _bump_highwater_mark_count ) 个块，但这些块不是直接挂在  process freelist上,更不是 transection freelist,而是放在master freelist上，这样这些块对于所有transection和 process  freelist 都是可使用的，因为大家都会在 transection freelist找不到的时候自己的process freelist,然后找master freelist的，只是不能找别的process freelist而已。这样就解决了我所有的疑惑

关于楼上说的死块，是这样的：
当oracle在freelist中搜索5（_release_insert_threshold ：default 5）个block当发现每个block都不能装下一个行的时候(因 pctused 过高删除回收等原因)，就直接移动HWm以获取新行，这是合理的。 这样，有可能存在这样的现象，这个所谓的死块，总是大量的影响，会可能很频繁地被这么搜索5次然后扩展HWM,所以我们一定要小心指定pctused.当然pctused本身也可能大量影响IO(假如频繁删除的话)

biti_rainy

THis document helps greatly,
http://support.oracle.co.uk/meta ... &p_id=1029850.6

因为HWM移动后的blocks挂在master freelist上并且所有process freelist 都可以去获取。我想这样的话，所谓freelist会浪费空间的可能性已经微乎其微了，不用考虑了！

5.2.6 (If 2.5 fails) Oracle tries to bump up the HWM. To reduce contention on segment header block, Oracle bumps up the HWM by m blocks at a time. The number m is:    1: if the block does not have to go on free list,    1: if we are on the initial extent (0) and the HWM is <= 4 (small    table)    min (5, unused blocks in the extent): before 7.2    min (5*(NFL+1), unused blocks in the extent): since 7.2.    In the example, we assume HWM is at the end of the extent.

5.2.7 New extent allocation. The new blocks are moved to Master free list. Free block search continues from step 2.4


下面是和CP的探讨：
http://www.*****.org/bin/ut/topi ... p;bpg=1&age=100

http://c n o u g.org/bin/ut/topic_show.cgi?id=367&h=1&bpg=1&age=100

Fenng

那两个文档真是精彩,昨天说了一些废话,今天看了才....明白,

嘿嘿,昨天回家想了很久,Ixora说的有些过于简略了呀

Fenng

最初由 biti_rainy 发布
[B]因为HWM移动后的blocks挂在master freelist上并且所有process freelist 都可以去获取。我想这样的话，所谓freelist会浪费空间的可能性已经微乎其微了，不用考虑了！

你这话我可不赞同,回收到master freelist 上的是process Freelist数变小后的包含在删除的Freelist中的块.Freelist浪费空间的问题不是微乎其微,还有不小.

我看到这样的话,希望不是以偏概全,
From 8.1.6 onwards, it is possible to dynamically add and remove process freelists. When the number of freelists is decreased,the blocks contained on the removed freelist are merged into the master freelist of the segment header or corresponding freelist group. When a new freelist is added, there are initially no blocks associated with it. The number
of freelists you decide to create is normally recommended to be close to the maximum number of concurrent inserts occurring on the segment.

biti_rainy

最初由 Fenng 发布
[B]

你这话我可不赞同,回收到master freelist 上的是process Freelist数变小后的包含在删除的Freelist中的块.Freelist浪费空间的问题不是微乎其微,还有不小.

我看到这样的话,希望不是以偏概全,
From 8.1.6 onwards, it is possible to dynamically add and remove process freelists. When the number of freelists is decreased,the blocks contained on the removed freelist are merged into the master freelist of the segment header or corresponding freelist group. When a new freelist is added, there are initially no blocks associated with it. The number
of freelists you decide to create is normally recommended to be close to the maximum number of concurrent inserts occurring on the segment. [/B]

我还是不赞同你的观点


你引述的这段文字并不能说明任何问题
你这文字只是说明 alter table t storage(freelist n )这样的时候
如果是减少，则可回收
增加，则开始不挂block
这个在  dump  block的测试中很明显
但这不能说明浪费多少空间
每个freelist通常不会多与5个block

关键的问题是每个process  freelist上可能挂多少块？假如不出现 死块 的话，通常不应该超过5块，这个浪费大么？

transection  delete释放的空间先是放在 TX  freelist中，这是根据事务动态产生的，当事务结束后，这些空间会被回收到 master freelist,然后某个事务需要块的时候先搜索 TX,然后是process,最后是master

所以只是同一个进程不能使用两个process  freelist
但事实上，由于master 的存在，而使得空间的浪费问题几乎可以忽略
这个问题在测试中也体现出来了

今天 dump  block做了不少测试
有兴趣你也可以去做

biti_rainy

大家可以去 我上面给出的连接

上面有比较详细的说明
和我和CP的对话讨论