碎片(Fragmentaion)2

碎片(Fragmentaion)2:
Fragmentation write by Jonathan Lewis Translated By me
这是篇文章的第二部分,将覆盖磁盘(Disk)和表空间(Tablespace)碎片(Fragmentaion).
1，介绍
2，磁盘和表空间碎片
3，表碎片
4，索引碎片

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