«Превышен период ожидания запроса блокировки» Ошибка при попытке увидеть иерархию БД

У меня проблемы с базой данных.

1. Я могу выполнять основные запросы, хотя и намного медленнее, чем обычно.

2. Когда я пытаюсь просмотреть деревья иерархии для таблиц, представлений или процедур в SSMS Object Explorer, я получаю lock request time out period exceeded.

3. Мои отчеты SSRS, которые запускаются для объектов в этой базе данных, больше не завершаются.

4. Задания, связанные с процедурами, хранящимися в этой базе данных, также не выполняются.

Я попытался использовать, sp_who2чтобы найти и уничтожить все соединения в базе данных, однако это не решило проблему.

Что здесь происходит? Как я могу решить это?

Это было вызвано постоянным откатом транзакции. Пришлось перезапустить мой кластер серверов

Без учета аппаратного обеспечения, возможно, вам нужно запустить сценарий, чтобы проверить, какие действия удерживают сеанс SQL, один из распространенных сценариев - это не использовать Implicit transactions OptionSQL Server Management Studio.

Я получил эту проблему, когда начал явную транзакцию, в которой я создал таблицу в базе данных tempdb из сценария, работающего в другой базе данных (не в базе данных tempdb). Когда я фиксировал транзакцию, фиксация, казалось, не снимала блокировку таблицы, которую я создал в tempdb.

Благодаря этой странице я USEвыполнил tempdb и выполнил DBCC OPENTRANSPID соединения с tempdb, который вызывал блокировку. Тогда я KILL <SPID number>убью его.

Не очень изящно, и я потерял всю информацию в таблице, которую создал в tempdb, но в моем случае это было нормально.

Так много всего, что я могу предложить, это лишь несколько вопросов, которые помогут вам найти ответ.

1. БД на сервере предназначена только для запуска SQL Server? Если нет, другие процессы могут мешать, похищая драгоценное процессорное время.

2. Серверу БД не хватает памяти? SQL Server будет пытаться выделить каждый байт, который может, но если он заполнен и ваши запросы требуют больше данных для загрузки, он вынужден использовать виртуальную память, что радикально увеличивает количество времени, которое могут потребоваться даже для простых запросов.

3. Является ли пропускная способность сети сервера БД малой для своевременной передачи данных?

В конце концов, похоже, что компьютер, на котором вы размещаете SQL Server, недостаточно приспособлен для того, что вы пытаетесь сделать. Вполне возможно, что вы наконец достигли тех аппаратных ограничений, когда производительность радикально падает. Если это так (приведенные выше вопросы помогут вам определить это), вы захотите переместить БД на сервер, размер которого соответствует размеру данных (и запросов), которые вы пытаетесь обработать.

Это может означать использование более быстрых процессоров, более быстрых дисков или просто установку большего объема оперативной памяти.

«Когда я пытаюсь просмотреть деревья иерархии для таблиц, представлений или процедур в SSMS Object Explorer, я получаю превышение времени ожидания запроса блокировки».

У меня была точно такая же проблема. Я пошел в окно выполнения запроса и; набрал и выполнил ROLLBACKзаявление.

Похоже, некоторые из серии заявлений, которые я выполнял до этого, проходили в открытой транзакции. В частности, потому что некоторые из них, где DDL заявления. Как только я произвел откат, иерархии объектов начали работать.

Как уже отмечали многие, обычно это длительные транзакции, в основном из-за которых я пропустил команду SET IMPLICIT TRANSACTIONS ON, которая вообще не должна использоваться. Чтобы понять, почему стоит проверить проницательную статью Брента Озара

В любом случае, вы можете получить список длительных ожидающих транзакций, используя следующий запрос.

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/