是否有任何逻辑只是最大限度的tempdb，从来没有改变大小？

Question

我之所以问我们有一个专用的RAID10阵列，其中tempdb（“t”驱动器）的容量约为150GB。它仅用于存储tempdb。 SQL Server或任何其他进程不会将t驱动器用于其他任何进程。

我们的DBA具有初始大小为15GB的tempdb设置，并且自动增长为20％。每次服务器启动时，它都会调整为15GB，然后在一天中增加到大约80GB（平均）。现在，IT正在考虑将初始尺寸设置为30或40GB，但考虑到该驱动器仅用于tempdb，我认为这就是为什么不立即“最大化”。

在tempdb的主要组中简单地创建4个数据文件是否有任何负面影响，每个初始大小为30GB（总共120GB），关闭自动增长并完成它？

SQL Server是否有能力在一个查询中跨越多个tempdb数据文件？即如果tempdb总共释放70GB但一个进程使用的文件已满（使用30GB中的30个）会导致问题吗？

Answer 1

我会将它们的大小设置为大约100GB并保持自动增长，这样您就不必每次都等待它增长，我也会添加多个文件

  

是否有任何负面影响   在主数据库中创建4个数据文件   tempdb的组给每个人一个   初始大小为30GB，转自动增长   关闭并完成它？

听起来对我来说是一个很好的计划，但是如果有人决定在没有该列索引的大表上进行排序操作，我会留下自动增长

另见：http://technet.microsoft.com/en-us/library/cc966534.aspx

• 建议使用.25到1 每个数据文件（每个文件组） 主机服务器上的CPU。
• 对于TEMPDB尤其如此 其中推荐是1个数据 每个CPU文件。
• 双核计为2个CPU;合乎逻辑 procs（超线程）没有。

Answer 2

我们发现创建大型TempDB数据和日志文件非常有用。任何限制服务器操作系统活动的操作（如调整TempDB大小）都会提高服务器效率。我们有一台16处理器机器，113 GB专用于TempDB数据空间。该机器专用于大型SSIS ETL过程，从而实现海量数据操作。

我们的大部分ETL操作最多会产生4个SQL线程。在为每个处理器（16）初始配置TempDB文件之后，我们通过性能监控很快意识到我们的配置强制SQL \ windows不必要地跨越多个TempDB文件。我们确定了5个更大的TempDB数据文件并实现了性能改进。我们已经转移到24处理器盒并使用8个TempDB文件。

请注意，这是一个大型数据迁移服务器;我确信面向事务的系统仍然可以从推荐的1-1处理器到TempDB文件配置中受益。还应该注意的是，在TempDB文件上大幅增加％可能会强制关键事务占用Windows操作，因此可能不适合您的特定应用程序。