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已经没有这个问题了。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/266799/viewspace-964191/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/266799/viewspace-964191/