Блокировки БД требуют транзакций?

Верно ли, что «Каждый оператор (выбрать/вставить/удалить/обновить) имеет уровень изоляции независимо от транзакций»?

У меня есть сценарий, в котором я установил обновление операторов внутри транзакции (ReadCommitted). И еще один набор не в транзакции (операторы выбора).

  1. В этом случае, когда выполняется первый набор, другой ждет.

  2. Если я устанавливаю READ_COMMITTED_SNAPSHOT для БД, возникает взаимоблокировка.

    ALTER DATABASE Amelio SET ALLOW_SNAPSHOT_ISOLATION ON
ALTER DATABASE Amelio SET READ_COMMITTED_SNAPSHOT ON

Чтобы решить эту проблему, мне нужно поместить операторы «Выбрать» в TransactionScope?


sql-server transactions isolation-level read-committed-snapshot
person Buzz    schedule 05.02.2010    source источник
comment
Да; все операторы внутри или вне явной транзакции выполняются на некотором уровне изоляции, но какой уровень изоляции зависит от СУБД и настроек, связанных с сеансами, и т. д.   -  person Jonathan Leffler    schedule 05.02.2010
comment
Как он ведет себя в случае sql server.   -  person Buzz    schedule 05.02.2010

Ответы (1)


arrow_upward
2
arrow_downward

В SQL Server каждая транзакция имеет неявный или явный уровень транзакции. Явный, если вызывается с BEGIN/COMMIT/ROLLBACK TRANSACTION, неявный, если ничего подобного не выдается.

Запустите снимок до того, как начнется запрос на обновление. В противном случае вы не дадите SQL Server возможности подготовить измененные строки в базу данных tempdb, а запрос на обновление по-прежнему будет иметь открытую блокировку.

Другим способом без создания изоляции моментальных снимков является использование SELECT <columns> FROM <table> WITH (NOLOCK), который указывает SQL Server, что нужно получить строки несмотря ни на что (он же READ_UNCOMMITED). Поскольку это подсказка запроса, он изменяет уровень изоляции даже с вашими настройками. Может работать, если вас не беспокоит, какое состояние строки запрашивается, однако при оценке полученных данных необходимо соблюдать осторожность.

person KMB    schedule 05.02.2010