首页 > 代码库 > 《SQL Server企业级平台管理实践》读书笔记——SQL Server中关于系统库Tempdb总结

《SQL Server企业级平台管理实践》读书笔记——SQL Server中关于系统库Tempdb总结

Tempdb系统数据库是一个全局资源。可供连接到SQL Server实例的全部用户使用。

存储的内容项:

1、用户对象

用户对象由用户显示创建。这些对象能够位于用户会话的作用域中。也能够位于创建对象所用例程的作用域中。

例程能够是存储过程、触发器或用户自己定义函数。

用户对象能够是一下项内容之中的一个:

  • 用户定义的表和索引
  • 系统表和索引
  • 全局暂时表和索引
  • table变量
  • 表值函数中返回的表

2、内部对象

内部对象是依据须要由SQL Server数据库引擎创建的,用户处理SQL Server语句。

内部对象能够在语句的作用域中创建和删除。内部对象能够是下列项之中的一个:

  • 用于游标或假脱机操作以及暂时大型对象(LOB)存储的工作表
  • 用于哈希连接或哈希聚合操作的工作文件
  • 用于创建或又一次生成索引等操作(假设指定了SORT_IN_TEMPDB)的中间排序结果,或者某些GROUP BY、ORDER BY或UNION查询的中间排序结果。
  • 每一个对象至少使用9页:一个IAM页。一个8页的区。

3、版本号存储区

版本号存储区是数据页的集合,它包括支持使用行版本号控制的功能所需的数据行。主要用来支持快照(Snaphot)事务隔离级别,以及SQL Server2005推出的一些其他提高并法度的新功能。在SQL Server2005中,有两个版本号存储区:公用版本号存储区和索引生产版本号区。包括下面内容:

  • 由使用快照隔离界别或已提交读隔离界别(基于行版本号控制)的数据库中的数据改动事务生成的行版本号
  • 由数据改动事务为实现联机索引操作、多个活动的结果集(MARS)以及AFTER触发器等功能而生成行版本号

在SQL Server2005以后,tempdb须要的磁盘空间会多于早期版本号。因此当升级到SQL Server2005或SQL Server2008后。管理员提供的tempdb磁盘空间可能得比曾经要大一些,用以容纳当前生产工作负荷并满足使用tempdb的SQL Server功能的额外空间要求。

 

Tempdb空间使用跟踪

tempdb空间使用的一大特点,是仅仅有一部分对象,比方:暂时表、table 变量等。能够用sys.allcoation_units和sys.partitions这种管理视图来管理。所以用sp_spaceused的结果和真实情况会有非常大差异。

提示tempdb的空间使用是不能用sp_spaceused来跟踪的。

DBCC SHOWFILESTATS还是能够反映数据库文件使用的总体情况的。

在2005版本号以后引入了一个新的视图:sys.dm_db_file_space_usage;这张视图能反映出tempdb在例如以下几个大类的空间里使用分布:

select * from sys.dm_db_file_space_usage

技术分享

当中:

database_id:数据库ID

file_id:文件ID,file_id映射到sys.dm_io_virtual_file_stats中的file_id,而且映射到sys.sysfile中的fileid

unallocated_extent_page_count:文件未分配区中的总页数。不包括已分配区中的未使用页

version_store_reserved_page_count:为版本号存储分配的统一区中的总页数

user_object_reserved_page_count:为从统一区为数据库中的用户对象分配的总页数。计数中包含已分配区中未使用的页。

能够使用sys.allocation_units文件夹视图中的total_pages列来返回用户对象每一个分配单元保留的页计数

internale_object_reserved_page_count:从统一区为文件里的内部对象分配的总页数。

计数包含已分配区中未使用的页

mixed_extent_page_count:文件的已分配混合区中的已分配和未分配总页数。混合区包括分配给不同对象的页。此计数器包括文件里的全部的IAM页

 

通过这个表的监视。就能知道temdb的空间被那个一块对象使用掉了,是用户对象(user_object_reserved_page_count),还是系统对象(internal_object_reserved_page_count),还是版本号存储区对象(version_store_reserved_page_count)。

 

tempdb在生产环境中的设置的初始大小事实上是一个经验值,也就是说没有一个好的固定值,可是我们能够依据工作负荷来确定该值的大小值:

1、设置tempdb的自己主动增长

2、模拟各个单独的查询或工作任务,同一时候监视tempdb空间使用

3、模拟运行一些系统维护操作。比如,又一次生成索引,同一时候监视tempdb空间

4、使用前面2和3步中tempdb空间使用值来预測总的工作负荷下,会使用多少空间;并针对计划的并发度调整此值。比如,假设一个任务会使用10GB的tempdba空间,而在生产环境里。最多可能会有4个这种任务同一时候执行,那就要至少预留40GB的空间。

5、设置tempdb在生产环境下的初始大小。

同一时候也開始自己主动增长。

 

Temp文件个数以及大小设置。不但满足用户任务的需求。还要考虑到性能优化。

 我们利用脚本来跟踪一下,看看是什么样的操作导致了SQL Server要这样大规模的使用tempdb,然后分析一下是正常行为还是异常行为,监视SQL Server的行为当然能够利用SQL Trace来完毕。但是管理员并不能预期造成大量使用tempdb的语句会在什么时刻执行。这些语句可能一周仅仅做一次。

并且开跟踪毕竟对SQL Server来讲是一个比較昂贵的事情,就算没有性能副作用,假设一直开着SQL Trace,也会产生大量的跟踪文件,对硬盘是个比較重的负担。

推荐的“轻量级”的操作是以一定的时间间隔执行可以监视系统执行状况的DBCC命令、查询管理视图(DMV)以及管理函数(DMF)等。把这个结果输出到一个文件中。

新开一个连接,我们输入下面常规脚本:

技术分享
select @@SPID
go
use AdventureWorks
go 
select GETDATE()
go 
select * into #MyOrdersDetail
from Sales.SalesOrderDetail
--创建一个暂时表
--这个操作应该会申请用户对象页面
go
waitfor delay 0:0:2
select GETDATE()
go
drop table #MyOrdersDetail
--删除一个暂时表
--这个操作用户对象页面数量应该会下降
go
waitfor delay 0:0:2
select GETDATE()
go
select top 100000 * from
[Sales].[SalesOrderDetail] 
inner join [Sales].[SalesOrderHeader] 
on [Sales].[SalesOrderHeader].[SalesOrderID] =
[Sales] .[SalesOrderHeader].SalesOrderID;
--这里做了一个比較大的连接。应该会有系统对象申请
go
select GETDATE()
--join 语句做完以后系统对象页面数目应该会下降
go
技术分享

然后另开一个窗体,我们输入监控脚本。输出结果以文本方式存储

技术分享
use tempdb
--每隔1s执行一次。直到用户手工终止脚本执行
while 1=1
begin
select GETDATE()
--从文件级看temp使用情况
dbcc showfilestats
--第一个会话
--返回全部做过空间申请的会话信息
select Tempdb as DB,GETDATE() as Time,
sum(user_object_reserved_page_count)*8 as user_obectskb,
SUM(internal_object_reserved_page_count)*8 as internal_objects_kb,
SUM(version_store_reserved_page_count)*8 as version_store_kb,
SUM(unallocated_extent_page_count)*8 as freespace_kb
from sys.dm_db_file_space_usage
where database_id=2

--第二个会话
--这个管理视图可以反映当时tempdb空间的整体分配
select t1.session_id,
t1.internal_objects_alloc_page_count,
t1.user_objects_alloc_page_count,
t1.internal_objects_dealloc_page_count,
t1.user_objects_dealloc_page_count,
t3.*
from sys.dm_db_session_space_usage t1,
--反映每一个会话累计空间申请
sys.dm_exec_sessions as t3
--每一个会话信息
where 
t1.session_id=t3.session_id
and (t1.internal_objects_alloc_page_count+t1.internal_objects_dealloc_page_count+t1.user_objects_alloc_page_count+t1.user_objects_dealloc_page_count)>0

--第三会话
--返回正在执行而且做过空间申请的会话正在执行的语句
select t1.session_id,
st.text
from sys.dm_db_session_space_usage as t1,
sys.dm_exec_requests as t4
cross apply sys.dm_exec_sql_text(t4.sql_handle) as st
where t1.session_id=t4.session_id
and t1.session_id>50
and (t1.internal_objects_alloc_page_count+t1.internal_objects_dealloc_page_count+t1.user_objects_alloc_page_count+t1.user_objects_dealloc_page_count)>0

waitfor delay 0:0:1
end
技术分享

我们先执行监控,然后再执行一般脚本,能够分析一下跟踪结果。

能够看到在新建暂时表的时候,对于Tempdb的申请空间有所添加。 四川www.sczygb.com/

《SQL Server企业级平台管理实践》读书笔记——SQL Server中关于系统库Tempdb总结