Уровни изоляции SQL Server - повторяемое чтение

Question

У меня проблемы с пониманием, почему это происходит. Я уверен, что понимаю теорию, но должно происходить что-то еще, чего я не вижу.

Таблица A имеет следующую схему:

ID [Primary Key]
Name
Type [Foreign Key]

SprocA устанавливает уровень изоляции для повторяемого чтения и выбирает строки из таблицы A, которые имеют Type=1, Это также обновляет эти строки.

SprocB выбирает строки из таблицы A, которые имеют Type=2,

Теперь, учитывая, что это совершенно разные наборы строк, если я выполняю оба одновременно (и положить WAITFOR звонки, чтобы замедлить его), SprocB не завершается, пока SprocA.

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

Кто-нибудь пролил свет?

ура

Answer 1

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

Answer 2

С Repeatable Read, установленным для уровня изоляции, вы будете удерживать общую блокировку для всех прочитанных данных до завершения транзакции. То есть, пока вы не совершите или ROLLBACK.

Это снизит параллелизм доступа вашего приложения к этим данным. Таким образом, если ваша первая процедура SELECTS from table затем вызывает WAITFOR, затем SELECTS снова и т. Д. В транзакции, вы будете удерживать общую блокировку все время, пока вы не завершите транзакцию или процесс не завершится.

Если это тестовая процедура, с которой вы работаете, попробуйте добавить COMMIT после каждого выбора и посмотреть, поможет ли это второй процедуре работать одновременно.

Удачи!

Kevin

Answer 3

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

Вы знаете, что SprocA просто читает для type = 1, а SprocbB просто читает для type = 2.

Однако SprocB не знает, что SprocA собирается сделать с этими записями. До завершения транзакции SprocA может обновить все записи до типа = 2. В этом случае SprocB будет работать некорректно, если не будет ожидать завершения SprocA.

Поддерживать параллелизм при выполнении блокировок диапазона / массовых изменений довольно сложно.