SQL 2008 SP - причина тупика или красная сельдь? - PullRequest
Новая
       21

SQL 2008 SP - причина тупика или красная сельдь?

0 голосов
/ 02 марта 2010

У одного из моих коллег есть хранимая процедура, которая выполняет следующие действия:
Начни тран
1) Динамически генерировать оператор выбора.
2) Вставить в таблицу х
3) Выполнить оператор выбора
Конец тран

Если эта хранимая процедура запускается двумя отдельными потоками одновременно, он получает следующую ошибку: System.Data.SqlClient.SqlException: транзакция (ID процесса 57) заблокирована при блокировке | ресурсы буфера связи с другим процессом и были выбраны в качестве жертвы тупика. Перезапустите транзакцию

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

Ответы [ 2 ]

1 голос
/ 02 марта 2010

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

  1. Перекрестная запись-чтение. Поток 1 вставляет строку с ключом A, а затем выбирает строку с ключом B. Поток 2 вставляет строку с ключом B, затем выбирает строку с ключом A. Порядок выполнения: T1 (A), T2 (B), T1 (B) - ожидание, T2 (А) -deadlock.
  2. Независимая запись-чтение: T1 вставляет A, затем читает A, T2 вставляет B, затем читает B. Критическая информация: нет индекса на ключе, поэтому для чтения A и / или B требуется сканирование таблицы. 1007 *. Порядок выполнения: T1 пишет A, T2 пишет B, T1 читает A, начинает сканирование, блокирует X-блокировку T2 на B, T2 читает B, начинает сканирование, блокирует X-блокировку T1 на A, тупик.
  3. Независимо оптимизировано запись-чтение. Этот случай является наиболее пугающим для большинства новичков, когда имеются надлежащие индексы доступа, но все еще возникают тупики. Я представил этот случай в тупик чтения / записи , обновление может заблокировать чтение только из-за другого порядка доступа к индексу. Вряд ли это ваш случай, но с такой плохой документацией все возможно.

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

Если бы я рискнул предположить, наиболее вероятный случай - 2). Случай 1), вероятно, будет легко идентифицировать. Случай 2) немного сложнее обнаружить в простом анализе кода, поскольку он зависит от физической схемы (структуры индекса).

0 голосов
/ 02 марта 2010

запустите трассировку в профилировщике (выберите пустой шаблон), выберите событие графика взаимоблокировок и на новой вкладке, которая появляется (Настройки извлечения событий), сохраните каждое (установите флажок сохранить события взаимоблокировки XML отдельно) в своем файле. Откройте этот файл в программе просмотра XML, и вам будет легко узнать, что происходит. Каждый процесс содержится со стеком вызовов процедур и т. Д., И все блокировки также присутствуют там, так что вы можете быть уверены, что вызывает тупик.

Пусть эта трассировка будет запущена до тех пор, пока не произойдет повторная блокировка, информация записывается только при возникновении тупика, поэтому не слишком много служебной информации.

...