SQL Server 碎片知多少之:物理磁盘碎片与数据库碎片的区别 每次提到“碎片”,我们自然而然的就想到了我们电脑中的那个磁盘碎片。在数据库中,我们提到碎片,很多的时候我们就开始犯糊涂了,因为我们曾经也在某些地方听说过“索引碎片”这个东西。最后,我
SQL Server碎片知多少之:物理磁盘碎片与数据库碎片的区别
每次提到“碎片”,我们自然而然的就想到了我们电脑中的那个磁盘碎片。在数据库中,我们提到碎片,很多的时候我们就开始犯糊涂了,因为我们曾经也在某些地方听说过“索引碎片”这个东西。最后,我们就开始认为:可能索引“碎片”中的那个“碎片和”和“磁盘碎片”中的那个“碎片”是差不多的,甚至是相同的。
有朋友可能会从数据库的存储机制去分析,但是最后可能分析清晰了索引碎片是怎么样回事,至于它和磁盘碎片是不是一样,就不得而知了。
其实上面说的那些问题,也是我们团队在为客户解决问题的时候遇到的曾经遇到的问题,而且也做了不少傻事情,最后才慢慢的明白到底是怎么回事。
当然,既然写了这篇文章,那么就说明:它们不是一样的,不是所有的“碎片”都是一样的,就好比不是所有长长头发的人都是女人一样。
那我们就来看看它们之前的区别吧。
其实物理磁盘碎片是Windows在物理磁盘上面工作而产生的一个副作用。我们也知道,清理磁盘碎片可以使得我们的计算机运行的更快,而且Windows也是内置了一些磁盘碎片清理的工具。
磁盘碎片之所以使得我们计算机的性能下降,主要是因为它增加了磁头读取数据的延迟时间。我这里借用CareySon的一个图片来说明一下:
我们知道,Windows会把文件保存到磁盘的空闲空间中,如果寻找到的空间不足以存放所有的文件数据,那么文件就分段会被保存到磁盘的多个地方,我们暂且称这些分段为数据块,或者理解为磁盘中的那个“扇区”,每个扇区都是有大小的。那么,当在读取数据的时候,磁盘的磁头就会定位到磁盘中的各个不同的扇区。
一般而言,磁头移动数据块的时间是读取数据块中数据时间的3-4倍。或者说,寻道时间一般是数据读取时间的3-4倍。
如果此时,在计算机的的磁盘中存在碎片(至于碎片如何产生,我这里也就不花时间讲述,重点不在这里,而且也不难),那么数据的读取操作就发生了变化。原本数据读取时的操作是“寻道-读取数据-读取数据…”,因为没有碎片,数据所在的扇区是连续的。如果有了碎片,那么读取的操作就变为了“寻道-读取-寻道-读取-寻道-读取”,很显然,数据的读取就延迟了。我们还是给大家看一个更加形象的图示:
从上图中可以知道,磁盘碎片使得原本只要读取两个扇区的时间从6ms变到了18ms。试想:如果一个文件有成百上千个扇区,那么读取的延时是非常的严重的,尽管我们感觉不到,因为读取的时间依然很短,但是如何在多用户,大并发的情况下,延时的后果可想而知,当然,此时我们可以采用更多的措施和策略。
对于磁盘碎片的清理,现在已经有了非常多的工具,包括微软自带和第三方的,我这里只是稍微的列举一下:Windows defrag, Power Defra, Page Defrag。
说完了磁盘碎片,我就来看看SQL Server的碎片问题。首先要说的是:它们二者是不一样的。
SQL Server采用了比较高级的存储系统(或者说它的存储机制的设计和Windows中一般保存文件的存储机制不一样),使得多个磁盘可以串联起来一起工作,而且还改变了文件的读取和存储的方式。物理磁盘的碎片最终是从从硬件上面解决,不能通过一些运行脚本的方式解决,而SQL Server中的碎片,则是可以的。
SQL Server存储机制使得它可以使用多磁盘存储设备,例如RAID,SAN和NAS等。磁盘控制器在这些设置中控制着读取数据的操作。在这些设备中,数据被分布在多个磁盘驱动器上面,形成块,和条带。因为数据被分布的保存,在读取的时候就是多个磁盘并行读取,最后每个读取出来的分布数据被组合,成为一个大的数据,传递给上面。这里就不在深入了,因为再说就要涉及到那些N复杂的存储结构,I/O总线了。
我这里只给几个图,大家看看而已:
20120821113459.png(40.41 K)其实说了这么多,只是想要告诉朋友们,这里数据保存的不连贯,是因为设计到形成的。这和之前讲的那个磁盘碎片中数据的保存的不连贯的原因是不一样的。
到这里大家可能开始不明白了,可能要问:尽管把数据这样分布保存在多个磁盘上面,对于每个磁盘上面,依然会有碎片?
有个疑问,说明大家在思考了。
这里一个要理解的重要概念就是:多磁盘存储系统中的磁盘控制器。这个控制器同时也具有碎片清理的功能,并且它还协调数据的读写操作。也就是说,这个控制器已经在磁盘级别做了清理工作。那么,对于SQL Server而言,只要自身清理碎片就行了。而如何清理SQL Server产生的碎片,只有SQL Server本身知道,这属于它的内部机制,控制器无法操作。