SQL Server 2005中Tempdb变化分析


SQL Server 2005版本中的所有变化可以写成一本书,事实上,已经被写成了好几本书。其中,最重要的变化不是功能上的变化;这些变化发生在用户或者管理员无法立刻感觉到的内部的行为上。这就是说,了解到它们是什么,它们在什么状况下会表现出来,将会很有用。

这些的隐藏起来的性能提升中最好的一个例子就是tempdb数据库——SQL Server用于临时或者开关操作的数据库。对tempdb所做的很多优化都是在透明的情况下,让处理加速:

◆当临时表被创建的时候,临时表会被缓存起来加速性能。然而,有一些表明确的不会被缓存:

◆关联着显式DDL的临时表

◆关联着命名的约束的临时表

◆作为动态产生的SQL语句的一部分的临时表——例如,存储过程sp_executeSQL的环境中

◆工作表的缓存得到提升。为了节约了空间,会被反复执行的执行计划中的工作表被截短了;现在只有工作表中的前九个页面才会保留。

◆很多其他类型的临时对象也被缓存以提高速度:当在存储过程、函数或者触发器中使用时,表值函数,表变量和局部临时表都会被缓存。对于某种特定的临时对象的编目条目不会被立即丢弃,而是缓存以备将来的重用(一段时间之后,最少使用的对象将从缓存中清除)。

◆对于tempdb中记录的一些修改将不再被记录到日志中,这样可以降低tempdb产生的日志和设备的I/O流量。INSERT操作只会记录插入的记录,DELETE操作只会记录被删除的记录。只有UPDATE操作才会同时记录原值和更新之后的值。(根据Microsoft的内部资料,在此之前的版本,三种操作都会记录操作之前的值和操作之后的值)

◆重新设计tempdb的文件被均衡写入的方式,减少对系统资源的竞争。均衡写入意味着每一个tempdb文件(假设存在多个文件)会被同时写入。因此,如果每个物理文件分散到不同的磁头上,那么对这些文件的写入可以更加有效率的并行处理。建议你为一个SQL Server在每一个CPU创建一个临时文件,并且将每个临时文件放在不同的磁头上。

◆如果一个临时表从tempdb中被丢弃,它会在后台进行处理以降低主机程序的等待时间。实际上,它会被立即处理。

不仅仅是性能,一些变化也影响到了SQL Server 2005的统计收集操作:

◆SQL Server 2005的动态管理视图(Dynamic Management Views)报告关于tempdb空间使用情况的统计数据,可以通过查询检索到这些数据。例如,SELECT SUM (unallocated_extent_page_count)*8 as [Free Space] FROM sys.dm_db_file_space_usage会返回tempdb文件中以kilobytes计算的自由空间总数。

◆Trace标志TF-1118(表示分配整个的extents给每个tempdb对象)已经被重新改造,减少资源的竞争。你可以用它作trace检查而不用担心对tempdb性能产生影响。

◆两个新的性能指标,临时表新建率(Temp Tables Creation Rate)和临时表销毁计数(Temp Tables for Destruction),在SQL Server 2005中出现。它们分别指示每秒钟新建多少个临时表和多少个临时表在排队销毁。

这些变化可以让程序员对tempdb实际的运行方式有一些洞察,而不是被它表面上的行为所蒙蔽——毫无疑问,一个创新的程序员可以利用这些来写出更好的、更先进的SQL Server 2005代码。

 

本文作者:
« 
» 
快速导航

Copyright © 2016 phpStudy | 豫ICP备2021030365号-3