Будут ли следующие операторы SQL причиной тупика? - PullRequest
2 голосов
/ 30 августа 2010

Я ищу способ объяснить проблему взаимоблокировки. Я думаю, что знаю, что вызывает это, но я не уверен в точных событиях.

У нас длительный просмотр (несколько секунд). Мы обновляем одну из таблиц, которая используется в этом представлении. Обновления также могут занять несколько секунд. Операторы обновления, выполняющиеся при возникновении тупиковой ошибки, присоединяются к представлению. Например:

UPDATE t1 SET
    Field1 = 'someValue'
FROM Table1 t1
JOIN TheView v ON v.TableId = t1.TableId
WHERE v.Condition = 'TheCondition'

Утверждение, которое, похоже, закрывается из-за тупика, выглядит так:

SELECT * FROM TheView

Где вид определяется как:

CREATE VIEW TheView AS
    SELECT *
    FROM Table1 t1
    JOIN Table2 t2 ON t2.foo = t1.foo

Я почти уверен, что возникла тупиковая ситуация, поскольку и представление, и оператор обновления зависят от Таблицы1. Возможен ли этот сценарий?

Спасибо

Ответы [ 3 ]

1 голос
/ 30 августа 2010

Возможно ли это? Конечно. Вам нужно будет поработать, чтобы узнать наверняка. См .: Как отследить взаимные блокировки с использованием SQL Server 2005 Profiler

1 голос
/ 30 августа 2010

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

Одним из способов является использование изоляции моментальных снимков.

1 голос
/ 30 августа 2010

Вы пробовали использовать SQL Profiler? Профилировщик точно скажет, какие операторы участвуют в тупике, и включает ресурсы, заблокированные каждым процессом, которые нужны другому процессу и т. Д.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...