SQL Server 2005 内存压力和 tempdb 写入问题答案

【问题标题】：SQL Server 2005 Memory Pressure and tempdb writes problemSQL Server 2005 内存压力和 tempdb 写入问题
【发布时间】：2010-10-11 20:06:00
【问题描述】：

我们的生产 SQL Server 存在一些问题。

服务器：双四核至强 8 GB 内存单 RAID 10 阵列 Windows 2003 服务器 64 位 SQL Server 2005 标准 64 位

目前机器上有大约 250MB 的可用 RAM。 SQL Server 有大约 6GB 的 RAM，而我们的监控软件显示，实际使用的 SQL Server 分配的 RAM 中只有一半。

我们的主数据库大约为 20GB，其中大约 12GB 用于任何频率。我们的 tempdb 为 700MB。两者都位于同一个物理磁盘阵列上。

此外，使用 Filemon，我能够看到 tempdb 文件有 100 或 1000 次长度为 65536 的写入。磁盘队列长度在将近 80% 的情况下超过 100。

所以，这是我的问题-

什么会导致 tempdb 上的所有这些写入？我不确定我们是否一直有这么多活动，但这似乎过度了，而且这些问题都是最近才出现的。
我应该为服务器添加更多内存吗？
在高负载服务器上，tempdb 和 db 文件是否应该位于不同的阵列上？

【问题讨论】：

我们有一个带有热备件的 RAID-10 阵列。当我们遇到丢失磁盘的问题时，我们购买了热备件，但这些问题已得到修复，并且一年多没有问题。在备用磁盘上创建新磁盘（无 RAID）是否是提高 tempdb 性能的快速修复方法？

标签： sql-server sql-server-2005 performance tempdb

【解决方案1】：

很好的问题，+1

tempdb 在 SQL 2005+ 中使用得更多。至少：快照隔离级别，在线索引重建，在触发器中读取INSERTED/DELETED（用于读取日志文件！）

除了通常的 order by 子句、临时表等之外。

您最好将日志和数据文件分开（也为了可恢复性）。更多内存总是好的，但请参阅下面的64 bit specific stuff, Grumpy Old DBA。

最后，也许是最重要的，你可以在 tempdb 中争用空间分配：来自Linchi Shea和SQL Server storage team的解释

后期编辑：

Paul Randall 添加了一个条目“Comprehensive tempdb blog post series”，它提供了很好的链接

【讨论】：

【解决方案2】：

如果您有 SAN 或 NAS，则较高的磁盘队列长度并不意味着您有 I/O 瓶颈，您可能需要查看其他额外的计数器。查看SQL Server Urban Legends discussed了解更多详情。

1：以下操作大量使用 tempdb

重复创建和删除临时表（本地或全局）
使用 tempdb 进行存储的表变量
与 CURSORS 关联的工作表
与 ORDER BY 子句关联的工作表
与 GROUP BY 子句关联的工作表
与 HASH PLANS 关联的工作文件

这些 SQL Server 2005 功能也大量使用 tempdb：

行级版本控制（快照隔离）
在线索引重建

正如其他 SO 答案中提到的，请阅读 this article 关于提高 tempdb 性能的最佳实践。

2：查看服务器上的可用 RAM 量，即查看 WMI 计数器 Memory->Available Mbytes 无济于事，因为 SQL Server 会将数据页缓存在 RAM 中，因此任何运行时间足够长的 db 服务器将几乎没有可用 RAM .
您应该查看的更有意义的计数器是：
SQL Server Instance:Buffer Manager->Page Life Expectancy (in seconds) 低于 300-400 秒的值将意味着页面在内存中的时间不会很长，并且正在不断地从磁盘读取数据。页面预期寿命较短的服务器将受益于额外的 RAM。
和
SQL Server 实例：缓冲区管理器->缓冲区缓存命中率 这告诉您从 RAM 读取的页面的百分比不必从磁盘读取，缓存命中率低于 85 将意味着服务器将受益于额外的 RAM

3：是的，这里不会出错。建议将 tempdb 放在一组单独的磁盘上。查看标题下的this KB article：移动 tempdb 数据库了解如何执行此操作。

【讨论】：

已查看页面预期寿命和缓冲区缓存命中率（不知道为什么我没有想到这一点，因为我过去有过内存问题）。页面预期寿命为 74000，缓冲区缓存为 99.85。很确定这意味着这不是内存问题！
原来一个丢失的索引导致了我的所有问题——我可以看到磁盘队列、磁盘秒/写和磁盘秒/读取在我创建索引的那一刻急剧下降。据我所知，在 tempdb 中对 300 万条记录的表的结果进行了排序。

【解决方案3】：

不是直接回答您的问题，但这可能是一个很好的提示：重新启动 SQL Server 实例将清除 tempdb，这可能是调查在 tempdb 上执行的操作时的良好开端。

【讨论】：

感谢您的提示！我不知道为什么我没有想到这个。

【解决方案4】：

对 tempdb 的写入可以是任何内容。内部哈希表、临时表、表变量、存储过程调用等
如果您只有 250 兆的可用 RAM，那么更多的 RAM 会更好。
始终建议您将 tempdb 和用户数据库拆分到不同的磁盘。

对 tempdb 的所有写入大小为 64k，因为这是每个数据库范围的大小。

【讨论】：

【解决方案5】：

是的，对高负载服务器的建议是将 TempDB 放在与用户数据库不同的一组驱动器上：

SQL Server 2005 Books Online: Optimizing tempdb Performance

【讨论】：