我们的供应商应用程序数据库是 TempDB 密集型的。
该服务器是虚拟的 (VMWare)，具有 40 个内核和 768GB RAM，运行 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 天。
在过去的 2 年中，我们已经调整了供应商的代码和 SP。
现在，我们正在考虑将 tempdb 文件放在 RAM 驱动器上，因为我们有大量内存。由于 tempdb 在服务器重新启动时被销毁/重新创建，因此它是放置在易失性内存上的理想候选者，该易失性内存在服务器重新启动时也会被清除。
我已经在较低的环境中对此进行了测试，它导致了更快的查询时间但增加了 CPU 使用率，因为 CPU 正在做更多的工作，而不是在缓慢的 tempdb 驱动器上等待。
有没有其他人将他们的 tempdb 放在高 oltp 生产系统的 RAM 上？有什么大的缺点吗？是否有任何供应商需要特别选择或避免？
首先，补丁：确保您使用的是 2012 Service Pack 1 Cumulative Update 10 或更高版本。在 SQL 2014 中，Microsoft 将 TempDB 更改为不那么急于写入磁盘，并且他们将其向后移植到 2012 SP1 CU10 ，这样可以减轻很多 TempDB 写入压力。
其次，获取延迟的准确数字。检查sys.dm_io_virtual_file_stats以查看 TempDB 文件的平均写入延迟。我最喜欢的方法是：
查看文件统计部分，并关注物理写入。自启动数据可能有点误导，因为它还包括 CHECKDB 运行的时间，这真的会影响您的 TempDB。
如果您的平均写入延迟超过 3 毫秒，那么是的，您的 SAN 中可能有固态存储，但仍然不够快。
首先考虑 TempDB 的本地 SSD。良好的本地 SSD（如英特尔的 PCIe NVMe 卡，价格低于 2000 美元，尤其是您所描述的尺寸）具有极低的延迟，低于您使用共享存储所能达到的延迟。但是，在虚拟化下，这会带来一个缺点：您无法将虚拟机从一台主机移动到另一台主机以对负载或硬件问题做出反应。
最后考虑一个 RAM 驱动器。这种方法有两个大问题：
首先，如果您确实有大量的 TempDB 写入活动，那么内存上的更改率可能会非常高，以至于您无法在没有人注意到的情况下将客户机从一台主机 vMotion 移动到另一台主机。在 vMotion 期间，您必须将 RAM 的内容从一台主机复制到另一台主机。如果它的变化真的那么快，比通过 vMotion 网络复制它的速度更快，那么您可能会遇到问题（特别是如果此框与镜像、AG 或故障转移群集有关。）
其次，RAM 驱动器是软件。在我完成的负载测试中，我并没有对它们在非常繁重的 TempDB 活动下的速度印象深刻。如果它太重以至于企业级 SSD 无法跟上，那么你也会对 RAM 驱动器软件征税。你真的很想在上线之前进行大量的负载测试——尝试在不同的索引上同时进行大量索引重建，所有这些都使用 sort-in-tempdb。
创建 RAM 驱动器应该很简单。许多可引导的 Linux 拇指驱动器和光盘驱动器创建一个 RAM 驱动器并在其中存储操作系统文件。然后根文件系统在内存中。在 Windows 中，过去，RAM 驱动器作为设备驱动程序加载到 config.sys 中。通常驱动程序被加载到高内存中。在我看来，这是一个非常好的和简单的解决方案。如果使用 RAM 驱动器创建了您的解决方案，我想听听。我想做类似的事情，但想做永久存储的写入并将数据库存储在 RAM 中。在我的情况下，我们的机器可以安装比操作系统可以使用的更多的 RAM。在操作系统加载之前创建一个 RAM 磁盘将允许使用操作系统在其他情况下看不到的 RAM。