DB_FILE_MULTIBLOCK_READ_COUNT指的是在顺序扫描过程中一次I/O操作所读取的最大块数。

今天在书中读到一段：

Larger extents can have a small performance benefit because the Oracle server can read
one large extent from disk with fewer multi-block reads than would be required to read
many small extents. To avoid partial multi-block reads, set the extent size to a multiple
of 5 × DB_FILE_MULTIBLOCK_READ_COUNT. Multiply by five because the Oracle
server tries to allocate extents on five-block boundaries.

开始时有点疑惑，来回多读了两次后有点感悟，但对five-block boundaries的意思不是特别理解，凭感觉认为是“以5个块为单位进行分配”的意思，在BLOG群上搜索了一番，找到了biti_rainy大师的一段解释，更觉得清晰了很多，内容如下：

The High-Water Mark Incremented in five-block increments as rows are inserted

是说当 HWM 在 segment 中移动的时候，开始3(or 5)次移动，每次只移动1个block，之后开始移动如果不设置下面这个参数则默认是5 blocks
alibaba@OCN>select KSPPINM ,indx from x$ksppi where ksppinm like '%bump%';
_bump_highwater_mark_count 429
alibaba@OCN>select KSPPSTVL from x$ksppsv where indx = 429;
0

至于oracle 提到要以 5 作为倍数
Multiply by five because the Oracle server tries to allocate extents on

five-block boundaries
可能是oracle在分配 extent的时候，是以5blocks为单位去为extent 分配空间的，分配一个extent包含10个block可能是在文件上进行2次空间操作，而6个block的extent也是进行2次空间操作。我估计是表达这个含义。

实际上，只要 extent大小足够大，达到 os max io size 的，这些细微的东西，早已经不是性能影响的重要因素，完全可以忽略，尤其在现在空间管理方式和算法已经大幅度改进的情况下。

关于 extent 大小的问题主要体现在dmt 中extent 数量过多导致 ust$ /fet$ 数据量过大的问题，而 lmt已经没有这个问题了。

[@more@]