一个internal的问题：Oracle的一个extent中的block在物理存储上是连续的吗？

ytlijiang

为什么扩展成了128,正常不8 吗,

tramplhg

比较难懂，慢慢研究！

tramplhg

biti你真厉害！你平时都看oracle的那些书？

Drewlee

biti_rainy的分析，很客观；其作风让人钦佩。
从反馈的信息上biti_rainy基本上解释了在Windows环境下的Oracle的extent和block的问题；但这不代表其它的环境下的Oracle全部走这条路。

我所指的是Oracle在UNIX和LINUX环境下特有的Raw Device模式，biti_rainy也提到了。这种模式可以不通过File System的管理，而是将Raw Device直接作为Cache对数据库进行IO；即块写。这样的IO方式与Windows的磁盘碎片整理的机制相似。在UNIX和LINUX下的raw disk在条带化后物理上是连续的。所以我认为，在Raw Device模式下的Oracle可以做到extent的block在物理上的连续。


参见：
http://www.ddvip.net/OS/aix/index2/51.htm
http://www.fors.com/orasupp/unix/37914_1.HTM


（抛砖引玉）

alexzeng

最初由 biti_rainy 发布
[B]是该编号附近的在同一个extent内的blocks

SQL> select file_id,extent_id,block_id,blocks from dba_extents where owner='TEST' and segment_name='
T';

   FILE_ID  EXTENT_ID   BLOCK_ID     BLOCKS
---------- ---------- ---------- ----------
         3          0         33          8
         3          1         73          8
         3          2         81          8
         3          3         89          8
         3          4        169          8
         3          5        177          8
         3          6        185          8
         3          7        193          8
         3          8        201          8
         3          9        209          8
         3         10        217          8

   FILE_ID  EXTENT_ID   BLOCK_ID     BLOCKS
---------- ---------- ---------- ----------
         3         11        225          8
         3         12        233          8
         3         13        241          8
         3         14        249          8
         3         15        257          8
         3         16      12169        128
         3         17      12297        128

已选择18行。

SQL> alter session set db_file_multiblock_read_count=20;

会话已更改。
...

PARSING IN CURSOR #1 len=22 dep=0 uid=23 oct=3 lid=23 tim=136872504466 hv=2199322426 ad='7b3e0898'
select count(*) from t
END OF STMT
PARSE #1:c=0,e=1159,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=136872504449
BINDS #1:
EXEC #1:c=0,e=4618,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=136872527767
WAIT #1: nam='SQL*Net message to client' ela= 10 p1=1111838976 p2=1 p3=0
WAIT #1: nam='db file scattered read' ela= 27197 p1=3 p2=36 p3=5
WAIT #1: nam='db file scattered read' ela= 23246 p1=3 p2=73 p3=8
WAIT #1: nam='db file scattered read' ela= 1346 p1=3 p2=82 p3=7
WAIT #1: nam='db file scattered read' ela= 3372 p1=3 p2=89 p3=8
WAIT #1: nam='db file scattered read' ela= 17965 p1=3 p2=170 p3=7
WAIT #1: nam='db file scattered read' ela= 2460 p1=3 p2=177 p3=8
WAIT #1: nam='db file scattered read' ela= 1403 p1=3 p2=186 p3=7
WAIT #1: nam='db file scattered read' ela= 1759 p1=3 p2=193 p3=8
WAIT #1: nam='db file scattered read' ela= 1444 p1=3 p2=202 p3=7
WAIT #1: nam='db file scattered read' ela= 1454 p1=3 p2=209 p3=8
WAIT #1: nam='db file scattered read' ela= 1053 p1=3 p2=218 p3=5


由上面p1  file_id   p2  block_id   p3  blocks 可以看出IO次数和相关blocks

事实上一次IO除了和这个参数有关，还和extent有关，一次IO是不能越过extent的 [/B]

block_id=201为什么没有读取? 全表扫描应该读所有的block啊?

是不是201中没有数据信息, 而是段头信息或者其他?

请大师释疑, 多谢

xpchild

原帖由 limpo 于 2003-12-22 15:56 发表
如果是：
     Oracle是如何做到这一点的，尤其是经过stripe以后的磁盘阵列（如raid0+1,raid1+0)，我感觉不太可能

如果不是：
     那就是说一个extent中的block在物理磁盘上是分散的，这样的话做segment的coalese还有任何意义吗？因为如果Oracle无法得知一个block存放在磁盘的具体位置，他就不可能得知两个extent之间是不是物理上相邻的，这样的话所谓coalese也只是fet$中相邻编号（block#）的extent被coalese，对性能的提高方面也只是加快找到空闲块速度的作用而已，对IO能力实在没什么提高。

   这样的话我是不是可以认为，
   1.所谓的碎片只是fet$,uet$ 表和所谓extent map block中extent map的碎片（在dmt上），而不是物理存储的碎片，只需要加工一下这些表就可以解决碎片问题了，解决了碎片问题也无法提高IO性能。
   
   2.system events中的db file scattered read,db file squenced read都是针对block#来说的，和物理读写的地址无关

   3.对db_file_multiblock_read_count这个参数的含义又模糊了，这里的read_count是指连续读这么多个block#的还是在磁盘连续区域上读这么多个块呢？前者可能还有点意义，后者似乎就是在浪费了。
   
呵呵，就想到这些，欢迎大家讨论！

在tom的书中有一句话说：

      extent是由连续的块所组成的，但这个连续是说相对于文件而言的，即文件内连续，但文件的存储都不保证在物理上是连续的扇区，又何来块是物理上连续的，一个块也是要多个扇区的。