我们最近从 Win 2003/SQL Server 2000 系统迁移到 Win 2008 64 位 R2、SQL Server 2008 R2。
我们的网站采用的是经典的 asp，目前无法更改为其他脚本语言。
在旧服务器上，如果我陷入某种无限循环，页面就会抛出错误。
在新服务器上，我有一个页面存在某种循环问题，即使 SQL SP 只被调用一次（并且在服务器上作为查询运行良好），它也会锁定 SQL 服务器，因此会锁定我们所有的网站。
我会弄清楚我的代码，没什么大不了的。但我需要确保服务器在发生这种情况时超时。（我正在处理的页面在查询的某些实例中运行良好，并使用不同的查询变量锁定其他实例。我不能让这样的事情在我三年没碰过的页面上偷偷出现。）
我无法理解 SP 是如何通过 ASP 页面在服务器上运行一次的，它是如何以这种方式绑定 SQL 服务器的。这显然是某种超时问题，但我不知道在哪里/哪些超时值需要更改。
我实际上必须远程桌面到服务器并终止 SQL 服务器中的进程。
恐怕我是个多面手，服务器管理不是我的强项，尽管这是我的职责，所以我几乎肯定会对我收到的任何答案产生疑问。
我该如何追踪这个问题？我需要更改哪些设置？
更多信息：它不是 SQL Server 在我们的测试站点上，我创建了一个 ASP 文件，该文件只执行了一个无限循环（do while 1=1），并且遇到了同样的问题 - 其他网站无法加载 - 无需 SQL Server 参与。所以我认为进程挂起的原因是页面没有按应有的方式超时，因此与 SQL 的连接从未关闭。在 SQL Server 中终止进程会以某种方式重置页面。
对于我故意设置的无限循环，我必须刷新应用程序池才能摆脱它。这更多地指向 IIS 或 ASP 设置。
ASP 超时设置为服务器首次加载时的默认设置。
不过，我还是不明白为什么一个文件会锁定所有网站。再说一遍，这在旧服务器上没有发生过。
答案1
对于下一个人。
当某些人（比如我）不太熟悉服务器管理时，这个问题的解决方案就取决于看法。
正如我在原始问题中所述，我们刚刚从旧服务器（Windows Server 2003/SQL Server 2000）迁移到新服务器，新服务器使用 Windows Server 2008 R2 64 位和 SQL Server 2008 R2。我没有设置原始服务器，而是付钱请人将东西迁移到新服务器，并给他指示，“只需按照旧服务器的设置方式进行设置即可。”呵呵。
旧服务器已有 9 年历史，是一台双 Xeon 处理器的机器，1 GB 内存。原始服务器设置了两个网站 - 我们的预订系统和公司网站 - 都使用相同的应用程序池。多年来，随着网站的添加，它们被添加到默认应用程序池中。由于我们的资源问题，这是我们能做的最好的事情。而且在某个时候，一定有人将超时设置为非常短的值，可能是因为服务器有时会有点堵塞。
新服务器有 32GB 的 RAM 和 4 核处理器。但我聘请的顾问几乎完全按照我的要求做了，并按照旧服务器上的方式设置了所有内容，包括将所有网站放入同一个应用程序池中。显然，他没有做的一件事是将超时设置为旧服务器必须设置的较短值。
在新服务器上，当我加载调用存储过程的 ASP 页面时，SQL Server 使用了分配给它的所有处理器，并挂在那里，所有网站都停滞了，直到我终止了 SQL Server 中的进程。经过一番研究，我发现同样的事情发生了 - 所有网站都停滞了 - 当运行任何类型的无限循环时，即使不涉及 SQL Server，并且回收应用程序池也会“修复”它。
这一切都归结为假设/看法：旧服务器上的超时时间足够短，以至于在调试某些东西时，我从来没有意识到所有的网站都被锁定了，因为只有 15 或 20 秒，然后页面就会超时，我会修复它并继续前进。但是，当超时设置为 120 秒时，情况就完全不同了。由于 SQL Server 停滞了，我以为是 SQL Server 问题，但它挂了，因为记录和连接没有关闭，因为页面卡在循环中……所以它只是出现了SQL 服务器是问题的一部分。
最终的解决方案是将大多数网站分离到自己的应用程序池中（呃），并根据每个网站的适用情况调整 ASP 的超时值。
答案2
首先，请听我说完，我总是告诉那些抱怨语句或程序运行时间过长并想解决查询超时问题的开发人员：
最好的办法是修复你的代码。
找出哪些代码运行时间过长（使用 SQL Profiler、查看查询计划或只是盯着代码直到您理解它）并修复问题。它可能是代码、索引、过时的统计数据、其他阻塞、存储缓慢或其他一系列问题。
好的，完成了。
如果您想更改查询超时以使事情正常工作，同时找出问题所在，您需要查看代码以找到创建 ADO 查询对象（结果集、命令对象等）的位置，并更改 .QueryTimeout 和/或 .CommandTimeout 属性。
据我所知，这些属性的默认值为 60 秒。请将其设置为“足够长”。据我所知，没有以 IIS 或应用程序全局方式设置 .QueryTimeout 和/或 .CommandTimeout 的全局方法，但我不是 IIS/ASP 人员，我是 DBA。
请注意，增加此值可能意味着运行时间较长的代码将阻塞其他用户更长时间，并可能导致附带损害。默认值设置为一个看似较低的值，以帮助防止您的连接扰乱其他连接。
没有简单的方法可以终止在 SQL 2008 上运行“太长时间”的查询。
您在 SQL Server“属性”对话框中看到的“查询超时”内容与链接服务器的超时有关。换句话说，当本地服务器充当客户端并代表您连接到远程服务器时，它控制本地服务器的超时值。（实际上，这就像更改查询对象中的 QueryTimeout 值，但它都在 SQL Server 内部。）这对您没有帮助。
旧的“查询管理器”在配置后会估计查询需要多长时间，但每次我尝试使用它时，它总是会出错。我见过的每个人都谈论它，觉得它令人失望。您可能注意到，“资源管理器”旨在限制 RAM 和 CPU 的使用，而不是时间。因此，您根本不想要它。
您可能会编写一些可以终止查询的内容。但是：
- 你可能会破坏别人的重要工作成果（包括备份、重新索引等）。
- 那些被终止的查询将被回滚。回滚需要一定的时间，并且工作可能会消失。
- 重新提交这些回滚的查询可能会导致服务器负载增加。
简而言之，这种项目通常比修复长期运行的代码更难做好。