0

我们在 W2003 Web 服务器上运行的大约 30 个站点中只有 1 个出现问题。

可能在一天中大约 25% 的时间里，网站不断返回： SQL Timeout Errors on various connections to SQL (using ODBC)

我已经检查并将 ODBC 驱动程序更新到我能找到的最新版本（3.5.x？），并且我还在检查 SQL 服务器以查看是否有问题（通过 Gb LAN 连接的同一网络上运行的另一台服务器）

IIS 日志文件返回“[Microsoft][ODBC_SQL_Server_Driver]Timeout_expired”

我今天早上遇到了这个问题，所以尝试重新启动 SQL 服务器以查看它是否是与负载相关的问题或其他问题 - 但该站点在重新启动后大约 20 分钟内继续生成这些错误（即使我们所有其他站点都在工作）此时） - 然后它停止超时，现在又开始工作了。

我试图为网站延长 SQL 连接的超时时间，看看这是否改变了一些东西，但它似乎没有做任何事情。

这个站点已经连续运行了大约 3 年，没有出现任何问题，而且我们已经有一段时间没有更改服务器上的任何内容了 - 这开始发生在圣诞节前后，但从那以后变得越来越规律。

我已经检查了所有代码以确保数据库连接正确打开/关闭（站点是经典的 ASP），并确保它没有打开太多并发连接 - 但一切都无济于事，我开始用完想法....有人吗？

我唯一的想法是更改为 OLEDB 连接而不是 ODBC - 但在此之前，我想检查是否有其他我错过的东西可以先尝试。

提前致谢！

卡尔。

4

4 回答 4

1

您提到更改 SQL 连接的超时，但不清楚究竟是什么超时：是与数据库的连接，还是查询时间过长？

一种可能有用的工具是 Sql Profiler。将其限制为遇到超时的用户或数据库。如果查询长度是一个问题，这应该可以让您准确了解哪些查询运行时间很长。

如果连接本身超时，请检查 Management Studio 中的当前活动。这显示了打开的连接数；如果它们很大，则可能某处存在泄漏。您可以通过运行包含以下内容的连接字符串在开发中对其进行测试：

MAX POOL SIZE=2;

这将导致泄漏迅速耗尽连接池。

Mitch Wheat 的建议非常好，不准确的统计数据确实会随着时间的推移而降低性能。此查询可以告诉您统计信息是否是最新的：

SELECT 
    object_name = Object_Name(ind.object_id),
    IndexName = ind.name,
    StatisticsDate = STATS_DATE(ind.object_id, ind.index_id)
FROM SYS.INDEXES ind
order by STATS_DATE(ind.object_id, ind.index_id) desc
于 2009-05-27T11:26:28.263 回答
0

SQL Server 是否有计划（并正在运行）的定期维护计划，包括重建索引？

于 2009-05-27T10:46:25.740 回答
0

由于您没有更改代码，因此您的连接没有问题。

去找出为什么 SQL 语句需要这么长时间。很难说它更简单。您可能会发现在未更改的代码与已更改的数据库的其他使用之间存在死锁情况。但是你需要去追踪它，而不是触及没有改变的工作代码。

于 2009-05-27T10:50:38.617 回答
0

如果上面的那些事情不起作用，我会在任务管理器下检查你的页面文件（PF）使用情况，看看它在哪里。您可能会因缺少虚拟内存而出现超时错误。如果它看起来接近顶部，请考虑将其增加得更高。在我的应用程序的不同部分，我偶尔会遇到很多 SQL 超时错误。事实证明这是一个性能问题。我建议至少 4000mb 的页面文件，具体取决于您服务器上的内存数量。

于 2011-04-12T14:23:19.163 回答