本贴是四篇系列中的篇二，涵盖磁盘和表空间碎片内容。完整的系列如下所示：
1、介绍 – （含2-4的链接）
2、磁盘和表空间碎片 – （本篇）
3、表碎片
4、索引碎片
二、磁盘和表空间碎片
2.1 磁盘“碎片”
表空间由文件组成，文件存储在磁盘上–多是指“逻辑卷”而不是真正的磁盘设备。当你发出一个（真实）的磁盘读请求，一次物理操作可获取到的最大数据量大约是300KB到500KB–这大约是单面磁盘一个环行磁道所存储的内容。
对于一个较大的（磁盘）读，你需要在不同的盘面（电路切换）、不同的磁道（磁头的径向移动），或者不同的磁盘间切换，这意味着要加入到其它的磁盘队列（在这种情况下，你的SAN软件—或等效软件—可能已经计算出您将要使用的磁盘，并且并发地启动所有读取队列）。
当你创建一个Oracle数据文件时，你简单到不需要知道文件是如何在系统中的多个磁盘间分布的–在最好情况时，从单个文件中读取1MB，也许只需转换为对带有电子盘面换的单个磁盘的三到四次旋转，最差时，我曾见到单次读请求，转换为32个独立的磁盘事件。这是由于使用了多层软件进行跨磁盘条带化。然后条带又跨了磁盘组，又跨了逻辑卷组等等。（如果你的SAN上只有你一个用户，这可能真的会提供很好的性能，但是，在多用户系统中，这会是一个队列灾难。这也是为什么向ASM提供“裸盘”并且在Oracle和磁盘之间只有一层软件是一个好策略的原因。）
Maxim(人名）：不要在Oracle和磁盘之间放置过多的软件层。
2.2 表空间“碎片”
显然，你可以创建使用多个文件的表空间。根据这个定义，表空间就是碎片化的–尽管这种特殊类型的碎片并没有什么问题。如我在前一篇中指出的，这会对数据段中extent的位置产生副作用， 并且，这可能导致你想执行一个大的读，却发现你实际上执行了很多比你期望要小的读，同时，IO队列时间也相应增加了。
不过，人们在谈论表空间碎片化时更喜欢考虑的是“碎片化”效应，这种效应也被称为“honey-combing（蜂窝）”和“bubbling（气泡）”。这是删除或收缩对象、移动表或重建索引的副作用。最后会在整个表空间中散落大量的空闲空间。当然，你每次重建另一个对象时，可能会重新填充其中的一些（碎片）–但在对象原来的位置却留下了更多的孔。
基本上，这类碎片不太像是个麻烦，因为你并没有因为空的空间而做了额外的工作–备份文件时除外。如果你真的认为备份空的空间所花费的时间对整个备份时间有重要影响（比如，导致下一次数据加载周期超负荷），那么你可能在某种程度上想移动这些对象，以便将这些空的空间留在文件的末尾，从而允许你减少文件的大小。（比如这个收缩表空间的例子https://jonathanlewis.wordpress.com/2010/02/06/shrink-tablespace/ 译文链接），但是，请牢记，围绕移动对象可能会带来你不想要的副作用–几年前，在OTN上有一个令人悲伤的小帖子，一位DBA发现移动表会使它们占用了更多的空间（我写了一个贴子https://jonathanlewis.wordpress.com/2007/11/23/table-rebuilds/ 译文链接 作为回应，引用了原因和解决方案，并把它发表在《Oracle 8i实践》上）。
有关“蜂窝”的历史难点，是Oracle允许你指定数据段的PCTINCREASE这个参数的巨大副作用–助长了将每个对象都缩减到1个extent之内是个好主意的荒诞说法。随着对extent尺寸有严格限制（尤其是相对于uniform的选项）选项集的本地管理表空间的引入，唯一的问题是时机–何时重用这些空间，而不是为了重用这些空间你要如何管理。
以下附原文链接和内容：
https://jonathanlewis.wordpress.com/2010/07/16/fragmentation-2/
Fragmentation 2
Filed under: fragmentation,Infrastructure,Oracle — Jonathan Lewis @ 6:51 pm BST Jul 16,2010
This note is part two of a four-part series, and covers Disk and Tablespace fragmentation. The whole series is as follows
Introduction – with links to parts 2 – 4
Disk and Tablespace Fragmentation – this bit
Table Fragmentation
Index Fragmentation
2.1 Disk “fragmentation”.
Tablespaces are made up of files, and files are stored on discs – which are often “logical volumes” rather than real devices. When you issue a (real) disc read request, the largest amount of data you can get off a (real, physical) disc in a single physical action is something like 300KB to 500KB – the content of a single circular track on a single platter of a disc.
For a larger read you continue the read by switching to a different platter (electronic switch), switching to a different track (radial head movement), or switching to a different disc – which means joining another disk queue (in which case your SAN software – or equivalent – will probably have worked out which discs you were going to be using and started all the reads queueing concurrently).
When you create an Oracle datafile you simply do not know how scattered that file might be across the physical discs in the system – at best a 1MB read from a single file may turn into three or four rotations of a single disk with electronic platter switches, at worst I have seen a single read request turn into 32 separate disc events because of the multiple layers of software that had been used to stripe across discs, then stripe across disk groups, then stripe across logical volume groups and so on . (This can be really good for performance if you are the only user on your SAN, but a queueing disaster on a multi-user system; and this is why it has become a good strategy to present “naked” discs to ASM and have only one layer of Oracle-aware software between Oracle and the discs).
Maxim: don’t put too many clever layers of software between Oracle and the disc drives.
2.2 Tablespace “fragmentation”.
Obviously you can create a tablespace using multiple files. By definition the tablespace is fragmented – even though there is nothing inherently wrong with this particular type of fragmentation. As I pointed in the previous note, though, this has side effects on the placement of extents for a data segment and this can lead to cases where you might want to perform big reads and find that you are actually performing smaller reads than expected with an associated increase in I/O queue time.
The “fragmentation” effect that people are more like to have in mind, though, when they talk about tablespace fragmentation is something that has also been called “honey-combing” and “bubbling”. This is a side effect of dropping or shrinking objects, moving tables, or rebuilding indexes. You end up with chunks of free space scattered throughout the tablespace. Each time you rebuild another object, of course, you will probably refill some of these chunks – leaving a load more holes where the object used to be.
Basically this type of fragmentation is unlikely to matter since you’re not doing any extra work because of the empty space – except when you backup the files. If you really think that the time spent backing up the empty space is having an important impact on your backup times (which may mean that the backup over-runs into the next dataload cycle, for example), then you might want to take some action to move objects around in a way that leaves all the empty space at the end of the files as this will allow you to reduce the file size. (See, for example, this note on shrinking tablespaces.) Bear in mind, though, that moving objects around can introduce undesirable side effects – there was a sad little note on OTN a couple of years ago where a DBA found that moving tables made them take up more space (I wrote a note in response, quoting the reason, and solution, that I had originally published in Practical Oracle 8i).
The historic difficulties associated with “honeycombing” were largely a side effect of the pctincrease parameter that Oracle allowed you to specify for data segments – helped along by the myth that it was a good idea to keep reducing your objects to a single extent each. Since the introduction of locally managed tablespaces with their strictly limited set of options for extent sizing (especially the option for uniform sizing), the only issue is timing – when are you going to reuse the space, not how can you manage to reuse the space.
