Лучший уровень изоляции, чтобы избежать взаимоблокировок с использованием предложения UPDATE в Sql Server 2005

Question

мне нужно выполнить оператор un update над таблицей sql server, эта таблица используется другим процессом одновременно. потому что иногда происходит тупиковая ситуация. Какой уровень изоляции вы рекомендуете избегать или минимизировать эти тупики?

Answer 1

READ UNCOMMITTED

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

Вы можете предпочесть включить управление версиями строк, обновление создает новую версию строки, а любые другие операторы выбора используют старую версию, пока эта фиксация не будет зафиксирована.Для этого включите режим READ_COMMITTED_SNAPSHOT.Больше информации здесь .Поддержание версий строк связано с дополнительными затратами, но устраняет тупиковые ситуации UPDATE / SELECT.

Answer 2

Предложения по использованию READ UNCOMMITTED в порядке, но они действительно обошли стороной вопрос, почему вы вообще зашли в тупик.Если вас не волнует грязное чтение, тогда это нормально, но если вам нужны преимущества изоляции (согласованность и т. Д.), Тогда я рекомендую выяснить правильную стратегию блокировки в вашем приложении.

У меня нетОтвет на этот вопрос - я сам разработал некоторые стратегии.См. Комментарии к этому вопросу для обсуждения.

Answer 3

Изучите изоляцию моментальных снимков - использование этого уровня изоляции является хорошим компромиссом между согласованностью и скоростью.Возможно, я застрелен в огне за эти слова, однако я считаю, что с тупиками гораздо сложнее встретиться на этом уровне изоляции.

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

Answer 4

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