SQL Server 2005/2008 – 多个文件/文件组 – 多less个? 为什么?

我是一名开发人员 – 但时不时的,一个客户没有一个像样的DBA来处理这些问题,所以我打电话来决定….

当处理合理大小的SQL Server数据库(比Northwind或AdventureWorks大的东西,大约2-4GB的数据加上索引等等)时,您的策略/最佳实践是什么? – 您是否使用多个文件/文件

如果是这样:多less? 为什么?

什么是你的标准来决定什么时候离开“一个文件组”的方法:

* database size? * database complexity? * availability / reliability requirements? * what else? 

如果您使用多个文件组,则使用多less个? 一个是数据,一个是索引,一个是日志? 几个(多less)的数据? 什么是你select的理由 – 为什么你使用确切数量的文件组:-)

感谢任何提示,指针,想法!

干杯,马克

基本的经验法则是将文件分离到不同的卷上以避免争用,然而,I / O子系统和工作负载所带来的性能增益的巨大变化是很大的。 例如,单个物理主轴上的多个文件在性能上会有所下降,但是与具有来自RAID 10arrays的数百个驱动器的SAN LUN上的卷相同的安排可能会很好。 磁盘队列长度计数器是您的朋友,可以告诉您是否有I / O瓶颈。

您正在查看数据库上的I / O模式 – 只读,主要读取,读写,主要写,只写 – 并基于此。 您还需要select正确的RAID级别,并确保您的磁盘分区偏移,RAID条带大小和NTFS分配单元大小设置正确。 有些人喜欢将非聚簇索引分隔成一个独立的文件组,但是这里的性能增益就像我上面所解释的那样。

除了性能,您还应该考虑可pipe理性和可恢复性。 为100GB数据库提供单一的单一数据文件意味着您的恢复单元就是该文件。 将其拆分成4个25GB的文件组意味着您可以使用部分数据库可用性和零碎恢复,只需要在发生损坏时恢复单个文件组。 通过对多个文件组中的表和索引进行分区,还可以限制维护操作影响数据库的哪些部分(例如,删除索引碎片)。

Tempdb是一个非常特殊的情况,我会在你的博客文章中指出你的理由,解释为什么以及如何分解tempdb – 这里有很多误解。

在这里没有给你一个“全面概括”的build议,我会指给你一些白皮书和博客post供你阅读:

  • 白皮书: 物理数据库存储devise
  • 白皮书: 预部署I / O最佳实践
  • 白皮书: SQL Server 2005中的分区表和索引
  • 白皮书: 部分数据库可用性

  • 博客文章:对TF 1118 (tempdb布局)的误解

  • 博客文章: 您的磁盘分区偏移量,RAID条带大小和NTFS分配单位设置是否正确? (链接到磁盘分区白皮书)

希望这可以帮助你!

在分析当前表的大小和未来增长之后,应当决定将数据库分成不同的文件组。 在我看来,除非拥有数百万行的大型数据库或表格,否则您应该仔细考虑优点和缺点,因为您最终可能会创build比您修复更多的性能问题。

在某些前提下,有些情景可能会很有趣:

  • 2个文件组:数据和索引
  • 3个文件组:只读表,读写表,索引
  • 多个文件组:只读,读写,索引,密钥表1,密钥表2,…

您必须分析您的环境,以确定文件组是否将有助于您的SQL Server增长,使用情况和性能需求。

一些关键指标转移到多个文件组 (从这篇文章 ):

  • 当磁盘队列导致应用程序和用户体验问题时
    • 如果是这种情况,考虑利用其他磁盘驱动器和容纳IO密集表的新文件组
  • 当特定的表是10%或更多的数据库
    • 如果是这种情况,请考虑移动这些特别大的表来分隔单独的基础磁盘驱动器上的文件组
    • 根据表格的大小与表格的其余部分成比例,考虑为单个表格build立一个文件组,
  • 非聚簇索引和数据空间在大型表上相等时
    • 如果是这种情况,请考虑从非聚簇索引中拆分数据和聚簇索引
  • 当数据库中存在几乎相等的只读和读写数据时
    • 如果是这种情况,请考虑将独立文件组中的只读数据拆分为读写数据
  • 如果没有足够的时间来执行数据库维护
    • 如果是这种情况,请考虑将大表分成不同的基础磁盘上的单独文件组,并行执行维护
  • 当业务或应用程序将发生重大变化,数据将以更高的速度增长
    • 如果是这样,请考虑与用户合作以了解潜在的增长
  • 归档数据与生产数据驻留在同一个数据库中时
    • 如果是这种情况,请考虑单独的文件组或本技巧中的一种或多种技术 – 在SQL Server中存档数据

如果您发现文件组可以提高数据库的性能,请在生产服务器上实施更改之前,在暂存环境中编写代码并testing该过程。 准备一些测量,然后再实施更改并在之前/之后进行比较。 由于这些过程可能是非常耗费资源和耗时的,因此在维护期间执行这些过程。

当创build新对象(表和索引)时,请确保在正确的文件组中创build对象以确保预期的性能,并定期validation数据库对象是否位于正确的文件组中,并根据需要进行更正。