SQL Server文件本地或NAS或SAN？

NAS

绝对不是NAS的SQL Server。 SMB / CIFS没有足够的文件locking支持来支持DBMS（至less在几年前，大约是2002-2003）。 请注意，NFS 确实可以在NFS服务器上使用Oracle。 但是，由于协议的限制，CIFS共享上的SQL Server不可靠。 它甚至可能不会让您将文件放在CIFS挂接的共享上。

SAN

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

采用双控制器的SAN也具有无单点故障的架构，并提供多种热备份选项。 这使他们从可pipe理性和可靠性的angular度来看是一个胜利。 然而，对于stream式传输数据量而言，它们是昂贵且受限制的，尽pipe后者在交易系统中不太可能成为问题。

对于运营系统，如果可用的话，SAN几乎总是最好的select。 它们也可以在运行中低音量系统的多个服务器之间共享。 然而，它们带有一个价格标签，这个技术可以用在最小的系统上。

直接连接

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

事实上，数据仓库系统的直连存储通常比SAN更好，原因如下：

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

• 前面提到的stream式瓶颈。

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

直接连接存储的另一个市场是当你销售到一个无法为SAN支付足够的资金的市场时。 销售给SMB客户的应用程序通常是这样的。 对于有6个用户的销售点系统或实践pipe理系统来说，SAN可能是矫枉过正的。 在这种情况下，带有一些内置磁盘的小型独立塔式服务器是更合适的解决scheme。

本地或SAN是维持性能的唯一途径。 在某些情况下，由于较大的写入caching和并行磁盘吞吐量configuration，SAN可能比本地磁盘更快。

避免在Windows共享上执行任何高性能文件I / O。 有大量的协议开销会显着减慢吞吐量。 例如，几年前，我测量了一个WAN上的大文件传输，比使用FTP共享的FTP快了50％。

不要使用NAS。

要么使用本地（确定一个好的RAID控制器中期），但如果预算允许，去体面的SAN。 幸运的是，您可以开始与其他系统“共享”SAN，并回收大部分初始费用。

对于大多数系统来说，4GB内存是很好的，只要它是一个专用的SQL Server（它应该总是）。 如果你还没有考虑到它，可以使用64位操作系统和SQL服务器，这样你就可以轻松地抛出更多的内存，而不需要使用PAE / AWE。

也想想虚拟化。 你将需要一个testing服务器？ 开发者服务器？ testingSP1的安装？ （对于之前的文章，无耻加： sql-server-in-vmware ）

对于2Gb的数据库大小，没有理由甚至考虑SAN。 NAS不能工作，只能使用NAS来进行备份，因此不会将备份与数据存储在同一台计算机上，而且从NAS进行异地存储的复制也很容易。

对于小型数据库，只需使用RAID 1或RAID 10中的本地磁盘即可。如果您的数据库适合内存，则不必非常担心IO性能。 使用64位窗口，并在那里放8个Gig。 这将为操作系统留下足够的空间，给你增长空间。

我使用同时使用本地RAID磁盘和光纤连接SAN的系统。 即使前者是更新更快的机器，SAN看起来performance更好。 我认为一个重要的因素是本地磁盘安排是一个单一的驱动器，所以SQL与操作系统和交换文件共享磁盘I / O。 这很可能是拖累的重要原因。

正如@spoulson所提到的，SAN可以提供更好的磁盘性能。 它不仅是一个单独的驱动器，但它可能在更快的硬盘上。

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

我们一直在努力解决的一个问题是，SAN磁盘空间分配是保守的。 因为价格昂贵，所以不要随心所欲。 使用我们使用的EMC SAN时，如果不转储整个LUN，则无法回收分配的空间。 因此，如果我们发现分配的空间超出了我们的需要，我们希望将这些空间用于另一个LUN，我们不能只缩小超大的空间。 我们必须放弃它并重新分配。 在生产环境中这不起作用。

正如其他人所build议的，避免使用NAS。 你也可以把你的数据文件放在USB外置硬盘上。

对于一个小型的2GB数据库来说，一个SAN会是一个过度的杀手。

一般来说，你不希望你的SQL驱动器与任何其他应用程序共享。 同样，越多的主轴（磁盘），你可以传播你的文件越好。 同样，用一个像你所描述的小型数据库，你可以将所有你需要的东西放在RAM中，这样磁盘性能就不会那么重要了。

也就是说，不要去创build一个RAID-10卷，并把所有的数据库文件放在上面。 您可以从简单的事情开始：数据 – 2个73GB 15K RPM，RAID1日志 – 2个73GB 15K RPM，RAID1备份 – 单个大型7200 RPM或RAID1中的一对

如果你有预算升级，为TempDB添加另一个单独的卷（如果你做任何复杂的报告/分析查询），或给日志卷更多的磁盘和configuration为RAID10，如果你是系统更多的事务瓦特/大量的更新。

对于相同数量的驱动器，SAN可能会比直连式存储器成本高3-4倍。 SAN提供许多先进的备份/快照function，集群支持和LUN迁移和扩展function。 如果这些对您来说很重要，则可能值得增加费用。

免责声明：在NAS上存储SQL Server数据库文件有许多严重的问题。 所有其他选项均相同，则selectSAN选项是正确的。 有关相关问题的详细讨论在MS KB304261中 。 然而，这个线程已经成为所有关于SQL Server在networking共享上的其他问题的一个答案，我宁愿在SQL Server版本中引用NAS支持的状态。

现在不less人正在尝试使用NAS和MS SQL。

这个默认情况下是禁止的，但是可以在MS SQL 2008和MS SQL 2005中解除限制。由于MS SQL 2008 R2没有这样的限制。

在MS SQL 2005和2008中，关键是禁止使用networking共享的跟踪标志。 可以发出

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

在2010年9月在Varun Dhawan的MSDN博客中发布的更多细节。

至less在NAS上技术上运行SQL Server是可能的。 这个select取决于很多因素，不难想象在NAS上很容易获得数据库存储的情况。