我们有一个数据库服务器，我们正在升级到64GB的内存，但目前它只有小型的SCSI驱动器 – 总共超过400GB（镜像后为192GB）。 我们的数据库比较小，但是大家都告诉我们，页面文件应该是1-1.5X的RAM。 考虑到我们的小磁盘大小，我们需要设置某种types的最大容量，但是在SCSI磁盘上购买500美元仅用于页面文件存储似乎很愚蠢。
1.5倍的物理RAM只是一个指导。 在这篇Technet文章中 ，有一些关于页面文件大小的一般指针，它指出：
在服务器系统上，一个共同的目标是拥有足够的RAM，这样就永远不会有短缺，页面文件本质上是不被使用的。 在这些系统上，拥有一个非常大的页面文件可能没有用处。
但对于某些系统（域控制器，Exchange服务器）完全禁用页面文件不是一个好主意。 它是专门针对DC的 ，对于Exchange Server来说这是一个非常糟糕的主意。 我曾经在E2K7服务器上看到过那篇文章中描述的Exchange行为（分页引起的极端的磁盘颠簸），并不是那些忙于使用32G物理RAM的人，而有的人把页面文件大小设置为1G。
我从来没有发现（或听说过）任何特定的声明，表明一个分页文件是必要的SQL，除了一般的说法，它有助于如果别的东西stream氓，咀嚼所有的物理内存。
我自己也不用担心，在我们的物理MSSQL框中，我们特别closures了分页function，而我们的一些function在没有input的情况下一次运行。 也就是说，我仍然很想让Windowspipe理自己的页面文件，留意它，它会告诉你它需要多大。
正确指定dbase服务器的整个目标是为整个数据库提供足够的RAM。 你想要的最后一件事是导致磁盘I / O（交换）的SQL查询。 findMSSQL数据库文件夹并检查您的数据库/总磁盘使用情况。 在理想的情况下，你应该至less将系统内存容量加倍。 这为dbase的增长留下了足够的内存，足以满足查询caching等需求。
所以要回答你的问题，对于内存不足的系统，swap可以是1.5倍的内存，对于大容量内存的系统通常可以是8GB或更less。 如果你开始使用分页不增加交换..增加你的RAM。
我build议从大小适中的东西开始，但是比较小一点的物理记忆。 在一个32GB的盒子里，8GB的页面文件是一个不错的开始。 一旦你testing一段时间，你可以移动这个数字，如果你喜欢。 确保授予SQLserver“locking内存中的页面”权限，以便数据库服务器本身不能被分页。
关于记忆大小的一篇很好的文章，请看：