标签：资源竞争   检查   struct   time   png   方便   html   新版   src   

前面文章针对CPU、内存、磁盘、语句、等待讲述了SQL SERVER的一些基本的问题诊断与调优方式。为了方便阅读给出导读文章链接方便阅读：

SQL SERVER全面优化-------Expert for SQL Server 诊断系列

　　　　这篇我们来说说TempDB，这个系统数据库如何进行优化，怎么样平衡他的使用。

　　　　首先简单介绍一下TempDB：Tempdb是SQL Server里的一个重要的系统数据库。并且每个实例中只有一个TempDB，也就是当你在一个实例下创建了100个数据库，这100个数据库也只能用这一个TempDB。是不是感觉到了他的压力会很大？还没完呢！许多用户的操作，都有可能使用到它。最常见的当然是用户使用临时表或者表变量。其他可能性有，用户使用trigger，Snapshot Isolation Level，某些复杂的查询，以及DBCC CHECKDB等。听起来这是要爆炸的节奏呀！他不会爆炸，这么说只是想你提高对他的关注性，很多系统性能问题就出在他身上！

　　　　一如既往还是用一个例子说明: 语句相当于“车”，硬件相当于 “路” ，等待相当于 “红绿灯”，那么TempDB 相当于什么呢？ “服务区停车场”

--------------博客地址---------------------------------------------------------------------------------------

Expert 诊断优化系列 http://www.cnblogs.com/double-K/

废话不多说，直接开整-----------------------------------------------------------------------------------------

TempDB压力从哪来？

　　　　当数据库创建一张新表的时候，SQL Server要为这张表分配存储页面，同时SQL Server也要修改SGAM, PFS, 和GAM页面，把已经分配出去的页面标志成已使用。所以每创建一张新表，SGAM, PFS, 和GAM这些系统页面都会有修改动作。这种行为对一般的用户数据库不会有问题，因为正常的应用不会折腾着不停地建表、删表。但是tempdb就不同了。如果一个存储过程使用了临时表，而这个存储过程被并发用户广泛使用，那很自然地就会有很多并发用户在tempdb里同时创建表，做完了以后又删除表。这样，在一个时间点，会有很多任务要修改SGAM, PFS, 或GAM页面。但是为了维护物理的一致性，对于同一个页面，SQL Server在一个时间点同时只允许一个用户修改它。所以对于tempdb，如果同时有很多很多人要在同一个数据文件里分配空间，那这个数据文件的SGAM, PFS, 或GAM页面，就有可能成为系统瓶颈。大家只能一个一个做，并发度上不去。

　　　　这就好像你进停车场要登记交费一样！一个一个来不要急~

　　　　直接上例子: 

　　　　等待资源为 ： “2：1：3” 这是什么意思？ ID 为 2 的数据库（TempDB）的 1号文件 的 页码为3的页（SGAM页面）！

　　　　这里关于系统页不过多的介绍，想详细了解的朋友请参见 ：  SQL Server中的GAM页和SGAM页

我创建个临时表跟系统页还有关系？

　　　　下面也用一个例子说明 ： 

　　　　创建临时表的时候会对系统表中进行插入和更新，而删除临时表逆向过程会删除或更新系统表！

use [AdventureWorks2012]
GO
checkpoint
go
create table #t
(
id int
)
drop table #t


use tempdb
go
select Operation,CONTEXT,[Transaction ID],AllocUnitId,AllocUnitName,[Page ID],[Transaction Name],Description from fn_dblog(null,null)

　　　　所以当你并发过高且频繁创建删除临时表的时候就会造成大量的争用。

TempDB问题简单处理

　　　　上面描述的看起来好像需要对SQL SERVER掌握的很深，才能处理这个问题。其实很简单 ，只需要你做一件事情就可以搞定TempDB的大部分问题！那就是把TempDB设置成多个来分摊这个压力。

　　　　“服务区停车场” 可以设置多个收费口来避免拥堵和排队！

分成多个文件

　　　　作为一般规则，如果逻辑处理器数小于或等于 8，使用和逻辑处理器相同数量的数据文件。如果逻辑处理器数大于 8 时，使用 8 个数据文件，然后如果仍然存在争用，增加数据文件数4 的倍数（最多的逻辑处理器数）直到争用降低到可接受的程度或对工作负荷/代码进行更改。

　　　　在网上流传的各种TempDB 配置文档中，都描述的是使用逻辑处理器相同数量的数据文件。一般情况下是没什么问题，但是有一点需要注意：如果程序中有内存不足蔓延到tempDB的情况，或频繁的使用数据量大的临时数据Worktables 等，性能反而会下降，因为你的文件被分成多个，但数据写入的时候就需要轮循（round-robin），简单理解这样会有一定的时间损失，且读取的时候随机IO 也会多消耗IO资源和时间。有兴趣的朋友可以详见 ：

A SQL Server DBA myth a day: (12/30) tempdb should always have one data file per processor core

　　　　这里说的看官们好像也不知道我该使用几个了...对于系统最佳实践，非常精细化的优化时可能才需要考虑上面的问题，对于一般系统TempDB一般可以配置成8 或16 个Temp文件就足够了，如果还有大量争取就继续增加（一般情况不要超过你的逻辑CPU数量）。

文件大小、增长率要相同

　　　这里需要注意一个小细节，你所分配的文件必须大小一致，如果设置自动增长那么增长率要相同。

TempDB磁盘划分

　　  大多数情况下，TempDB的文件不需要拆分磁盘，在同一个磁盘即可，如果压力大可以选择放置在一个单独的磁盘中，这样不会与其他文件（如数据读写）发生磁盘资源竞争。

　　　　如果出现TempDB 读取响应时间高的情况，请考虑，TempDB的磁盘相关优化。

TempDB压力诊断

等待类型诊断

　　TempDB的争用压力在等待篇中已经简单介绍，等待的表现为 pagelatch_类等待，等待的资源是 “2： X ：X ”

计数器诊断

　　计数器中我们主要看以下几个计数器：

1. Workfiles Created/sec 
2. Worktables Created/sec 
3. Active Temp Tables　　
4. Temp Tables Creation Rate
5. Temp Tables For Destruction　　　

　　这里的标准各不相同就不细说了。

通过对象分布诊断

　　　　TempDB中对象可分为三种：

• 显式创建的用户对象

　　这些对象由用户显式创建。存在于用户会话的作用域中，也可位于创建对象所用的例程（存储过程、触发器或用户定义函数）的作用域中。

　　包括：表和索引（系统的，或用户定义的）、临时表和索引（全局的，或局部的）、表变量、表值函数中返回的表。

• 数据库引擎创建的内部对象

　　这些内部对象由数据库引擎根据需要而创建，用于处理SQL Server语句。可以在语句的作用域中创建和删除。每个内部对象至少使用9个页面：1个IAM页，1个连续8页的区。

　　包括：用于游标或假脱机操作以及临时大型对象（LOB）存储的工作表；用于HASH连接或HASH聚合操作的工作表；用于创建或重新生成索引等操作（如果指定了SORT_IN_TEMPDB）的中间排序结果，或者某些GROUP BY、ORDER BY或UNION查询的中间排序结果。

• 版本存储区

　　版本存储区是数据页的集合，它包含支持使用行版本控制的功能所需的数据行，主要用来支持快照事务隔离级别，以及一些其它提高数据库并发性能的新功能。主要分为2类：公用版本存储区、联机索引生成版本存储区。

　　包括：由使用快照隔离级别或已提交隔离级别（基于行版本控制）的数据库中的数据修改事务生成的行版本；由数据修改事务为实现联机索引操作、多个活动的结果集（MARS）以及AFTER触发器等功能而生成的行版本。

　　脚本奉上 ：

SELECT ‘tempdb‘ AS DB,GETDATE() AS TIME,
SUM (user_object_reserved_page_count)*8 as [用户对象(kb)], ----如临时表的使用
SUM (internal_object_reserved_page_count)*8 as [内部对象(kb)], -----如连接hash 使用的空间
SUM (version_store_reserved_page_count)*8  as [纪录版本空间(kb)],
SUM (unallocated_extent_page_count)*8 as [可用空间(kb)],
SUM (mixed_extent_page_count)*8 as [mixedextent(kb)]
FROM sys.dm_db_file_space_usage

　　　高能预警：如果用户对象分配空间持续使用很大，基本可以说明你的程序代码中过度依赖TempDb 过并发高的存储过程中有大量的临时表使用。如果内部对象持续很高，说明你的程序中有很多语句写法可以优化（如排序、hash join溢出，游标等等）

TempDB和语句调优

　　　　语句调优篇提到语句中使用临时表或表变等会减少语句的复杂度，提升语句的效率，是常用的三板斧之一，但这里的需要一个平衡。如果对语句过度使用会造成文中提到的TempDB压力。那么怎么样平衡呢？下面给出几点建议：

1. 切记不要过度使用！临时表的使用主要有两个场景，拆分语句降低复杂性。另一个是缓存中间结果避免重复操作。
2. 减少使用临时表锁系统表的时间！”select 字段 into #临时表 from“ 如果语句执行时间过长这将是灾难，尽量选用先创建，后插入的做法。
3. 临时表也是有缓存的，查找哪些对象没有被缓存，为什么发生这样的情况！参见 ：Sql Server tempdb原理-缓存机制解析实践

SQL SERVER 2016版本小福利

　　2016 已经发布了 在2016中做了如下改动：

　　　高能预警： 2016中默认的TempDB 文件数量也和本文讲述的TempDB配置个数相符合哦~~~~

--------------博客地址---------------------------------------------------------------------------------------

Expert 诊断优化系列 http://www.cnblogs.com/double-K/

-----------------------------------------------------------------------------------------------------

　　总结：TempDB经过添加多个文件，基本可以避免成为瓶颈。

　　　　　TempDB添加的文件一定要大小一致，增长率一致，否则不会起到效果。

　　　　　使用临时表等对语句优化是常用手段，但一定要保持一个平衡，切勿过度使用。

　　　　　 通过语句优化一样能降低TempDB压力，如检查执行计划，是否有一些计划创建了大量的临时对象、假脱机、排序或者工作表。对此，你需要把一些临时对象清理掉。比如，在列中创建用于order by的索引可以考虑移除排序。

　　　　　TempDB的文件分配是优化的常规配置。

 ----------------------------------------------------------------------------------------------------

原创链接：http://www.cnblogs.com/double-K/archive/2016/06/02/5538249.html

系列文章导读请关注 ：  SQL SERVER全面优化-------Expert for SQL Server 诊断系列

Expert 诊断优化系列------------------给TempDB 降温

标签：资源竞争   检查   struct   time   png   方便   html   新版   src   

原文地址：https://www.cnblogs.com/binghou/p/9171644.html