小编d-_*_*_-b的帖子

我们的供应商应用程序数据库是 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，VM + SAN）有 32 GB 的 RAM，数据库大小约为 80GB。该应用程序大量使用 TempDB - 磁盘读写都达到了 ~100 MBps。看到大量的 SQL 编译/秒......所有批处理请求的 95% 是编译。

理想情况下希望将 RAM 增加到 64GB 或 128GB，但需要向团队“证明”这是必需的。

缓冲区缓存命中率 (BCHR) 为 99.9%，但页面预期寿命 (PLE) 仅为 ~400。
对此有何解释？
我虽然 PLE 和 BCHR 有线性关系（即它们一起增加或减少）

在其他具有更大数据库和更多 RAM 的 VM 上，BCHR 和 PLE 都很高。

当前等待统计数据和性能计数器

表中的每一行可以是 8060 字节，因为页面大小是 8KB。如果行大小超过此值，最大的列将移动到另一个页面ROW_OVERFLOW_DATA并在原始页面上创建一个指针。

将新列添加到现有表时会发生什么？数据是否存储在表的“末尾”，并且在页面中的每个现有行之后创建指针以指向这个新数据？显然这会导致性能问题..

还是整个表格都经过重新组织，以便新列“适合”原始页面？

我们正在运行 SQL 2012（及更高版本）企业版，但也有兴趣了解较低版本。我对堆和聚集索引都感兴趣，因为在任何一个中，必须修改现有行 - 添加新列，或添加指向新列的指针，对吗？

我们有一个主分析 SP，它调用 100 个其他子 SP，所有这些都对同一组数据（声明）进行操作，检查其是否存在某些业务规则和输出差异。

SP 不需要全部按顺序运行，它们可以分成多个部分，这些部分依赖于前面的部分（顺序），但在该部分内独立（并行）。

在查看了许多选项（例如 Service Broker、Agent Jobs、Batch Files、SSIS 等）后，我使用此CLR 代码来并行化各个部分，并极大地提高了性能。

但是，当我同时运行多个 (5, 10, 15) 个主 SP（每个 SP 分析不同的声明）时，性能会随着并发性的增加而逐渐下降。我猜这是因为通过 CLR 创建多个并行线程的开销。我还看到 sp_who2 中有很多 XTP_THREAD_POOL 会话空闲。

有没有人使用 CLR 在关键 OLTP 生产工作负载中并行化存储过程？
是否有任何性能优化 SQL CLR 的最佳实践？
在开销使事情变得更糟之前，是否有可以打开的并行线程数量的阈值？
如果我的系统有 20 个内核，是否意味着创建 > 20 个并行线程没有帮助？

作为一名 DBA，我已经对 SQL 服务器进行性能调优多年。

我正在尝试创建一个快餐版的性能指标，它可以快速（在 5 分钟内）和准确（可证明）回答来自管理层的问题“此服务器需要更多/更快 _ 吗？”

“_”是 IT 堆栈自下而上的这 4 个可能的瓶颈之一（从服务器的角度来看，无需进入应用程序/代码/用户界面）：

1. 网络

2. 磁盘

3. 记忆

4. 中央处理器

有数以千计的柜台、文章、产品可以帮助监控这些。但是是否有一个简单、即时和准确的脚本可以确定这 4 个中的任何一个是否需要扩大或缩小？

例如 sys.dm_os_wait_stats - SOS_SCHEDULER_YIELD 具有高信号等待 => 需要更多或更快的 CPU。
PAGEIO_LATCH => 需要更多文件或更快的磁盘

这2个准确吗？Page Life Expectancy 是否准确地“证明”了需要更多内存？您用于诊断性能问题的GO-TO脚本是什么？

我使用过 sp_whoisactive、sp_blitz、Glenn 的 DMV、Spotlight、Idera 等，但我还没有遇到一个脚本可以满足 CIO 关于在哪里花费预算资金的问题，或者将问题正确归咎于错误代码，或者速度缓慢SAN 或 ISP。

每当任何（网络/系统/DBA/应用程序）工程师指责另一个团队时，我们都必须“证明”我们的陈述，而有了虚拟化和云，没有理想的测试环境，没有停机时间，越来越难以证明地精确定位服务器性能问题的根源，可能是任务管理器以外的<请原谅咆哮>