两天前，我们的产品服务器遭受了巨大的经济下滑，主要症状是极其多的请求遭遇SQLTimeout。 我会很快描述我们的设置，我调查了什么，我们的解决方法，然后将跟随我的问题。
我们的设置
一对服务器托pipe我们的SAS应用程序的这个分支。 一个是在IIS上运行多个应用程序的应用程序服务器，另一个是遭受速度下滑的应用程序服务器，它是一个运行SQL Server 2005的Windows Server 2008服务器.SSQL托pipe的是100到200个数据库。
问题/调查
服务几乎停下来。 一些请求通过，但大多数遭受SQL超时。 SQL机器CPU和RAM看起来不错，平均CPU工作量大约为25％，内存大小为85％。 我当时没有想到要检查磁盘的活动，因为我直接去了'EXEC sp_who2'
结果显示数百个任务被ID 123阻塞，这个任务本身和其他100个任务被ID 456阻塞。正常执行通常根本没有阻塞任务。 当我在15-20秒后重新运行sp_who2时，popup了不同的阻塞ID，但阻塞/阻塞任务的数量似乎保持不变。 （由于紧急模式没有统计组）
大多数任务阻塞了“SELECT INTO”或“CREATE INDEX on temptable”等语句。
解决方法
杀死SQL进程并重新启动以恢复服务。 经济放缓没有重现，但我们知道我们处于危险之中。
我的问题
我能做些什么来解决这个问题，最好在重新发生之前呢？
子问题：
我到目前为止做了什么
从症状来看，我们怀疑问题是tempdb上的某种争用。 （另一个症状是右键单击tempdb以查看问题期间的属性在短时间内生成错误）
没有日志表明在tempdb上发生了自动增长事件，尽pipe据我所知，自动增长成功不会被logging，只有失败。
从那时起，我已经阅读了很多不同的信息来源，包括tempdb，
http://www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/ http://www.sqlservercentral.com/blogs/robert_davis/2010/03/ 05 /断-下- TempDB的争用/
从我收集的信息来看，最好的做法是设置初始大小的tempdb文件，并且每个核心最多有8个文件。 我们的计划是尽快实施（8核心，8个文件），因为这是最好的做法。 他们都将在同一个硬盘（现在），但我们认为最坏的情况是没有改善，最好的情况是我们获得逻辑争用瓶颈和磁盘I / O瓶颈之间的差异。
但是，我们不能确定与我们所遇到的问题的相关性。 据我所知，分裂到多个临时文件将有助于“PAGELATCH_XX”types的等待，但在正常活动期间运行Paul S. Randal的查询（请参阅第1页的链接），那种types的等待是不存在的。 我在正常活动中看到的前3名是：
CXPACKET 68.63％
LATCH_EX 18.46％
PAGEIOLATCH_SH 4.35％
尽pipe我没有办法知道减速过程中发生了什么types的堵塞，因为我们没有所有这些信息。
我发布这个问题后，这个问题终于复发了。
运行Paul S. Randal的查询，我很快发现了一些PAGELATCH_XX阻塞等待正在进行，所以通过sp_who2，我能够find罪魁祸首数据库，并且只从Web服务器重新启动相关的客户端应用程序池，作为一个不那么苛刻的解决方法恢复服务。
我们也能够跟踪实际的操作，做更多的tempdb工作，他们之前做的，并将寻找解决这个问题的另一种angular度的方法。
解决scheme
我们已经把tempdb文件分割成多个文件，正如最佳实践所暗示的那样 ，因为它似乎是解决我的问题的正确方式。