Есть ли способ предотвратить тупики (и что происходит, если один происходит, а другой становится жертвой) - PullRequest
2 голосов
/ 30 августа 2010

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

Теперь мы все больше и больше заходим в тупик (в этом случае один из двух становится победителем и прерывается). Пока все хорошо, потому что вы можете предвидеть это и пытаться повторно выполнить утверждение, но тогда всегда возникает один и тот же тупик. Итак, это мой первый вопрос: почему всегда возникает один и тот же тупик?

И, во-вторых, есть ли способ сообщить dbms не пытаться получить эксклюзивную блокировку для записи (мы обновляем отдельные записи с помощью хранимой процедуры), когда другой процесс уже читает и обновляет ее, но «подождите, пока сторона, пока другой процесс не будет готов? Или это слишком простая вещь, чтобы сказать о тупике?

и, возможно, в-третьих, есть ли способ спросить у LINQ to SQL, какие блокировки вызывали проблему, поэтому я получу немного больше информации о том, какие части процесса вызывают проблему.

Ответы [ 2 ]

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

SQL Profiler - лучший инструмент, который я использовал, чтобы начать пытаться решить проблемы взаимоблокировок в SQL Server.

Запустить трассировку: на вкладке «Выбор событий»: снять все предварительно выбранные события.Отметьте «Показать все события».Разверните «Замки».Установите флажки «График взаимоблокировки», «Блокировка: тупик» и «Цепочка взаимоблокировки блокировки».

Запустите трассировку и запишите события взаимоблокировки.

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

Использование того, что вы найдете в этом первом проходе, может дать вам идеи о том, что нужно изменить, или предложить другие события для отслеживания в SQL Profiler.

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

Как указывает @Darryl Peterson, SQL Profiler - хороший инструмент для сбора информации о взаимоблокировках.Если вы не знаете, когда возникнет взаимоблокировка, вы можете установить флаг трассировки SQL Server для захвата данных.

DBCC TRACEON (1204) 

При возникновении взаимоблокировки информация о взаимоблокировке будет записана на SQL Server.Журнал ошибок.

Существует несколько способов получить тупик.Ваш первый вопрос «почему всегда возникает один и тот же тупик», вероятно, является хорошим знаком.Если взаимоблокировка повторяется, то вы можете ее перехватить и исправить.

Что касается вашего второго вопроса, SQL Server, вероятно, уже говорит одному процессу ждать, пока другой завершит работу.Тем не менее, вы не можете избежать тупика, ожидая.Тупиковая ситуация - это ситуация, когда процесс пытается использовать ресурс, который удерживается другим процессом.Но другой процесс ожидает ресурс, который удерживает первый процесс.Ни один из процессов не освободит ресурс, пока не завершит свою работу.Обратите внимание, что это простое объяснение и могут быть более сложные тупиковые условия.Дело в том, что процессы, находящиеся в тупике, никогда не смогут завершиться.

Как только вы узнаете больше о процессах, связанных с тупиком, вы сможете предпринять шаги, чтобы избежать его.

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