首先 – 虽然我完全不屑一顾， 我也很感兴趣的是，如果有什么好的方法可以预先测量/收集数据，我可以使用这些数据来确定要遵循哪些“经验法则”，哪些要跳过。
我不能为应用程序显着改变模式，虽然我有一些怀疑，开发人员去索引快乐; 我不想拿出他们的索引，只是还没有取代他们。
我有一个相当大小的电话应用程序数据库，大约60GiB左右。 数据主要分解为：
我现在在单核机器上，3Gb专门用于SQL Server 2005和SQL Server 2005中的磁盘caching.msdb数据库和操作系统位于15k硬盘驱动器RAID 1上。日志文件和备份驱动器位于15k硬盘驱动器，RAID 1.电话数据库都在2 x 15k硬盘驱动器，RAID 10上（共有8个驱动器）。
我正在大力升级硬件。 在Server 2008 R2 x64上将拥有SQL Server 2008 R2，12个内核，32Gb的RAM。 它有四个内部HD，可能用于操作系统和备份，但最大的变化是连接的存储 – 在外部SAS接口上的12 x 15k驱动器。
我们在当前的服务器上有一点CPU / I / O的限制，但是还不足以打扰很多 – 这个新的服务器将会治愈许多罪过 – 但是我现在还是宁愿这样做。
我可以做一个巨大的RAID 10 6磁盘，并把整个数据库上，但我一直在考虑拆分TRAFFIC，它的索引文件到不同的分区 – 也可能是BILLING。 另外，其他的东西可能在它自己的文件中performance不错。
那么当然，总是有RAID 10和RAID 5/6，RAID 50/60要考虑。
我很想知道如何处理这个决定，以及如何确定是否有必要分拆硬盘，以便将TRAFFIC / BILLING分开 – 我是否可以使用两个文件组（PRIMARY和USERDEFINED），或者如果我愿意需要更多。
顺便说一下，sizeof（TRAFFIC）= sizeof（BILLING）* 2 >> sizeof（EVERYTHEELSE）
谢谢，
让我们从头开始。
我有一个用于电话应用程序的大型数据库，大约60GiB左右
换个说法：我有一个非常小的数据库。 严重的是，大约10年前60千兆的地方。 比较一下：我有一个有800GB和不断增长的财务数据库，95％的数据在一个表中;）
它有四个内部HD，可能用于操作系统和备份，但最大的变化是连接的存储 – 在外部SAS接口上的12 x 15k驱动器。
这是我会做的：
镜像接下来的两张光盘作为日志文件。 如果那些在IO上运行hifh – 将它们与SSD相关联。 鉴于less量的变化你有….小80gb SSD应该是足够的。
其余的（12张光盘），架起了一块休闲的RAID 10。
更重要的是，你重新configuration我们的服务器使用：
那么当然，总是有RAID 10和RAID 5/6，RAID 50/60要考虑。
考虑到Raid 10与其他游戏之间的HUGH性能差异，考虑到这些因素，所有这些都需要考虑，因为这些都需要很高的I / O，所有这些都会将Raid 5/6/50/60中的水冲走。 RAID 5/6如果放入SSD驱动器就会造成严重的损失 – 那么显着的IO损失将被完全吞噬掉。 实际上，考虑到你的数据库规模微不足道，甚至可以使用2×15 SAS光盘。 获得2 x200GB的REALSSD驱动器，如果您的30个驱动器使用RAID 10，则IO性能将达到100倍。 考虑到基础设施的巨大成本，您可能会省下很多钱。
其实，最聪明的事情就是不要考虑整个SAS的东西 – 你有4个硬盘插槽，把操作系统放在两个硬盘上，在另一个镜子上使用200GB固态硬盘。 成品。 而且也比你的SAS更快;）有一个微不足道的数据库大小的喜悦。 请查看http://www.fastestssd.com了解当前状态。 现代固态硬盘将在该设置中保持200mb的持续随机速率，即使不是最高的。 这将会严重地擦掉你从SAS设置中获得的平庸IO。
或者：30张SAS光盘可能是4800 IOPS。 RealSSD最高可达50.000，在一张光盘上，“弱时”约为36.000 IOPS。 这意味着一个SDD的速度是你的12张光盘的7.5倍。 在美好时光中快10倍左右。 哎哟。
请小心妥善alignment这些部分，并适当地格式化文件系统（提示：不要使用标准的4kb节点大小 – 对于SQL Server来说是愚蠢的）。
我可以做一个巨大的RAID 10 6磁盘，并把整个数据库上，但我一直在考虑拆分TRAFFIC，它的索引文件到不同的分区 – 也可能是BILLING。 另外，其他的东西可能在它自己的文件中performance不错。
那将是SQL Server的愚蠢的滥用。 即使它确实在文件之间进行负载平衡，并且要求/每个组要求多个文件（每个逻辑处理器一个文件），但是它不会获得任何东西。 无论如何，分离文件和索引都没有任何意义。 在你的情况下，你最好用一个文件组，12个文件。 如果你想要以后的可扩展性，你可能想要开始48个数据文件 – 给你的空间达到处理器48内核。
您可能希望使用两个文件组来从较不稳定的/请求的账单数据中分离出账单数据，但不是为了直接速度，而是为了在不重新组织的情况下将这些数据完全移到后面的权限 – 这就是我对我的财务数据库。
最后一句话：谁购买服务器是一个坏的决定硬件明智。 没有理由有一个小的外部SAS托盘。 我的数据库服务器来自SuperMicro，有2个机架单位高度的24个磁盘插槽。 那是没有外部笼子。 我真的不想比较这里的数字 – 但我敢打赌这是浪费了很多钱。
我将链接到一个白皮书，介绍如何回答这个确切的问题。 虽然我们所有人都可以提出一般性的build议，但是真正的问题来自于实际的I / O利用率。 下面的白皮书谈到如何衡量，以及如何规划磁盘子系统（并testing新硬件以确保达到最佳效果）。 另外，最后还有很多额外的链接可以真正挖掘到这个领域：
预部署I / O最佳实践
这应该也有助于谷歌dmv所有明星！
http://technet.microsoft.com/en-us/library/cc966540.aspx
也
windchill条目涵盖了几乎所有的sql服务器性能指标