0

我想访问 INTEL SS4000-E 存储中的我的 sql server 数据库文件。它是 NAS 存储。是否可以将其用作 sql server 2000 的存储？如果不是，最好的解决方案是什么？

4

6 回答 6

1

我强烈建议不要这样做。

使用 RAID 镜像驱动器将您的数据文件本地放在服务器本身上。原因有两个：

  • SQL Server 对于除最小工作负载之外的所有工作负载都会运行得更快
  • 万一到 NAS 的链接被破坏，SQL Server 将不太容易损坏。

使用 NAS 存储 SQL Server 的备份，而不是托管数据文件。我不知道你的数据库大小是多少，或者你的使用模式是什么，所以我不能告诉你必须拥有什么。对于将在生产环境中承担任何重大负载的数据库，我建议至少使用两个逻辑驱动器（一个用于数据，一个用于事务日志），每个都包含一个 RAID 1 阵列，其中包含您可以承受的最快驱动器买。如果这太过分了，请将您的数据库放在两个物理驱动器上（一个用于事务日志，一个用于数据）。如果这超出了预算，请将您的数据放在一个驱动器上，并经常备份。但是，如果您选择单驱动器或 NAS 解决方案，IMO 您相信祈祷的力量（这可能不是一件坏事，它只是'

请注意，NAS 与 SAN 不同（人们通常会在 SAN 上放置数据库文件）。NAS 通常比 SAN 连接慢得多，带宽也少得多，SAN 连接旨在实现非常高的可靠性、高速、高级管理和低延迟。NAS 更适合降低网络存储成本。

于 2008-10-30T03:45:00.150 回答
1

我的直觉反应 - 我认为您在 NAS 上冒着数据风险是疯了。SQL 的期望是对存储子系统的持续低延迟不间断访问。几乎可以肯定，NAS 不是这些东西——您的本地或 SAN 存储（按照性能、简单性和偏好的顺序）——将 NAS 留作离线文件存储/备份。

以下 KB 列出了尝试将 NAS 与 SQL 一起使用时遇到的一些限制和问题 - 虽然 KB 涵盖了 SQL 7 到 2005，但许多信息仍然适用于 SQL 2008。

http://support.microsoft.com/kb/304261

于 2008-10-30T03:56:20.720 回答
0

本地几乎总是比网络存储快。

您的 sql 性能将取决于您的对象、文件和文件组是如何定义的，以及消费者如何使用数据。

于 2008-10-29T20:42:46.180 回答
0

好吧，“最佳”对不同的人意味着不同的东西，但我认为“最佳”性能将是 TMS RAMSAN 或 SSD 的 RAID ......等等

使用大型 HDD 的 RAID 可以实现最佳容量...

通过跨多个驱动器进行镜像和定期备份（最好是异地备份）可以实现最佳可靠性/数据安全性......

最佳可用性...我不知道...也许克隆系统并随时准备好热备份。

最好的安全性需要加密，但主要限制对机器（及其备份）的物理访问就足够了，除非它连接了互联网。

于 2008-10-30T03:54:28.523 回答
0

正如其他答案所指出的，这里会有性能损失。

还值得一提的是，这些东西有时会实现 RAM 缓存以提高 I/O 性能，如果是这种情况并且您尝试了此配置，则 NAS 应该与服务器硬件处于相同的电源保护/UPS 上，否则在在断电的情况下，NAS 可能会“丢失”缓存中的文件部分。哎哟！

于 2008-10-30T04:50:33.140 回答
-1

它可以工作，但专用光纤连接的 SAN 会更好。

本地通常会更快，但它的大小有限并且不容易扩展。

我对硬件不熟悉，但我们最初在共享 NAS 上部署了一个仓库。这是我们发现的。

我们经常在主机上争夺资源——它只能处理这么多的带宽。海量仓库查询和数据负载受到严重影响。

我们的仓库（数据/索引/日志）需要 1.5 TB，我们将这些资源中的每一个都放在一组单独的 LUN 上（就像您可能对附加存储所做的那样）。数据仅跨越 10 个磁盘。我们遇到了各种各样的 IO 瓶颈。更好的解决方案是在许多小磁盘上创建一个大分区，并将数据、索引和日志存储在同一个地方。这大大加快了速度。

如果您正在处理一个中等使用的 OLTP 系统，您可能没问题，但 NAS 可能会很麻烦。

于 2008-10-29T20:57:42.063 回答