我们的供应商应用程序数据库是 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 上?有什么大的缺点吗?是否有任何供应商需要特别选择或避免?