我有一台在 Windows 2003 R2 服务器上安装了 SQL Server 2008 Standard 的计算机。我会定期（大约每小时一次）连续多次收到事件 ID 17890。例如：
6:28:54 “很大一部分 SQL Server 进程内存已被分页。这可能会导致性能下降。持续时间：0 秒。工作集 (KB)：10652，已提交 (KB)：628428，内存利用率：1%%。
6:34:27 “SQL Server 进程内存的很大一部分已被调出。这可能会导致性能下降。持续时间：332 秒。工作集 (KB)：169780，已提交 (KB)：546124，内存利用率：31%%。”
6:38:55 “很大一部分 SQL Server 进程内存已被分页。这可能会导致性能下降。持续时间：600 秒。工作集 (KB)：245068，已提交 (KB)：546124，内存利用率：44%%。”
这种模式在 7:26 - 7:37、8:26 - 8:36、9:24 - 9:35 重复出现，因此工作集和内存利用率也呈现相同的增长模式。我目前没有运行任何（已知的）后台任务。备份在 2:00 运行
这种情况从晚上 11 点开始逐渐平息，直到凌晨 4 点才再次发生，并且一直持续间歇性 10 分钟的故障期。
由于这台服务器有足够的 RAM（提交费用已达到 4,194,012 个物理 RAM 中的 2,871,564 个），我在阅读了我在 Google 上搜索到的几个项目后禁用了分页文件，但没有发现任何可以改变这种情况的东西。我记录的这种模式是后删除页面文件，所以我甚至不确定我们正在对 SQL 进程进行分页。我还将 SQL 进程内存更改为最低 500MB 和最高 2GB RAM（因为这是一个轻型数据库服务器，仅为小型工作组提供服务）。
有人遇到过这种情况吗？在禁用页面文件之前，此错误会导致 5 分钟的磁盘抖动，从而禁用对数据库、文件、IIS 网站等的访问。自从禁用页面文件以来，它只是记录了一些奇怪的事情，但我至少没有看到性能下降。欢迎提出任何建议。
答案1
与微软支持人员交谈后，官方答复是：http://support.microsoft.com/kb/2001745
不会修复，不会解决问题，仅建议将操作系统升级到 2008 的某些版本。我已经移动了我的 SQL 安装并退役了服务器。
答案2
最好的办法是运行一些分析来捕捉事件。最有可能的是，这是一个单一的错误查询，由于错误的 where 子句或糟糕的索引，需要提取一个大表。这更多地取决于表的大小和整个数据库。
在对问题进行一两次分析之后，您应该能够将问题缩小到需要调整的一两个查询。
另一件需要检查的事情是 IIS 应用程序池和工作线程的设置。如果在应用程序启动中为站点添加了繁重的代码，那么当工作线程再次启动时，它们将不得不运行该代码。在一定量的空闲时间、过多的 CPU 时间或使用过高比例的资源后，IIS 会终止工作线程。基于计时器的线程可能是问题所在，这会导致它在夜间空闲时间发生。另一个问题可能是搜索索引器在夜间访问站点。
答案3
遇到了同样的问题，这是由于卡巴斯基防病毒软件每隔一小时左右尝试自我更新而导致的。卸载卡巴斯基解决了这个问题。