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

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

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

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

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

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

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

Источник

5 ответов

Решение

НЕТ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ТУПИК

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

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

Источник

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

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

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

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

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

Источник

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

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

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

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

Учитывать:

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

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

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

Источник

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

Источник
Другие вопросы по тегам