sql-server - 大量的 SQL Server 内存使用会导致错误吗？

Question

刚开始在我们的 C# .Net 应用程序上出现一堆似乎无缘无故发生的错误。诸如 SqlDataReader 对象上的 System.IndexOutOfRangeException 之类的索引应该返回并且已经返回一段时间了。

无论如何，我查看了任务管理器，发现 sqlservr.exe 的运行内存使用量约为 1,500,000 K。我绝不是 DBA，但在配备 Intel Xeon 3.33Ghz 和 4GB ram 的 Win Server 2003 R2 Enterprise 上，大量使用内存对我来说是错误的。所以我重新启动了 SQL Server 实例。重启后，一切恢复正常。错误突然停止发生。 那么这种大的主内存使用最终会导致错误吗？

此外，我用 Google 快速搜索了 high memory usage mssql .我发现如果保留默认设置； SQL Server 可以增长到那么大。此外，找到了关于 How to adjust memory usage by using configuration options in SQL Server 的 MS 链接。 .

现在的问题是……应该将 SQL Server 的主内存限制在多少？

Answer 1

如果是数据库本身，我肯定会非常感到惊讶，SQLServer 是一个非常可靠的产品 - 比 Office 或 Windows 本身的任何产品都要好得多，并且通常可以绝对和完全地依赖。

1.5Gb 对于 rdbms 来说什么都不是 - 而且它们都将继续用缓存数据填充它们的可用缓冲区。内核读取通常比磁盘访问快 1000 倍或更多，因此使用它可用的每一 block 内存是最佳设计。事实上，如果您查看任何 RDBMS 设计理论，您会发现用于决定从核心中丢弃什么的算法非常重要，因为它会对性能产生重大影响。

大多数专用数据库服务器将以 4Gb 内存(假设为 32 位)运行，其中 90% 专用于 SQL Server，因此您肯定不会在此处查看任何类型的边缘条件。

到目前为止，您最有可能遇到的问题是编码错误或结构问题(例如锁定)

不过我确实有一个警告。非常(非常，非常 - 就像 10 年两次)偶尔我看到 SQL Server 返回页面撕裂错误由于其数据库文件损坏，两次都是由潜在的间歇性硬件故障引起的。幸运的是，这两次都是在保存索引的页面中，通过删除索引、修复数据库、备份和恢复到新磁盘，我能够在不回退到备份的情况下恢复。我不确定页面撕裂错误将如何传递给 C# API，但可以想象，如果您有一个磁盘错误，该错误仅在核心已满(即它位于某个交换空间的某个位置)后才会出现，那么索引越界错误是可以想象的看起来确实像我期望的那种表现形式，因为调用可能返回垃圾 - 因此落在数组范围之外。