碎片(Fragmentation)--解析

碎片(Fragmentation)--解析
Fragmentation write by Jonathan Lewis Translated By me
Fragmentation1：
这篇文章开始于一个简单的随记，直到我意识到它不仅如此，我决定把它写成一系列文章，我将发布以下四部分在接下来的2周：
1，介绍
2，磁盘和表空间碎片
3，表碎片
4，索引碎片

Introduction

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

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

让我们从一个例子开始：我创建了一个新表空间并且转移进一张表。当我查询dba_extents视图的时候，这张表有100个extents。但从这个“fragment"的字面意思而言,

很明显这张表是"碎片的",因为它被划分成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.)

仅仅在你开始清晰的考虑关于什么是碎片"fragmentation"之后,你可以开始理解可能引起的问题以及问题的可能的原因，为什么对你的系统有如此的影响。
在第二部分，我将对你应该在磁盘级别和表空间级别考虑的关于碎片的做一些阐述。