SQL Server文件是本地文件还是NAS或SAN？

我必须在SQL Server 2008上安装一台新服务器，您推荐什么？一台具有RAID 10的服务器或NAS中的文件？

我应该如何使用iSCSI？

那SAN呢？

该服务器具有4Gb RAM，该数据库文件约为2GB。

今天要明确地说，服务器没有RAID，我必须实施某种策略，以便在发生问题时可以保护文件安全，那么应该选择什么本地文件，NAS，SAN？哪个选项具有最佳性能，哪个更安全？

NAS

绝对不是用于SQL Server的NAS。SMB / CIFS没有足够的文件锁定支持DBMS（至少在几年前（大约2002-2003年）没有）。需要注意的是NFS 不和你真正可以与Oracle NFS服务器上做到这一点。但是，由于协议的限制，CIFS共享上的SQL Server不可靠。它甚至可能不允许您将文件放在CIFS挂载的共享上。

SAN

这对事务性应用程序来说是好的，因为RAID控制器上的缓存可以吸收相当大的工作集。SAN RAID控制器通常比基于主机的RAID控制器支持更多的缓存，特别是在高端套件中，其中RAID控制器可能是与服务器一样强大的多处理器设备。

具有双控制器的SAN也具有无单点故障的体系结构，并提供了许多用于热备份的选项。从可管理性和可靠性的角度来看，这使其成为制胜法宝。但是，它们昂贵且受流数据量的限制，尽管后者在事务系统上不太可能成为问题。

对于操作系统，SAN几乎始终是最佳选择（如果有）。它们还可以在运行中小型系统的多台服务器之间共享。但是，它们带有价格标签，在可以使用该技术的最小系统上有相当大的下限。

直接连接

在某些情况下，直接附加存储是最好的。一种可能是带宽受限的流应用程序，其中有限数量的光纤通道连接将把可用带宽限制为小于高端SAS控制器可能的带宽。但是，这些可能是相当专业的应用程序，例如非常大的数据仓库，其中无共享架构可能无法提供最佳吞吐量。

实际上，由于以下几个原因，对于数据仓库系统，直接连接存储通常比SAN更好：

• 数据仓库在磁盘子系统上产生了较大的瞬时负载峰值。这使它们在SAN上非常反社会，因为它们可能会影响SAN上其他系统的性能。

• 前述的流媒体瓶颈。

• 直接连接存储比SAN存储便宜很多。

直接连接存储的另一个市场是当您向不会为SAN支付足够钱的市场销售产品时。对于出售给SMB客户的应用程序，通常是这样。对于将要有六个用户的销售点系统或实践管理系统，SAN可能是过大了。在这种情况下，带有一些内部磁盘的小型独立塔式服务器是更合适的解决方案。

本地或SAN是维护性能的唯一方法。在某些情况下，由于更大的写缓存和并行磁盘吞吐量配置，SAN可能比本地磁盘更快。

避免通过Windows共享执行任何高性能的文件I / O。协议开销很大，会大大降低吞吐量。例如，几年前，我曾测量过通过Windows共享使用FTP，通过WAN进行大文件传输的速度提高了约50％。

不要使用NAS。

都可以使用本地磁盘（对于一个良好的RAID控制器，可以使用中期协议），但如果预算允许，可以选择一个不错的SAN。幸运的是，您可以开始与其他系统“共享” SAN并收回大部分初始支出。

只要是专用的SQL Server（并且应该始终如此），则4GB RAM对于大多数系统来说就可以了。如果您还没有考虑过，请使用64位OS和SQL Server，这样您就可以轻松投入更多的RAM，而不会浪费PAE / AWE的东西。

还考虑虚拟化。您需要测试服务器吗？开发服务器？测试SP1的安装？（无耻加为早先的文章：sql-server-in-vmware）

数据库大小为2Gb，甚至没有理由考虑使用SAN。NAS无法正常工作，您只应考虑使用NAS进行备份，这样就不会将备份与数据存储在同一台计算机上，并且很容易从NAS复制副本以进行异地存储。

对于小型数据库，只需使用RAID 1或RAID 10中的本地磁盘即可。如果数据库适合RAM，则不必太担心IO性能。使用64位窗口，并在其中放置8个Gig。这将为操作系统留出足够的空间，并为您提供增长的空间。

我使用既使用本地RAID磁盘又使用光纤连接SAN的系统。即使前者是更新更快的计算机，SAN的性能也似乎更好。我认为一个重要因素是本地磁盘排列是单个驱动器，因此SQL与操作系统和交换文件共享磁盘I / O。这可能会极大地拖累阻力。

如@spoulson所述，SAN可以提供更好的磁盘性能。它不仅是一个单独的驱动器，而且可能在速度更快的磁盘硬件上使用。

在我们的案例中，我们使用SAN是因为它为自动故障转移VERITAS SQL Server服务组提供了一个集中的存储区域。当主计算机发生故障时，SAN上安装的Windows驱动器将重新安装到热备份计算机上，服务器很快恢复正常。当然，这需要用于服务组管理的类似于VERITAS的系统，该系统可能不在您的范围内。

我们一直在努力的一个警告是，SAN磁盘空间分配是谨慎处理的。因为价格昂贵，所以不要一时兴起。使用我们使用的EMC SAN，您无法在不转储整个LUN的情况下回收分配的空间。因此，如果我们发现分配的空间超出了我们的需要，并且想将其中一些空间用于另一个LUN，我们就不能只缩小超大空间。我们必须删除它并重新分配。这在生产环境中效果不佳。

正如其他人建议的那样，避免使用NAS。您最好将数据文件放在USB外部硬盘驱动器上。

对于2GB的小型数据库，SAN可能会显得过大。

一般来说，您不希望您的SQL驱动器与任何其他应用程序共享。同样，可以分布文件的主轴（磁盘）越多越好。同样，使用您描述的小型数据库，您将能够满足RAM中所需的所有内容，因此磁盘性能将不再是一个重要因素。

就是说，不要创建单个RAID-10卷并将所有数据库文件放到上面。您可以从简单的开始，例如：数据-2x 73GB 15K RPM，RAID1日志-2x 73GB 15K RPM，RAID1备份-单个7200 RPM或RAID1中的一对

如果您有升级的预算，请为TempDB添加另一个单独的卷（如果您执行任何复杂的报告/分析查询），或者为日志卷分配更多的磁盘并将其配置为RAID10（如果您的系统需要更多的事务，则需要大量的事务）更新。

对于相当数量的驱动器，SAN的成本可能是直接连接存储的3-4倍。SAN确实提供了许多用于备份/快照，群集支持以及LUN迁移和扩展的高级功能。如果这些对您来说很重要，则可能值得增加费用。

免责声明：在NAS上存储SQL Server数据库文件存在许多严重问题。所有其他选项都相同，则选择SAN选项是正确的。有关相关问题的详细讨论，请参见MS KB304261。但是，该线程已成为网络共享上有关SQL Server的其他问题的全部解决方案，我宁愿发布对S​​QL Server版本中NAS支持状态的引用。

现在有很多人尝试将NAS与MS SQL一起使用。

以前默认情况下是禁止这样做的，但是可以取消对MS SQL 2008和MS SQL 2005的限制。由于MS SQL 2008 R2没有这种限制。

在MS SQL 2005和2008中，关键是禁止使用网络共享的跟踪标志。一个可以发行

 DBCC TRACEON(1807, -1)
 CREATE DATABASE [test] ON  PRIMARY 
 ( NAME = N'test', FILENAME = N'\\storage\mssql_db\test.mdf' )

有关更多详细信息，请参见Varun Dhawan的MSDN博客中的2010年9月帖子。

在NAS上至少可以在技术上运行SQL Server。选择取决于许多因素，不难想象NAS上随时可以存储数据库存储的情况。