SQL Server阻塞问题

目前，SQL 2005数据库服务器上大约每天发生一次问题，尽管发生的时间不一致

基本上，数据库会停止，并开始拒绝连接，并显示以下错误消息。这包括登录到SSMS：

已成功与服务器建立连接，但在登录过程中出现错误。（提供程序：TCP提供程序，错误：0-指定的网络名称不再可用。）

SQL的CPU使用率通常在15%左右，但当数据库处于断开状态时，它的CPU使用率约为70%，因此它显然在做一些事情，即使没有人可以连接。即使我禁用了使用数据库的web应用程序，CPU也不会下降

我无法重新启动SQLSERVER进程，因为它没有响应，因此我必须手动终止该进程，然后将DB置于可疑/恢复模式（我可以修复该模式，但这很痛苦）

下面是我在数据库处于中断状态时收集的一些PerfMon统计数据，这可能会有所帮助。如果人们想请求，我还有很多：

• 活动事务：2（从不
• 更改）逻辑连接：34（NC）
• 进程被阻止：16（NC）用户
• 连接：30（NC）批处理请求：0
• （NC）活动作业：2（NC）日志
• 截断：596（NC）对数收缩：24
• （NC）运行时间最长的事务
• 时间：99（NC）

我想他们的关键是找出数据库正在使用它的CPU，但由于我甚至不能登录到SSMS，这在标准方法中是不可能的

令人不安的是，我甚至不能使用专用的管理员连接进入SSMS。我得到了与所有其他请求相同的timout

---

任何建议、建议，甚至同情，都将不胜感激

您需要使用探查器来确定哪些查询和进程可能导致此问题。

当它阻止正常连接时，您可能需要尝试在专用管理控制台连接下进入。要实现这一点，您需要担任数据库服务器的sysadmin角色，在SSMS中，当您指定服务器名称的前缀为“admin:”时，这将使用不同的连接，不太可能被阻止（但并非不可能，只是需要极端情况）

默认情况下，您不应该使用此DAC，您可以访问系统表和其他各种您无法正常看到的项目，因此您也可以使用它进行大量损坏

一旦进入，您就有了一个正常的查询窗口，可以开始查看正在运行的内容、锁定的内容等。

的目的是在这些情况下提供帮助

然后，这个脚本可以告诉您opentran和SQL运行的是什么

SELECT s_tst.[session_id],
   s_es.[login_name] AS [Login Name],
   S_tdt.[database_transaction_begin_time] AS [Begin Time],
   s_tdt.[database_transaction_log_record_count] AS [Log Records],
   s_tdt.[database_transaction_log_bytes_used] AS [Log Bytes],
   s_tdt.[database_transaction_log_bytes_reserved] AS [Log Reserved],
   s_est.[text] AS [Last T-SQL Text],
   s_eqp.[query_plan] AS [Last Query Plan]
FROM sys.dm_tran_database_transactions s_tdt
   JOIN sys.dm_tran_session_transactions s_tst
      ON s_tst.[transaction_id] = s_tdt.[transaction_id]
   JOIN sys.[dm_exec_sessions] s_es
      ON s_es.[session_id] = s_tst.[session_id]
   JOIN sys.dm_exec_connections s_ec
      ON s_ec.[session_id] = s_tst.[session_id]
   LEFT OUTER JOIN sys.dm_exec_requests s_er
      ON s_er.[session_id] = s_tst.[session_id]
   CROSS APPLY sys.dm_exec_sql_text (s_ec.[most_recent_sql_handle]) AS s_est
   OUTER APPLY sys.dm_exec_query_plan (s_er.[plan_handle]) AS s_eqp
ORDER BY [Begin Time] ASC;

---

最后，SQL Server 2005有一个问题：您可以使用它来找出哪里出了问题

是否有系统创建的作业，可能是在数据库发生更改之前创建的？像定时清理等？是的，有各种各样的清理任务在运行。从SQL代理日志看来，这些都是完整完成的，我确实考虑过这一点，但是它意味着运行24个小时的剖析器，直到问题发生。如果我这样做了，如果我无法登录到SSMS，我是否能够保存用于分析的配置文件跟踪？您可以让profiler直接将跟踪运行到表或文件中。