单词‘fragmentaion’的含义是某些东西被分割成片段，但是也经常暗示着被分割成很多小的片段。在oracle中，你需要去考虑究竟什么是一个片段，这个片段的粒度
是什么，可能会给系统性能带来什么样的影响。这是因为当我们讨论关于碎片，它可能是在(Logical)磁盘(disk)级别，文件（file)级别，表空间(tablespace)级别，

段(segment)级别，区(extent)级别,以及块(block)级别。所以，当你评论诸如"my tablespace is fragmented"或者”my index is fragmented",你非常有必要清晰的
阐述你究竟要说什么。

很明显这张表是"碎片的",因为它被划分成100个不同的片段。另一方面，这张表是我操作这个表空间的第一个操作，我可以看到所有的这些extents是连续的-所以你可
能会说这个表是逻辑碎片的"logical fragmented"而不是物理碎片的"physically contiguous"(逻辑上分成很多片段，无理上是相邻的).

如上这个碎片的例子会不会影响我们数据库系统的性能呢？因为大部分orcale的I/O操作都是在块级别完成的(我们读一个数据块进入db cache，我们写数据块进入数据
文件),并且在任何特定的extent里数据块的位置是无相关性的，所以答案可能是no。但是很多次当我在一个单独的读请求下读很多相邻的块(tablescans和index fast
full scans),物理上连续"physically contiguous"的表被分割成逻辑上碎片"logically frgmented"的区(extents)会存在什么问题吗？

假设很多extent，每个extent是64k，当发出一个多块读"db file multiblock read"的请求，它会受限于extent的大小吗？或者，它能够跨extent读吗？假设一个表空
间由两个数据文件组成，并且这些extents以轮流"round-robin"方式在这两个文件中产生-这样会影响读操作的方式吗？假设我们尝试并行扫描一张表-这些限制会影响
"direct pathreads"吗？如果你是在数据仓库花费大量的时间做这些操作，那么如上这些问题是你需要回答的。((See, for example, a note I wrote three years ago
about some of the anomalies of I/O sizes when running parallel query, and a related enhancement in 11g described by Christian Antognini a couple of
years later.)