我有一台在Windows 2003 R2服务器上安装了SQL Server 2008 Standard的计算机。 定期（大约每小时一次），我连续多次获得事件ID 17890。 一个例子：
工作集（KB）：10652，提交（KB）：628428，内存使用情况：内存使用情况： 1 %%。
工作集（KB）：169780，已提交（KB）：546124，内存利用率： 31 %%“。
（KB）：245068，已提交（KB）：546124，内存使用情况：已安装的服务器进程内存的一个重要部分已经被分页出来，这可能会导致性能下降。 44 %%“。
这种模式在7:26 – 7:37，8:26 – 8:36，9:24 – 9:35重复，同样增加了工作集和记忆的使用模式。 我目前没有任何（已知的）后台任务正在运行。 备份在2:00运行
从晚上11点开始，直到早晨4点恢复正常，一直持续10分钟的间歇性故障。
由于这台服务器有足够的内存（提交费已经达到4,194,012个实体的2,871,564个），所以我在阅读了几个项目之后禁用了分页文件。我search了Google，但没有发现其中的任何一个正在改变这种情况。 我logging的这种模式是在删除分页文件后，所以我甚至不知道我们在哪里分页SQL过程可能会。 我也改变了SQL进程内存至less有500MB和最大2GB的内存（因为这是一个轻型数据库服务器只服务于一个小型的工作组）。
有没有人遇到过这个？ 禁用页面文件之前，这个错误会导致5分钟的磁盘抖动，禁止访问数据库，文件，IIS网站等。 由于禁用页面文件，它只是logging奇怪的事情，但我没有看到性能下降至less。 欢迎大家提出意见。
与Microsoft支持部门交谈之后，官方回答是： http : //support.microsoft.com/kb/2001745
不会修复，不会解决方法，只推荐将操作系统升级到2008的某些版本。我已经移动了我的SQL安装并退役了服务器。
最好的办法是运行一些分析来捕捉事件。 最有可能的是这是一个单一的错误查询，需要一个大的表，由于一个糟糕的where子句或索引不佳。 这更依赖于表和数据库的整体大小。
在分析问题一两次之后，您应该能够将问题缩小到一个或两个需要调整的查询。
另一件要检查的是IIS的应用程序池和工作人员的设置。 如果你的应用程序启动中有大量的代码，那么当工作人员重新启动时，他们将不得不运行该代码。 IIS会在一定的空闲时间，CPU时间过长或使用过高的资源百分比之后，终止工作线程。 基于计时器的问题可能会成为问题，这将导致它在晚上的闲置时间发生。 另一个问题可能是search索引者在晚上点击该网站。
有同样的问题，这是由卡巴斯基反病毒每小时尝试更新自己造成的。 卸载卡巴斯基解决了它。