Могу ли я стать жертвой тупика, если я не выполняю запрос в транзакции? - PullRequest
Новая
       26

Могу ли я стать жертвой тупика, если я не выполняю запрос в транзакции?

5 голосов
/ 13 января 2010

Допустим, я открываю транзакцию и выполняю запросы на обновление. 

BEGIN TRANSACTION
UPDATE x SET y = z WHERE w = v

Запрос успешно завершен, и транзакция намеренно остается открытой в течение некоторого времени, прежде чем я решу зафиксировать.

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

Я знаю о SET DEADLOCK_PRIORITY и читал статьи MSDN на тему взаимоблокировок. По логике вещей, поскольку я не стремлюсь активно претендовать на какие-либо дополнительные ресурсы, я не могу представить сценарий, который мог бы запустить алгоритм избежания тупиковой ситуации.

Кто-нибудь точно знает, возможно ли, что простое удержание каких-либо замков может сделать меня подходящей целью? Точно так же может любое состояние низкого ресурса вызвать убийство моего SPID?

Ответы [ 5 ]

3 голосов
/ 09 августа 2011

Чтобы ответить на ваш вопрос: вы можете стать жертвой тупика, если не выполняете запрос в транзакции.

Это нелогично, но вы можете стать жертвой тупика, запустив оператор SELECT.

Это может произойти, если вы выполняете запрос, использующий индекс:

  • вы сканируете индексы в поисках совпадающих строк

  • другой процесс начинает обновление страниц данных

  • теперь вы хотите получать данные со страниц данных из соответствующих строк

    другие блокировки процесса удержания на страницах данных

    вы ожидаете, пока не освободятся блокировки страниц данных

  • другой процесс завершил обновление страниц данных, хочет обновить индексы

    вы держите блокировки чтения на индексах

    другой процесс ожидает освобождения блокировки индекса

  • ТУПИК

Таким образом, строго говоря, вы можете стать жертвой тупика, когда вы не выполняете запрос в транзакции. Другой парень тоже не выполнял свой оператор UPDATE в транзакции.

Никто явно не использует транзакцию, но есть тупик.

3 голосов
/ 13 января 2010
нет

NO

Чтобы возникла взаимоблокировка, все участники цепочки взаимоблокировок должны ожидать ресурса (блокировки). Если ваше соединение не используется, это означает, что оно не выполняет запрос, что означает, что оно не может ждать.

Что касается других состояний, которые могут убить вашу сессию, я могу назвать как минимум три:

  • административные операции, которые используют WITH ROLLBACK_IMMEDIATE
  • переключение при отражении
  • преднамеренно KILL <yourspid>, возможно, как шутка вашего дружелюбного администратора баз данных
0 голосов
/ 13 января 2010

Возможные проблемы:

  1. SQL Server имеет только конечное число блокировок. Можно кончить замки.

  2. Другие ресурсы ограничены (например, память, база данных). Удержание этих ресурсов может привести к их исчерпанию.

  3. Журналы транзакций - логические журналы транзакций не могут быть освобождены для повторного использования, если транзакция открыта. Результатом может быть журнал, который заполняется. Эта проблема может остановить ваш процесс, потому что он остановит весь экземпляр.

Для рассмотрения:

  1. CASCADE: DELETE может содержать только одну таблицу в команде, но отношение CASCADE может касаться других таблиц.

  2. Триггеры: триггеры на измененной таблице могут влиять на другие таблицы.

  3. Команды DELETE и UPDATE могут использовать предложение FROM, которое касается других таблиц. Я никогда не видел этого, но я не исключил бы это.

0 голосов
/ 13 января 2010

Транзакции могут прерваться, вот что происходит.

Поскольку у вас снята как минимум 1 (или более) блокировка обновлений и некоторые из них являются блокировками чтения и сканирования таблиц, вас могут убить, чтобы освободить тупики, созданные другими транзакциями. Код восстановления взаимоблокировок в SQL Server вряд ли будет полностью свободен от ошибок, и ненормально держать транзакцию открытой в течение длительного времени на SQL Server. Однако я не ожидал бы, что это случится часто.

Некоторые системы, когда они отсоединяют проблему типа взаимоблокировки, просто начинают убивать «долгоживущие» транзакции, которые не выполнили сопоставительную работу, чтобы освободить блокировки. Тот факт, что вы не являетесь частью тупиковой петли, не останавливает вас.

Чтобы понять, что происходит в вашем случае , вам придется использовать Sql Server Profiler , чтобы собрать все события, связанные с блокировкой и взаимоблокировкой, а также событие об отмене хорошее соединение, транзакции и т. д. Хорошо, на это потребуется время и хороший уровень понимания событий профилировщика, на которые вы смотрите ...

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

0 голосов
/ 13 января 2010

То, что вы не участвуете в транзакции, не означает, что вы не удерживаете блокировки.

...