mar*_*c_s 11 groups sql-server sql-server-2005 sql-server-2008
我本质上是一名开发人员 - 但时不时地，客户没有一个像样的 DBA 来处理这些问题，所以我被要求决定......
在处理合理大小的 SQL Server 数据库（任何大于 Northwind 或 AdventureWorks 的数据库；大约 2-4GB 的数据加上索引等）时，您的策略/最佳实践是什么？您是否使用多个文件/文件组？
如果是这样：多少？为什么？
您决定何时摆脱“一个文件组为一切”方法的标准是什么：
* database size?
* database complexity?
* availability / reliability requirements?
* what else?
如果您使用多个文件组，您使用多少个？一为数据，一为索引，一为日志？几个（多少）用于数据？您选择的原因是什么 - 为什么要使用确切数量的文件组:-)
感谢您的任何提示，指针，想法！
干杯，马克
Pau*_*dal 16
基本的经验法则是将文件分离到不同的卷以避免争用，但是您获得的性能提升量因 I/O 子系统和工作负载而异。例如，就性能而言，单个物理轴上的多个文件会很糟糕，但将卷放在具有数百个来自 RAID 10 阵列的驱动器的 SAN LUN 上的相同安排可能会很好。磁盘队列长度计数器是判断是否遇到 I/O 瓶颈的最简单方法。
您正在查看数据库上的 I/O 模式 - 只读、主要读取、读写、主要写入、只写 - 并以此为基础。您还需要选择正确的 RAID 级别并确保正确设置磁盘分区偏移量、RAID 条带大小和 NTFS 分配单元大小。有些人喜欢将非聚集索引分离到一个单独的文件组中，但正如我在上面解释的那样，这里的性能提升有所不同。
除了性能之外，您还应该考虑可管理性和可恢复性。拥有一个用于 100GB 数据库的单一整体数据文件意味着您的恢复单位就是该文件。将其拆分为 4 个 25GB 的文件组意味着您可以使用部分数据库可用性和零碎恢复，以便在文件组损坏时只需要恢复单个文件组。通过在多个文件组中对表和索引进行分区，您还可以限制数据库的哪些部分受到维护操作（例如索引碎片删除）的影响。
Tempdb 是一个特殊的案例，我会在我的一篇博客文章中为您指出，该文章解释了所有关于拆分 tempdb 的原因和方法 - 有很多误解。
在这里不给你一个“全面概括”的建议，我会向你指出一堆白皮书和博客文章供你阅读：
白皮书：部分数据库可用性
博客文章：关于 TF 1118 的误解（tempdb 布局）
希望这对你有帮助！
| 归档时间： |
|
| 查看次数： |
12897 次 |
| 最近记录： |