Помилка під час перегляду запиту на блокування запиту. Помилка під час спроби бачити Ієрархії БД

У мене проблеми з базою даних.

1. Я можу запускати основні запити, хоча і набагато повільніше, ніж зазвичай.

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

3. Мої звіти SSRS, які працюють на об'єктах у цій базі даних, більше не завершуються.

4. Завдання, пов'язані з процедурами, що зберігаються в цій базі даних, також не виконуються.

Я намагався sp_who2знайти і вбити всі з'єднання в базі даних, однак це не вирішило проблему.

Що тут відбувається? Як я можу це вирішити?

Це було викликано вічним відказом транзакції. Довелося врешті перезапустити мій кластер сервера

За винятком розгляду програмного забезпечення, можливо, вам потрібно запустити скрипт, щоб перевірити, що таке діяльність, що стримує SQL-сесію. Одним із поширених сценаріїв є не використання Implicit transactions Optionв студії управління SQL Server.

Цю проблему я отримав, коли почав явну транзакцію, в якій створив таблицю в tempdb зі скрипту, який працює в іншій базі даних (не tempdb). Коли я здійснив транзакцію, фіксація, здавалося, не звільнила замок на створеній мною таблиці в tempdb.

Завдяки цій сторінці я USEd tempdb і виконав DBCC OPENTRANі отримав SPID з'єднання з tempdb, що викликало блокування. Тоді я KILL <SPID number>його вбиваю.

Не дуже витончено, і я втратив всю інформацію в таблиці, яку я створив у tempdb, але це було нормально в моєму випадку.

Є так багато речей, це може бути те, що все, що я можу запропонувати, - це декілька питань, які допоможуть вам надати відповідь.

1. Чи БД на сервері призначений для просто запуску SQL Server? Якщо ні, то інші процеси можуть заважати, викрадаючи дорогоцінний час процесора.

2. Чи сервер БД по суті не має пам'яті? SQL Server намагатиметься виділити кожен байт, який він може, але якщо він є потужним і ваші запити потребують завантаження більшої кількості даних, то він повинен відмовитися від використання віртуальної пам’яті, що кардинально збільшує кількість часу, яке можуть зайняти навіть прості запити.

3. Чи пропускна здатність мережі сервера БД невелика, щоб вчасно обробляти передачу даних?

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

Це може означати використання більш швидких процесорів, швидших дисків або просто встановлення більшої кількості оперативної пам'яті.

"Коли я намагаюся переглянути дерева ієрархії для таблиць, представлень або процедур у Провіднику об'єктів SSMS, я отримую перевищення періоду часу запиту блокування."

У мене було саме таке питання. Я перейшов до вікна виконання запиту і; набраний та виконаний 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_transaction-one-hell-bad-idea/