SQL Server 2008 SP3

如何追踪这些超时错误？

错误显示在专门用于 IIS 中的错误报告的 Intranet 仪表板上。我怀疑 Web 应用程序中的默认超时时间为 30 秒，如果查询时间超过 30 秒，则会引发异常。由于在这些 SQL 服务器上有许多查询需要超过 30 秒的时间，因此我不能仅根据持续时间在探查器中进行过滤。

为这个仪表板监控的网站提供服务的是两台 IIS 服务器，它们从七个 SQL Server 实例中检索数据。

我可以使用“用户错误消息事件”和“OLEDB 错误事件”来跟踪 SQL Server Profiler 中的这些错误吗？

使用 SQL Server 时，可以有多个应用程序主机访问它，每个应用程序可以有一个或多个连接。每个连接都可能有多个事务（如果我错了，请纠正我）。每个事务都可以执行查询或非查询 SQL。

根据我的经验，如果我查询一个被独占锁定的表，我很容易遇到超时。如果两个不同的应用程序锁定同一资源，我还看到 SQL Server 检测并抛出死锁异常而不是超时。我还显示了重建索引超时，这可能是由于有人仍然连接到表。

但是，我也遇到了一种死锁，SQL Server 没有检测到它或超时。在这个应用程序中，它打开了两个连接，两个独立的事务，其中第一个事务锁定了一个资源，第二个事务尝试访问相同的资源，但它没有关闭第一个事务。

有人会提供超时和/或死锁类型的列表，这将帮助我在处理应用程序时避免此类情况。

我的理解是 PostgreSQL 函数的执行类似于事务。但是，当我尝试在函数中“SET LOCAL statement_timeout”时，它不起作用。以下是它在事务中的工作方式：

BEGIN; 
  SET LOCAL statement_timeout = 100; 
  SELECT pg_sleep(10); 
COMMIT;

结果在哪里（如预期的那样）：

BEGIN
SET
ERROR:  canceling statement due to statement timeout
ROLLBACK

但是，如果我将相同的命令放在函数体中：

CREATE OR REPLACE FUNCTION test() RETURNS void AS '
    SET LOCAL statement_timeout = 100;
    SELECT pg_sleep(10);
' LANGUAGE sql;

SELECT test();

超时不会发生，函数test()执行需要 10 秒。

请告知为什么这两种情况不同，以及我如何纠正它以在函数内设置语句超时。

我们遇到了一个问题，即通过 MySQL 工作台运行的只读查询从用户的 UI 角度超时，并在服务器上继续运行（显然消耗越来越多的资源），直到我们出现中断。

问题

• 在 MySQL 中是否有处理此类问题的标准方法？
• 是否存在我们需要避免的根本原因？

我在 Postgres 中有多个用户。我想为不同的用户设置不同的语句超时。
例如：访客 5 分钟，管理员 10 分钟。

在 Postgres 11.11 中可以吗？

我看到 Pricincipel SQL 服务器 (2008 R2) 超时

我看到的确切错误是：

超时已过。操作完成前超时时间已过或服务器未响应。尝试连接到Principle 服务器时发生此故障。

System.Data.SqlClient.SqlException (0x80131904)：超时已过期。操作完成前超时时间已过或服务器未响应。尝试连接到 Principle 服务器时发生此故障。---> System.ComponentModel.Win32Exception (0x80004005): 等待操作在 XXXX 超时

我想了解的是这是一个标准的超时，即。数据库无法在允许的时间内返回所需的结果？或者“ Principle Server ”的措辞是否意味着另一个问题？

我无法找到有关此特定错误的太多信息，并且需要知道它是否是性能问题，调整索引和 proc 将有助于解决，还是我需要查看其他问题。

我知道我可以通过运行（从 mysql 客户端）设置全局 MAX_EXECUTION_TIME 的值：

SET GLOBAL MAX_EXECUTION_TIME

但我如何查询它的价值呢？

GET 而不是 SET 似乎无法实现这一点。

我们有两个独立的 SQL Server。在一台服务器上，我们有一个数据仓库 (DWH)，在另一台服务器上，我们有销售信息数据库。

现在在 DWH 服务器上有一个 ETL 作业从销售服务器收集信息。该作业每天午夜后运行。DWH 通过链接服务器从销售数据库中收集信息。

现在，大多数情况下 ETL 作业运行没有任何问题。但有时会因为查询超时而失败。我们发现，有一个特定的模式：故障每 11 天发生一次。所以在第 11 天，ETL 作业无法收集信息。

出现以下错误：

链接服务器“我的链接服务器”的 SQLNCLI11 返回消息“查询超时已过期”。

注意：作业通常在启动后 10 分钟失败。

我们已经搜索了所有内容，但无法找出此问题的原因。我们也知道每次的数据量几乎一样。也没有任何运行所有 11 天之类的预定作业。

链接服务器上的远程查询超时设置为 0。

我们的下一步将是关闭销售服务器上的防病毒程序，以检查这是否会导致问题。

有没有人有任何线索或想法，我可以在哪里进一步搜索以找到问题？

技术

我正在使用 php 的 mssql 扩展（在 linux 上）向 SQL Server 发送查询。

设置。

我有一个表格，可以相当快地建立一次性数据。我花了比预期更长的时间来构建一个 cron 每小时清理这些数据，所以它已经积累了几个月来超过 1G 的数据，不确定有多少行，但可能超过 100 万。

问题

因此，我对超过 1 天的任何内容运行了删除查询。

DELETE FROM CacheForms WHERE TimeStamp < 1503454349

但是在 60 秒后查询超时并且脚本失败。（更新同样发生在 10 分钟。）

问题

当这个删除查询超时（一个 php 概念）数据库会发生什么？数据库是否从事务日志中恢复已删除的数据？还是数据真的被删除了？或者查询是否在 sql server 中继续运行？

是否有 DMV 或其他机制可以返回执行 session_id 的命令超时？