如何使页面文件使用率指标为零？

你应该调整PERFORMANCE ，而不是幻数。

零分页文件（交换）利用率是一个很好的目标，如果你能达到它，但如果你有足够的内存满足所有的SQL服务器的需求，而且你没有遇到性能问题，你可能不需要“调整”任何东西。 有一些数据坐在分页文件，这是永远不会被要求不会损害性能。

如果你想专注于数字，虽然我会更专注于Memory\Available Bytes （确保始终有一个健康的可用数量，其中“健康”由您的用例定义）和Memory\Pages/sec （应该是零或靠近它，表明正在交换的内容没有被主动调回RAM）。

请记住，现代操作系统通常会从RAM中提取从未请求的数据，并在系统闲置时将其置于分页文件（交换空间）中，以便有更多的RAM可用，系统不必如果在实际繁忙的时候需要内存，那么对磁盘进行混洗的性能就会受到影响。

例如，从我的（unix）数据库服务器中考虑这些统计信息：

 CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 710M Active, 730M Inact, 554M Wired, 72M Cache, 315M Buf, 862M Free Swap: 2048M Total, 910M Used, 1138M Free, 44% Inuse 

• 我有“大量”免费的RAM（800MB，没有什么比这更多的）。
• 我正在使用我的交换空间的一大块
  （因为这个服务器上有一个内存泄漏的程序， 大部分都是换出来的）
• 系统性能非常好，我的所有用户都很开心。

所以在这个时候，我不采取任何调整行动（虽然我杀死并重新启动与内存泄漏时，交换利用率达到50％）的程序。

任务pipe理器是错误的。 它实际上显示了系统提交总数。 （2008年服务器的措辞已经改变，以反映这一点。）

至于1.341％的页面文件的使用情况，这似乎相当可笑地接近于零，但我不是DBA。 即使Windows有足够的内存，对于Windows来说也是“正常的” – 如果这是你想要纠正的问题，那么也许你应该考虑在DBA网站/论坛上寻找指针。 看起来像是在dba.stackexchange.com和sqlservercentral.com上讨论了这个问题

我可能会build议首先尝试一些基准testing，看看这个1.3％是否真的影响了你的服务器的性能，然后花费大量精力去消除它。 如果它有明显的区别，我会感到惊讶 – 我认为你的性能调整工作可能会在其他地方花的更好，但正如我所说，我不是DBA，所以我可能是错的。