ID #65774

SQL Server 数据存储与 NTFS 簇的大小

首先感谢微软发明的NTFS文件系统,确实是非常健壮的文件系统,功能强大。

簇是磁盘进行I/O读写时的最基本单位(就是NTFS中的分配单元)。

今天来说一下在SQL Server的数据存储中与NTFS簇大小有关的话题。NTFS在超过2GB的分区中,格式化时会默认使用4KB的簇,这基本上就成了现在大部分硬盘的簇大小。在簇不大于4KB时,可以使用碎片整理。

NTFS簇大小可以设置成从512B~64KB大小,当然必须在格式化时指定,否则就不可以更改了。簇太小,空间利用率高,但分区表较大,碎片多,性能较差;簇太大,空间利用率低,但碎片少,性能较好。于是4KB可谓是普遍的选择。

现在的硬盘,动则容量几百GB,空间似乎已经不再是问题。但磁盘的I/O一直是性能的瓶颈,为了提高磁盘读写速率,各位可谓是绞尽脑汁了。无论如何,硬盘只要选用了,改变它的物理设计似乎并不太可能,也不推荐这样做,于是就只能从其它的地方着手了,方法如用RAID陈列了、经常地整理碎片、用好的芯片、用好的数据线了等等,能用的都用了。

SQL Server服务器是对I/O要求高的应用,它的数据文件读写基本单位是页,每页的大小是8KB,连续的8个页组成一个区,也就是64KB的区,且一般数据文件都比较大,一般生产环境中,几GB以上是常见的。并且基本上不会有人在SQL Server的存储上用碎片整理了,因此我们可以将专用于SQL Server存储的磁盘分区格式化成为64KB的簇,这样在不浪费空间的前提下,又可以提高性能。

有没有风险?当然有了,在磁盘出现灾难时,丢的数据可能就会多一点,最少会丢64KB了,不过实践证明这种方案还是非常可行的,因为一般服务器的RAID陈列分块也是64KB,两个都是64KB,就无所谓了。

其它应用场景各位也可以参考,不对之处,欢迎批评。

本文作者:gytnet

本文出处:http://www.cnblogs.com/gytnet/archive/2009/12/21/1628561.html


2011-08-28 10:54
阅读:
I'm VC , Just U know Y
本站部分文章来源于互联网,版权归原作者所有。

延伸阅读:

关于连接SQL Server 2000时提示“SQL Server不存在或拒绝访问”的处理

SQL 2005 发送邮件 存储过程

如何管理SQL Server的数据库对象

SQL SERVER 2000 连接不上的解决方法

Microsoft SQL Server 查询处理器的内部机制与结构