SQL 2014, платформа 8.2.19.90
Началось это дело со вчерашнего дня. Стали падать ошибки блокировки на некоторые документы. Перезагрузили сервер, помогло. Сегодня снова аналогичные блокировки.
Сообщение: конфликт блокировок при выполнении транзакции превышено максимальное время ожидания.
Знаю какой регистр и какие измерения заблокированы. Теперь вопрос кто это сделал и как.

Мало места.

ТЖ настраивай

(0) На конслои не видно?

(1) место есть.
(3) Нет.

проще цуп поднять, там все автоматом

(5) он же платный

(5) ЦУП куплен но не установлен(
Если его поставить там можно будет увидеть кто блокирует (конкретный пользователь)

(7) Можно прям в ТЖ это смотреть, ЦУП просто разберет его в более удобный вид

Есть скрипт в инете для скула, он покажет точно, проверено. Но еще можно по консоли агента сервера посмотреть, подумать

так я не понял главный вопрос, кто виноват или что делать?

(9) скрипты смотрю, или я нахожу не работающие или у SQL сейчас нет блокировок
(10) Хочется все знать, чтобы предпринять меры к дальнейшему исключению гемора.
Сейчас бы конечно идеально сбросить блокировку, но найти ее не получается

(11) в консоли сервера посмотри еще, там тоже видно блокировки

(9) Судя по тексту - это блокировки сервера 1с

(13) Не понял про блокировки сервера))

(14) управляемые блокировки

use <ИмяБазы>;

SELECT
    db.name DBName,
    tl.resource_type,
    CASE WHEN request_type = 'OBJECT' THEN
        OBJECT_NAME(p.OBJECT_ID)
    ELSE
        OBJECT_NAME(tl.resource_associated_entity_id)
    END BlockedObjectName,
    tl.request_session_id,
    wt.blocking_session_id,
    h1.TEXT AS RequestingText,
    h2.TEXT AS BlockingTest,
    tl.request_mode
FROM sys.dm_tran_locks AS tl
    LEFT JOIN sys.databases db ON db.database_id = tl.resource_database_id
    LEFT JOIN sys.dm_os_waiting_tasks AS wt ON tl.lock_owner_address = wt.resource_address
    LEFT JOIN sys.partitions AS p ON p.hobt_id = tl.resource_associated_entity_id
    LEFT JOIN sys.dm_exec_connections ec1 ON ec1.session_id = tl.request_session_id
    LEFT JOIN sys.dm_exec_connections ec2 ON ec2.session_id = wt.blocking_session_id
    CROSS APPLY sys.dm_exec_sql_text(ec1.most_recent_sql_handle) AS h1
    CROSS APPLY sys.dm_exec_sql_text(ec2.most_recent_sql_handle) AS h2
GO

покажет блокированный/блокирующий запрос, заблокированную таблицу и ИДшники сессий.

(16) пустая таблица

(18) значит прямо сейчас нет ожиданий на блокировках на скуле

(18) Значит у тебя блокировки заканчиваются, надо быстрее реагировать) Скорее всего себестоимость рассчитывают, кто это может предположи и к ней, спроси.

Тогда что блокирует таблицы. скуль молчит, консоль 1с молчит

(19) так это же не скуль

(22) где не скуль? здесь не скуль?
http://www.gilev.ru/wp-content/uploads/2013/10/Ошибка-SQL.png

(23) Так у ТС сообщение
конфликт блокировок при выполнении транзакции превышено максимальное время ожидания

это конфликт УПРАВЛЯЕМЫХ блокировок

Режим блокировки "Автоматический"

(26) Точно сооб щение такое тогда? или ты по памяти?

(0) чот не пойму - ЦУП есть ну и вперед