我们最近从Win 2003 / SQL Server 2000系统迁移到Win 2008 64位R2，SQL Server 2008 R2。
我们的网站是经典的asp，这个时候不能改成另一种脚本语言。
在旧的服务器上，如果我陷入某种无休止的循环，该页面会引发错误。
在新服务器上，我有一个页面有一些循环的问题，即使SQL SP只被调用一次（并作为服务器上的查询运行良好），它挂钩SQL服务器，因此locking我们所有的网站。
我会得到我的代码，没有biggie。 但是，我需要确保服务器超时发生这种情况。 （我正在处理的页面在查询的某些实例中运行正常，并且使用不同的查询variables与其他人locking。我不能在页面上偷偷摸摸地看到我在三年前没有碰到的页面。）
我无法弄清楚如何从服务器上运行一个SP，从一个ASP页面，这样的SQL服务器。 这显然是某种超时问题，但我不知道哪里/哪些超时值要改变。
我实际上已经远程桌面到服务器并杀死SQL服务器中的进程。
我担心自己是一个多面手，而服务器pipe理不是我的事情，即使这是我的责任，所以我几乎肯定会对我收到的任何答案有疑问。
我怎样才能跟踪这个？ 我需要更改哪些设置？
更多的信息：这不是SQL Server在我们的testing网站上，我创build了一个ASP文件，只是做了一个无限循环（1 = 1时做），并有同样的问题 – 其他网站将无法加载 – 没有涉及SQL服务器。 所以我认为这个过程悬而未决的原因是页面没有按照原样超时，所以与SQL的连接从未closures。 杀死SQL服务器中的进程会以某种方式重置页面。
对于我的故意无休止的循环，我不得不刷新应用程序池来摆脱它。 这更多地指向IIS或ASP设置。
ASP超时设置为服务器第一次加载时的默认值。
我仍然不知道为什么一个文件locking所有的网站，但。 再次，这在旧的服务器上没有发生。
首先，听我说，这是我总是告诉开发者谁抱怨长时间运行的语句或程序，并希望摆脱查询超时：
最好的办法是修复你的代码。
找出哪些代码运行时间长（使用SQL事件探查器，查看查询计划，或只是盯着你的代码，直到你grook它），并修复问题。 它可能是代码，索引，过时的统计信息，阻塞其他东西，缓慢的存储或一堆其他的东西。
好的，完成了。
如果你想改变查询的超时时间，以便在弄清楚什么是坏的情况下工作，你需要查看你的代码，find你创buildADO查询对象（结果集，命令对象等）的位置，然后改变它。 QueryTimeout和/或.CommandTimeout属性。
IIRC，这些属性的默认值是60秒。 把它“足够长”。 AFAIK，没有全球性的方式来设置.QueryTimeout和/或.CommandTimeout在IIS或应用程序全局的方式，但我不是一个IIS / ASP的人，我是DBA。
请注意，增加此值可能意味着长时间运行的代码会阻止其他用户更长时间，并且可能导致附带损害。 默认值设置为可能看起来很低的值，以帮助防止连接混乱其他连接。
有没有简单的方法来杀死在SQL 2008上运行“太长”的查询。
您在SQL Server“属性”对话框中看到的“查询超时”内容与超时链接的服务器有关。 IOW，它作为客户端控制本地服务器的超时值，并以您的名义连接到远程服务器。 （实际上，就像改变查询对象中的QueryTimeout值一样，但它都在SQL Server内部。）这对你没有帮助。
旧的“查询pipe理器”在configuration时将估计查询将花费多长时间，并且每当我尝试使用它时，它总是会出错。 我所见过的每个人都认为这是令人失望的。 您可能会注意到，“资源调控器”旨在限制RAM和CPU的使用，而不是时间。 所以，你根本不需要这个。
你可能会写一些会杀死查询的东西。 但：
总之，这样的项目通常比修复长期运行的代码更难。
对于下一个人。
这个问题的解决scheme归结为人们的看法，当时像我这样的人对服务器pipe理并不熟悉。
正如我在原始问题中所述，我们刚刚从较旧的服务器（Windows Server 2003 / SQL Server 2000）迁移到使用Windows Server 2008 R2 64位和SQL Server 2008 R2的新服务器。 我没有设置原来的服务器，并且付了钱给别人迁移新的服务器，给他指示：“只要设置好旧服务器的设置就可以了”。 嘿。
旧服务器是9岁，一个双Xeon处理器机器与1 GB的RAM 。 原来的服务器设置了两个网站 – 我们的预订系统和公司网站 – 都使用相同的应用程序池。 随着网站被添加多年，他们被添加到默认的应用程序池。 由于我们的资源问题，这是我们可以做的最好的。 而且在某些时候，有人必须将超时设置为非常短的值，可能是因为服务器有时被阻塞了。
新的服务器有32GB RAM和一个4核心处理器。 但是我聘请的顾问完全按照我所要求的方式 – 将所有的网站都放到了同一个应用程序池中。 显然，他没有做的一件事就是将超时设置为较短的值，即旧服务器必须设置的值。
在新服务器上，当我加载一个叫做存储过程的ASP页面时，SQL服务器使用了分配给它的所有处理器，并且只是挂在那里，所有的网站都被阻塞了，直到我杀死了SQL Server中的进程。 经过一番研究之后，我发现同样的事情发生了 – 所有的网站都停滞不前 – 当运行任何一种无尽的循环时，即使SQL服务器不参与，回收应用程序池也会“修复”它。
这一切都归结为假设/看法：旧服务器上的超时时间足够短，debugging时， 我从来没有意识到所有的网站被locking ，因为只有15或20秒，那么页面会超时，我会解决它，继续前进。 当超时设置为120秒时，虽然这是一个完全不同的球赛。 由于SQL Server被阻止，我以为这是一个SQL Server的问题，但它挂起，因为logging和连接没有closures，因为页面被困在一个循环…所以它只是似乎是SQL服务器的一部分问题。
最终的解决scheme是将大多数网站分成自己的应用程序池 （duh），并根据每个网站的适用情况调整ASP的超时值。