Редактировать : Решено, был триггер с циклом на столе (читайте мой собственный ответ ниже).
У нас есть простой оператор удаления, который выглядит следующим образом:
DELETE FROM tablename WHERE pk = 12345
Это просто зависает, нет таймаута, нет ничего.
Мы рассмотрели план выполнения, и он состоит из множества поисков связанных таблиц, чтобы убедиться, что никакие внешние ключи не приведут к сбою при удалении, но мы убедились, что ни в одной из этих других таблиц нет строк, относящихся к этому конкретному строки.
В данный момент нет другого пользователя, подключенного к базе данных.
Мы запустили DBCC CHECKDB против него, и он сообщает 0 ошибок.
Глядя на результаты sp_who и sp_lock во время зависания запроса, я заметил, что мой spid имеет множество блокировок PAG и KEY, а также случайная блокировка вкладки.
Таблица содержит 1.777.621 строк, и да, pk является первичным ключом, поэтому удаление одной строки основано на индексе. В плане выполнения нет сканирования таблицы, хотя я заметил, что он содержит что-то, что говорит Буфер таблицы (Eager Spool) , но говорит Примерное количество строк 1. Может ли это быть на самом деле скрытое сканирование таблицы ? Он только говорит, что смотрит на столбец первичного ключа.
Попробовал DBCC DBREINDEX и ОБНОВЛЕНИЕ СТАТИСТИКИ на столе. Оба были завершены в разумные сроки.
К сожалению, в этой конкретной таблице очень много индексов. Это основная таблица в нашей системе с множеством столбцов и ссылок, как исходящих, так и входящих. Точное число - 48 индексов + кластерный индекс первичного ключа.
На что еще мы должны смотреть?
Обратите внимание, что в этой таблице не было этой проблемы раньше, эта проблема возникла неожиданно сегодня. У нас также есть много баз данных с одинаковыми настройками таблиц (копии баз данных клиентов), и они ведут себя, как и ожидалось, проблематично только это.