（译）走进SQL Server 2005 tempdb数据库（四）

    对于一个应用程序来说，评估tempdb数据库的大小是非常困难的。这篇文章介绍了评估tempdb数据库所需大小的一般方法。这些方法可能不够精准，需要相当的经验和测试才能获得满意的结果。为了安全起见，建议你总是考虑多余评估大小20%的空间大小，同时也是为了考虑应用程序将来的数据增长。

    为了能明白tempdb数据文件所需要的磁盘空间大小，首先需要先弄清楚SQL Server 2005中，哪些特性使用了tempdb。对于每个特性，其磁盘空间需求是不一样的。下面就是会用到tempdb空间的特性列表：

 

    .   查询

    .   触发器

    .   快照隔离级别以及读写快照（RCSI）

    .   MARS

    .   联机的索引创建

    .   临时表，表变量，以及表值函数

    .   DBCC CHECK

    .   LOB参数

    .   游标

    .   Service Broker以及事件通知

    .   XML以及LOB变量

    .   查询通知

    .   数据库邮件

    .   索引创建

    .   用户定义函数

 

一个服务器实例可能使用一些或者所有的特性。对于一些服务器，可能一到两个特性对于占用tempdb空间占主要地位。如果是这种情况，我们就应该努力的集中大部分规划在这些特性上。例如，可能你发现，某台服务器，在高峰期间，查询所需要的tempdb空间为50GB，RCSI所需要的为20GB，剩下的其他只需要1GB的tempdb空间，那么你就需要分配85GB（71GB+20%多余的）的tempdb大小。

 

.查询所需要的空间大小

 

    应用程序通常向SQL SERVER发送大量的查询请求。如果连续的向SQL SERVER发送查询请求，那么tempdb所需空间的峰值则由这些需要占用tempdb空间大小的查询决定。如果这些查询几乎在同一时刻被执行，则所需要的总的tempdb空间则是这些需要占用tempdb空间的所有查询的总和。

    SQL SERVER有一个基于成本的查询优化器。它会选择一个最低成本的查询计划，但在tempdb上，它忽略了一些问题。结果，对于一个查询，它所需要的tempdb空间会有所不同，这依赖于它的执行计划。在一些情况下，查询优化器决定的最优的查询计划比相对的其他比较优化的查询计划需要更多的tempdb空间。同样，当应用程序是从SQL SERVER 2000升级上来，一个查询计划的改变会需要更多的tempdb空间。

    对于容量的规划，准备考虑最坏的情况。一个查询会因为tempdb的空间大小错误而失败。在一些情况下，可以使用自动增长来扩展tempdb文件直到填慢所有的磁盘大小。

    考虑查询所需要的最大tempdb大小，可以查看执行计划。在SQL SERVER里，有很多方法可以查看执行计划。SQL Server Manage Studio可以显示正在使用的查询计划，或者以绘画的方式评估一个查询计划。关于更多查询计划的内容，请参考联机帮助相关章节。

    下面列表是通常需要使用到tempdb空间的操作。这些每一个操作消耗了一些的行数以及输出了一些行数。

 

    .排序（包括distinct排序）

        排序操作需要tempdb空间排序整个纪录集（这些纪录集是通过排序操作产生）

 

    .HASH匹配

        这个操作有两个输入-一个是HASH表，一个是探测表。所需要的tempdb空间依赖

        HASH表的大小，可以看第一个输入操作的返回行数和行大小。

 

    .Spool(包括表spool,非聚集索引spool)

        这个操作需要在tempdb存储整个的输入纪录集。

 

评估每个操作所需要的tempdb空间，可以看操作报告出的行数和行大小。计算所需要的空间大小，通过评估的行大小乘上实际（或评估）的行数。需要注意的是，因为不正确的统计信息或者其他原因，评估的行数和行大小可能是不准确的。请在你对数据的认识基础上调整这些评估。

 

.其他特性所需要的空间大小

 

 

    临时表，表变量，以及表值函数都需要使用tempdb空间。应用程序严格的控制了这些对象由多少纪录产生。因此，应该如同用户表一样评估他们所需要的空间占用。LOB变量（包括参数）以及XML变量也同样需要使用tempdb空间。这是SQL SERVER2005的新特性。在SQL Server2000里，这些变量只是常驻内存。LOB或者XML表达式的中间结果也同样需要使用tempdb空间。评估空间需求，看看逻辑设计并设法找到一个合理的上线值。DBCC CHECK操作在内部产生一个查询来验证数据的一致性，这个执行计划不能被显示，然而，这个命令有一个选项可以评估它所需要的tempdb空间。如果你怀疑可能没有足够的tempdb空间了，请在运行这个命令前，评估一下。否则应用程序可能会因为DBCC CHECK需要足够的tempdb空间而失败。

    Service Broker每个会话使用1MB的空间。如果应用程序开启了很多会话而没有关闭它们，空间使用会成为一个问题。其他功能也一样，例如事件通知。

    索引创建有一个选项是在tempdb排序。排序所需要的空间如同索引被创建所需要的一样。对于联机索引创建，我们可能同样需要一个MAPPING索引。计算这个索引的大小，用行数乘以平均的索引键大小。

    两种服务器端的游标也同样需要使用tempdb空间：静态游标和键集游标。对于静态游标，整个结果集都需要使用tempdb空间；对于键集游标，需要使用tempdb空间的只是结果集中行数乘以平均的键大小。

 

.tempdb记录日志所需要的空间大小

 

    Tempdb里的大多数操作都不需要被记录到日志里。但临时表，表变量，表值函数，以及用户定义的表是需要被记录的。它们被称为用户对象。因为活动的页的分配原因，排序操作也同样要被记录到日志。其日志文件的空间大小依赖于两个因素：分别是期间需要保持多长的日志以及有多少记录产生。评估tempdb日志文件空间大小与评估其他数据库差不多。但是，你在评估tempdb日志文件空间大小时，请只关注那些需要被记录到日志里的操作。例如，在tempdb中运行了很长时间的事务是一个用了排序操作的索引创建。这个操作运行了5个小时。假设，每分钟大约有1000个临时的表的纪录被修改，平均的纪录大小是1KB，那么计算日志空间所需要的大小为：5*60*1000*1KB = 300MB。

    由于日志截断会在只有1个小的日志文件的重负载系统中成为问题，所以要保证日志文件足够的大从而避免日志文件经常的被截断。例如，如果系统中每1秒会产生50MB的日志大小，那么日志文件至少应该为500MB，保证每10秒能完成日志截断操作。

    下次，会介绍如何监控和诊断tempdb数据库。