Tod*_*odd 3 sql-server storage sql-server-2008-r2 hardware
有大量文章推荐 SQL Server 的 RAID/LUN/驱动器配置，但大多数让我仍然质疑，因为他们通常说“这取决于”，因此我想提供一些细节并获得一些更直接的建议：
我有一个客户已经在 Cybernetics SAN 上安装了 SQL Server，具体细节如下：
• SQL Server 2008 R2 安装在虚拟服务器上
• 贮存：
Run Code Online (Sandbox Code Playgroud)o Cybernetics miSAN-D8/T16 SAN iSCSI storage appliance o 4+1 GbE ports o 8 GB SAN controller cache o USB and eSATA ports o Two miniSAS device o 8 drive bays all filled with 600 GB SATA-II 7.2K drives (5.4 TB total) o All 8 drives set up in RAID 6 o Three logical drives: 1. C (156 GB) – for system and apps (IIS, web app, SQL, SSIS, CA ArcServe backup app, VIPRE antivirus) 2. E (1.64 TB) – for data, logs and tempdb 3. F (1.80 TB) – for backups
SQL Server 的读取强度更高，每晚都会像数据仓库和用于查找和报告数据的 Web 应用程序那样批量加载数据。
客户在使用 Web 应用程序的短时间内会周期性地遇到缓慢，有时甚至严重。我还注意到 Brent Ozar 的 Blitz 脚本有时会显示对 E 驱动器的缓慢写入。
我想建议客户按如下方式重新配置他们的 SAN：
- C（156 GB，raid 1）——用于系统和应用程序文件。
- D（1200 GB，raid 10/5）——用于 sql 数据文件。
- L（444 GB，raid 1）——用于日志文件。
- T（1200 GB，raid 5）——用于 tempdb 数据文件。
- 备份到不同的 san 或网络位置并存档到磁带。
但至少我认为客户应该做到以下几点：
建议？
安装在虚拟服务器上的 SQL Server 2008 R2
IMO，SQL Server VM 应该与其余 VM 一起使用。如果该设备出现故障（Cybernetics 网站没有说明该型号范围内的控制器数量，因此大概只有一个），您不会希望所有鸡蛋都放在一个篮子里。希望有其他更好的保护设备可用。
SQL Server 的读取强度更高，每晚都会像数据仓库和用于查找和报告数据的 Web 应用程序那样批量加载数据。
你还没有说数据仓库有多大或加载时间 SLA 是多少，但我强烈怀疑 RAID 5/6 不适合这个，特别是因为涉及 7.2k RPM 驱动器。高驱动器延迟与 RAID 5/6 相结合，对写入性能而言是两英尺的坟墓。
客户还可以考虑优化批量加载过程以提高效率。这方面很可能效率低下。
- 将备份移动到不同的 SAN 或网络位置，以释放 F 驱动器以供 SQL 使用以及更好的 DR。
- 将日志文件和 tempdb 数据文件移动到 F 驱动器。
移动 DR 的备份：是的，绝对。如果其他设备上有可用空间，请使用它。
由于存储都是 RAID 6 的大池，因此无论使用哪个逻辑卷，性能特征都将相同，因此除非需要更多空间，否则我认为移动东西没有任何意义。
我想建议客户按如下方式重新配置他们的 SAN：
除了将备份移出此 SAN 之外，此配置可能会使事情变得更糟：
对单个数据库日志文件使用 RAID 1 没问题，但是一旦您有多个日志文件，那就是随机访问，性能会急剧下降。
以前对数据文件的读取和写入分布在 8 个驱动器上，现在相同的负载将分布在 3 个驱动器上。
我建议在一个 RAID 10 池中使用所有 8 个驱动器，鉴于工作负载和可用硬件，这是唯一有意义的 RAID 级别，这仅比您建议的配置少 1 个驱动器的可用空间。只是没有足够的回旋空间来微观管理这里的物理池。如果初始尺寸错误，或者尺寸随着时间的推移发生剧烈变化，则需要重做整个过程。使用一个池提供了更大的灵活性。
现在说了这么多，根据数据集的大小，购买更多 RAM 通常是一个非常好的投资回报率，以便 SQL Server 首先需要执行更少的物理读取，从而提高性能。但这当然无助于写入工作量。