SQL Server tempdb在RAM磁盘上？

我们的供应商应用程序数据库非常占用TempDB。

该服务器是具有40个内核和768GB RAM的虚拟服务器（VMWare），运行SQL 2012 Enterprise SP3。

包括TempDB在内的所有数据库都位于SAN的1层SSD上。我们有10个tempdb数据文件，每个文件已预先增长到1GB，并且它们从未自动增长。与70GB日志文件相同。跟踪标志1117和1118已设置。

sys.dm_io_virtual_file_stats显示过去一个月在tempdb数据和日志文件上读取/写入的数据超过50 TB，累积io_stall为250小时或10天。

在过去的两年中，我们已经调整了供应商的代码和SP。

现在，我们正在考虑将tempdb文件放置在RAM驱动器上，因为我们有大量的内存。由于tempdb在重新引导服务器时被破坏/重新创建，因此它是放置在易失性内存中的理想选择，该易失性内存在重新引导服务器时也会被清除。

我已经在较低的环境中对此进行了测试，它可以缩短查询时间，但可以增加CPU使用率，因为CPU可以做更多的工作，而不是等待慢的tempdb驱动器。

还有其他人将tempdb放在高oltp生产系统的RAM上吗？有什么主要的不利条件吗？是否有任何供应商专门选择或避免？

首先，打补丁：确保您使用的是2012 Service Pack 1累积更新10或更高版本。在SQL 2014中，Microsoft将TempDB更改为不急于写入磁盘，他们将其很好地反向移植到了2012 SP1 CU10上，从而可以减轻很多TempDB的写压力。

其次，获取延迟的确切数字。检查sys.dm_io_virtual_file_stats以查看您的TempDB文件的平均写入停顿。我最喜欢的方法是：

sp_BlitzFirst @ExpertMode = 1, @Seconds = 30 /* Checks for 30 seconds */
sp_BlitzFirst @SinceStartup = 1 /* Shows data since startup, but includes overnights */

查看“文件统计信息”部分，重点关注物理写入。因为BeginStartup数据还包括CHECKDB运行的时间，所以它可能会误导您，这确实会影响您的TempDB。

如果您的平均写入延迟超过3毫秒，那么可以，您的SAN中可能有固态存储，但是仍然不够快。

首先考虑用于TempDB的本地SSD。好的本地SSD（例如Intel的PCIe NVMe卡，价格不到2k美元，尤其是在您描述的大小下）具有极低的延迟，低于共享存储所能达到的。但是，在虚拟化环境下，这样做有一个缺点：您无法将客户机的vMotion从一台主机移动到另一台主机，以对负载或硬件问题做出反应。

最后考虑一个RAM驱动器。这种方法有两个大陷阱：

首先，如果您确实有大量的TempDB写活动，则内存上的更改率可能会很高，以致您无法在没有所有人注意的情况下将guest虚拟机从一台主机移动到另一台主机。在vMotion期间，您必须将RAM的内容从一台主机复制到另一台主机。如果更改的速度确实快于您通过vMotion网络复制的速度，则可能会遇到问题（尤其是此框涉及镜像，AG或故障转移群集时）。

其次，RAM驱动器是软件。在完成的负载测试中，在繁重的TempDB活动下，它们的速度并没有给我留下深刻的印象。如果太沉重以至于企业级SSD无法跟上，那么您也将向RAM驱动器软件加税。您确实要在上线之前进行大量负载测试-尝试使用不同的索引在大量索引上同时进行索引重建，所有这些都使用sort-in-tempdb。

创建RAM驱动器应该很简单。许多可引导的Linux拇指驱动器和光盘驱动器创建RAM驱动器并将OS文件存储在那里。然后，根文件系统在内存中。早在Windows中，RAM驱动器已作为设备驱动程序加载到config.sys中。通常，驱动程序已加载到高内存中。我认为这是一个非常好的简单解决方案。如果已经使用RAM驱动器创建了您的解决方案，那么我想听听。我想做类似的事情，但想写永久存储并将db存储在RAM中。就我而言，我们的计算机可以安装更多的RAM，而操作系统无法使用。在操作系统加载之前创建RAM磁盘将允许利用操作系统无法看到的RAM。