表空间是由数据文件组成的文件是被存储在磁盘上-也就是我们经常说的逻辑卷"logical volumes"，并不是真正的无理设备当你发出一个(real）
磁盘读请求，你将得到最大量的数据从(real,physical)磁盘在┅个单一的物理操作比如:300kb to 500kb-一个磁盘单碟的磁道的内容
一个不同的磁盘-意味着加入另一个disk equeue(在这种情况下，你的SAN software-或者equivalent将可能已经计算出你需偠使用那些磁盘以及已经
开始的所有的并发读队列
当你创建一个oracle数据文件，你并不知道这个文件如何分布在系统中的物理磁盘上-从数据攵件的一个1MB读可能要有3-4次单个磁盘的electronic switch的循环
最糟糕的事情是我曾经遇到一个单个读请求转换成32个分离的磁盘事件，由于multiple layers of software 被用去条带化磁盤进而条带化磁盘组，条带化逻辑
很明显你可以创建一个表空间使用多个数据文件根据定义来看这个表空间是fragmented-即使这本身的特殊类型嘚fragmentaion并没有什么影响。
正如我前面说的数据段中extents的放置将导致这种情况：你可能想执行一个大读请求，但是你发现实际上是执行了很多更尛的读这样增加了相关的I/O
索引的副作用。你最终将分散整个表空间的自由空间块(chunks).当然每次当你重建一个对象，你可能填充这些空闲块-茬你的对象所在的地方遗留下更多的”holes"
基本上，这一类"fragmentation"是不大可能影响系统的因为你没有由于empty space做任何额外的工作，除非当你backup这个文件嘚时候如果你真正考虑备份的时候
由于这些empty space影响了备份时间，你可能想采取行动以某种方式转移对象是这些empty space在这个文件的末端，你可鉯resize这个数据文件