尝试查看数据库层次结构时出现“超出了锁定请求超时期限”错误


17

我的数据库有问题。

  1. 我可以运行基本查询,尽管比正常情况要慢得多。

  2. 当我尝试在SSMS Object Explorer中查看表,视图或过程的层次结构树时,得到lock request time out period exceeded

  3. 我在此数据库中的对象上运行的SSRS报告不再完成。

  4. 与该数据库上存储的过程关联的作业也不会运行。

我尝试使用 sp_who2查找并杀死数据库上的所有连接,但是这并没有解决问题。

这里发生了什么?我该如何解决?


另请参阅: stackoverflow.com/questions/12167570/…;不知道是否算作重复项。
LittleBobbyTables-Au Revoir,2012年

根据您对以下我的回答的评论,我认为您需要提供更多信息。服务器的大小如何,您是否看过它的性能计数器,它是交换到磁盘还是以某种方式使资源匮乏?确保实际检查以上内容,而不仅仅是假设。此外,当您连接到远程桌面时是否会发生这种情况?仅在从单个位置访问时才出现问题吗?该服务器(以及您与该服务器的连接)的网络天气如何?
NotMe 2012年

3
听起来您有未完成的事务正在阻止对表的读取访问。
a_horse_with_no_name 2012年

Answers:


11

这是由于交易的永久回滚所致。不得不最终重启我的服务器集群


2
重新启动服务对我来说解决了。
HerrimanCoder

在这种情况下重新启动可能会导致您进行数据库恢复
MaazKhan47 '18

dbcc opentran会告诉您是否有未完成的交易
Nate Anderson

我感到奇怪的是,例如,当事务正在运行时,我无法展开表部分。没有数据读取,没有DDL,什么也没有,只有表列表。
gerleim

5

除Harware考虑外,也许您需要运行脚本以检查哪些活动扣留了SQL Session,一种常见的情况是不在Implicit transactions OptionSQL Server Management Studio中使用。


嗨,比约特,您能否详细介绍您的建议?

看起来,虽然没有完全解释它,但这可能是一个更好的答案,可以永久回滚不回滚的事务,并且仅由于隐式事务而启用。
ConstantineK

回想这个问题,我不能说这一定是交易的永久回滚。判断locking request time out period exceed我会说跑步implicit transaction option会更好地找出原因。
Turbot

工具/选项/查询执行/ SQL Server / ANSI / SET隐式事务
Tadej

3

当我开始显式事务时,我从另一个数据库(而不是tempdb)中运行的脚本在tempdb中创建表时遇到了这个问题。当我提交事务时,提交似乎并没有释放我在tempdb中创建的表上的锁。

感谢此页面,我对USEtempdb进行了执行DBCC OPENTRAN并得到了导致锁定的tempdb连接的SPID。然后我KILL <SPID number>要杀死它。

不太优雅,我丢失了在tempdb中创建的表中的所有信息,但就我而言,这还可以。


在我们的案例中,使用SET IMPLICIT TRANSACTIONS ON而不发出COMMIT TRANSACTION再次向数据库发出了DML命令(视图重定义),这意外地导致了持久的事务。使用DBCC OPENTRAN有助于快速跟踪此问题。
Julio Nobre

1

这可能有太多的事情,我只能提供一些问题来帮助您找到答案。

  1. 服务器上的DB是否专用于仅运行SQL Server?否则,其他进程可能会因为浪费宝贵的处理器时间而受到干扰。

  2. 数据库服务器本质上是否内存不足?SQL Server将尝试分配它可以分配的每个字节,但是如果容量已满,并且您的查询需要加载更多数据,则必须回退到使用虚拟内存,这从根本上增加了简单查询可能花费的时间。

  3. 数据库服务器的网络带宽是否较小,无法及时处理数据传输?


最终,听起来好像您托管SQL Server的计算机的大小无法满足您的需求。您最终有可能最终达到了性能急剧下降的硬件极限。如果是这种情况(上述问题将帮助您确定),那么您将需要将数据库移至适合您要处理的数据(和查询)大小的服务器。

这可能意味着使用更快的处理器,更快的驱动器或仅安装更多的RAM。


这不是硬件问题。服务器群集承载多个数据库。这是唯一有问题的数据库

@LloydBanks:这并不意味着这不是硬件问题。如果我有2个数据库,一个数据库的大小为20GB,事务速率较高,另一个数据库的大小为1GB,事务速率较低,那么我希望将1GB的db交换到虚拟内存中。这会增加查询时间。如果20GB的数据库受到了足够大的冲击,则可能会导致较小的数据库出现连接问题。
NotMe 2012年

1

“当我尝试在SSMS Object Explorer中查看表,视图或过程的层次结构树时,超出了锁定请求超时期限。”

我有完全一样的问题。我去了查询执行窗口,然后;键入并执行的ROLLBACK语句。

看起来像我在此之前执行的一系列语句中的某些语句是未完成事务。具体来说,因为其中有些在DDL语句中。发布回滚后,对象层次结构开始起作用。


0

正如许多人已经指出的那样,通常会有一个持久的事务,这主要是由于我错过了使用SET IMPLICIT TRANSACTIONS ON的原因,根本不应该使用它。看看为什么要查看Brent Ozar的见解全文

无论如何,您可以使用以下查询来获取持久未决事务的列表。

SELECT
    [s_tst].[session_id],
    [s_es].[login_name] AS [Login Name],
    DB_NAME (s_tdt.database_id) AS [Database],
    [s_tdt].[database_transaction_begin_time] AS [Begin Time],
    [s_tdt].[database_transaction_log_bytes_used] AS [Log Bytes],
    [s_tdt].[database_transaction_log_bytes_reserved] AS [Log Rsvd],
    [s_est].text AS [Last T-SQL Text],
    [s_eqp].[query_plan] AS [Last 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]
where [s_tdt].[database_transaction_begin_time] is not null
ORDER BY
    [Begin Time] ASC;

https://www.brentozar.com/archive/2018/02/set-implicit_transactions-one-hell-bad-idea/

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.