tempdb大量闩锁等待问题分析

置顶格瑞趋势技术团队

于 2022-12-01 21:32:20 发布

阅读量453

点赞数

分类专栏：运维数据库性能文章标签：数据库

本文链接：https://blog.csdn.net/z_cloud_for_SQL/article/details/128138979

版权

性能同时被 3 个专栏收录

34 篇文章 0 订阅

订阅专栏

数据库

28 篇文章 0 订阅

订阅专栏

运维

25 篇文章 1 订阅

订阅专栏

背景

客户业务系统升级后，高峰期运行缓慢，在SQL专家云上看到数据库出现严重等待，需要分析原因并紧急处理。

现象

登录到SQL专家云中，进入实时可视化页面，在活动会话里面看到有大量资源等待的会话。

点击一个时间点，进入到该时间点的活动会话原始数据。看到大量会话的等待类型为PAGELATCH_UP，等待资源为“2：1：xxxxxxx” ，SQL语句都和临时表有关。

分析

会话等待的资源“2：1：xxxxxxx” 代表ID为 2 的数据库（tempdb）的1号文件（tempdev）的xxxxxxx页。SQL语句创建一个临时表时，相当于在tempdb中创建一张表，SQL Server要为这张表分配存储页面，需要修改SGAM、PFS、GAM系统数据页，为了其他表不会分配到同一个数据页，在修改时使用闩锁，修改完成后释放闩锁。

这种机制对一般的用户数据库不会有问题，因为正常的应用不会折腾着不停地建表、删表。但是tempdb就不同了，经常会有高并发的SQL语句使用临时表。因此在同一个时间点会有很多线程要修改系统页，就会产生大量的PAGELATCH_UP闩锁等待。

解决

最直接的解决办法是增加tempdb数据文件的个数，这样多个线程修改系统页时就被分配到不同的数据文件上，从而降低了闩锁争用。在增加数据文件时有2点重要的注意事项：

文件个数一定要和CPU核数对齐，也就是能被CPU核数整除。例如是40个核，则可以创建4个、8个、10个、20个等。建议最少4个，最多可以和CPU的核数一样多，但一般的服务器CPU核数都在几十个，没有必要创建这么多。

每个数据文件的初始大小和增长大小的配置一定要一致，如果不一致，SQL Server将不会平均地使用每个数据文件，而是先使用容量最大的数据文件。

tempdb的重要性

临时表、表变量、查询语句（ORDER BY、GROUP BY、UNION等）、触发器、索引维护、快照事务隔离级别等很多功能都会用到tempdb，详细参考微软官方文档：https://docs.microsoft.com/zh-cn/sql/relational-databases/databases/tempdb-database?view=sql-server-ver15。

最佳实践

对tempdb依赖较高的实例，可以为tempdb单独规划一个快速的物理磁盘，例如SSD，让tempdb独享I/O资源，不和用户数据库文件争抢，从而加快tempdb的响应速度。如果服务器有基于磁盘镜像的容灾软件，为tempdb规划单独的磁盘的另一个好处是不用把temdp文件同步到备机。