Друзья, поясните, что тут происходит! Дидлок в таблице, один процесс делает

SELECT, второй DELETE. Но почему?

Можно запросы?

точные запросы не знаю как откопать, длина в логе ограничена и целиком они там не видны. К тому же они формируются ORM. Но предполагаю что первый должен быть вида SELECT * FROM Events WHERE (StartTime >= A OR EndTime <= B) AND EventType = C , а второй просто DELETE FROM Events WHERE Id = X

СУБД и тип изоляции?

SQL Server,READ COMMITTED

А какая версия MS SQL Server?

Хм. Похожэ, ещё одной гадости про MSSQL я не знал. Так и не избавились от наследия блокировочника Sybase? Или там всё-таки, видимо, что-то спецыфичное было в этом SELECT -- ну там, триггер какой неявный?

дидлоки, в которые вовлечён триггер, я вчера тоже разбирал, и вроде бы в таких случаях его видно. А что значит "неявный" ?

Ну, вообще-то вроде на SELECT триггер просто так не повесишь. Но через всякие view и stored procedure можно добиться.

не, я про INSERT UPDATE триггеры

А чего странного то в этом дедлоке ? С одной стороны s блокировка с другой x , они не совместимы. Режим изоляции как я понял дефолтный, например можно включить rcsi на базе чтоб читатели не мешали остальным.

Вообще не знал вот про эту вещь, спасибо!

И это очередная причина, почему СУБД должны в первую очередь выбирать программисты... Какая боль выяснять такие вещи в середине проекта!

Я вот тоже не знаю что такое RCSI, это какая-то опция которую принято на хайлоаде включать?

Read committed snapshot isolation , все чтение будет из version store , которое находится в tempdb базе. Минусы если есть долгие транзакции оно может сильно распухать

Как бы select это shared lock, delete - это update lock, они несовместимы, причем, shared может блокировать того, кто хочет получить update, то есть, select может блокировать delete

Согласен. Но почему deadlock?

Ну, так вот...

Скорее всего там hold lock хинт используется в select

Запросы должны быть в логе сервера.

Есть там в SELECT хинт HOLDLOCK ? Хотя даже если и нет, ничего страшного-то нет. Расскажи, в чём твоя ПРОБЛЕМА заключается, и чего ты хочешь добиться?

Очевидно, что изоляция стандартная, не MVCC

Проблема в том, что я не понимаю, почему единственный DELETE, который представлен на графе, связан с блокировкой сразу нескольких страниц

Не факт, что ваша строчка на одной странице

А, вот эта мысль мне в голову не приходила

Он ищет записи для того чтобы их удалить на многих страницах

СтрочКИ только

Так несколько индэксов если -- то ничего удивительного.

А можно поподробнее? Ссылки на матчасть тоже принимаются.

В смысле -- если несколько индэксов -- то разумеется INSERT/UPDATE будет несколько страниц менять. И ничего удивительного, в принцыпе, что SELECT тогда шёл другим путём и ужэ заблокировал страницы в другом порядке.

А вторая страница это как раз страница кластерного индекса... Вполне может быть, кстати