SQL Server-强制在内存中使用DB？

我们拥有功能强大的Windows 2008 x64服​​务器（4 x 4核心CPU，32GB RAM），运行SQL Server 2005 64位。我们有一个很小的（6GB）但非常重要的数据库，在将页面缓存到内存之前，它的访问速度有些慢（使用情况是非常随机的I / O，因此给定页面在内存中以及最终用户的可能性非常低抱怨最初的缓慢）。磁盘足够快（本地15K SAS），但我猜该应用程序编写得有些笨拙（这是一个COTS解决方案），所以我想知道是否有办法“强制” SQL Server 2005中的内存中的数据库（不支持2008年）由供应商提供，所以我们还不应该升级到该版本），以帮助避免最初出现的高速缓存填充蓝调？

我当前的方法是我从脚本中的每个表运行SELECT *以获取内存中的数据页，但是此方法未缓存某些对象（索引，全文本搜索等）（并修改了脚本以查询索引和编写适当的WHERE子句进行缓存是煮沸的海洋复合物）。

不，不幸的是，没有办法将数据库强制进入缓存。您的蛮力方法可能是最简单的方法。您可以通过使用阈值设置非常低的索引碎片整理脚本来获得更近的距离，例如说如果索引的碎片为1％，则重建索引，如下所示：

http://sqlserverpedia.com/wiki/Index_Maintenance

这将花费更长的时间并涉及更多的磁盘写入操作，但会产生使索引碎片整理和更新统计信息的副作用，无论如何这都是一个好主意。

好的-我无法评论布伦特的答案（但是，由于我的代表不多）-但是，如果您要进行碎片整理，则不必重新建立索引-这样会建立新的索引，如果没有足够的可用空间，则可能会扩展数据库，并确保您的下一个日志备份至少为索引大小，并且日志中也可能包含大量的日志记录（取决于恢复模型）。如果您要进行碎片整理，请执行ALTER INDEX ... REORGANIZE，它不需要任何可用空间（一个8k页），但是会将叶级读取到内存中，并且仅对碎片进行操作页面。在查询后，非叶级别应该很快进入，并且（取决于扇出）数据应该比叶级别少得多。

为什么首先要从缓存中清除数据库对象？您要重新启动SQL服务还是使数据库离线/联机？还是从其他数据库缓存中将它们推出？

问候，

单片机。

如果数据库这么小，请考虑将其放在SSD上？

我曾遇到过一些情况，即使用FULLSCAN更新关键表上的统计信息，从而迫使数据进入缓存，并使我围绕这些表的后续DML更快。这不是过期统计信息的结果，因为它不会导致执行计划发生任何变化。

为什么不安装仅具有该数据库的第二个 SQL Server 实例，并将该实例的最小内存设置为6GB？

这将确保您的其他数据库永远不会从“小型但非常重要”的数据库中窃取内存。

这也意味着您可以使另一个实例脱机，并且小型DB将保留在内存中。

我会使用探查器来检查您的SQL。将“逻辑”读数与“物理”读数进行比较。SQL Server很聪明，将使用其所需的RAM以获得最有效的结果。

还要检查您的自动统计信息是否最新。

如果没有更多关于查询类型和数据库表大小的想法，这听起来有点奇怪。