Блокировки ms sql, вопрос. #658363

Разбирался почему не удается провести параллельно два разных заказа покупателя с одинаковой номенклатурой. В итоге выяснил следующее: Запускаем последовательно в разных сеансах код: В каждом сеансе устанавливается отбор на разные заказы, причем в записях регистра по этим заказам есть некоторая общая номенклатура. Для ДЛЯ ИЗМЕНЕНИЯ указано, чтобы получить SERIALIZABLE, режим блокировок - автоматический. У регистра проиндексированы измерения ЗаказПокупателя и Номенклатура Запросы выполняются параллельно, конфликта блокировок нет. Теперь если же добавить в условие запроса еще и отбор на общую для этих заказов номенклатуру: ЗаказыПокупателей.Номенклатура = &Ном, и повторить параллельный запуск то второй запрос отвалится по таймауту на блокировке. Пытаясь понять в чем дело я посмотрел планы запросов, во втором запросе добавляется Index Seek по индексу по номенклатуре, в результате залоченнымми оказываются все записи с указанной номенклатурой, получается избыточная блокировка. Это сразу должно было быть понятно? Может убрать нафиг этот индекс по номенклатуре? Конфа на базе УТ 10. Поправьте, что не так.

добавь дату в условия

ну и да - правильнее на управляемые блокировки переходить

+ а, это ТЧ - тогда фигню сморозил, ХЗ чтотам :( разве только во вложенный запрос оборачивать

в смысле ТЧ? Запрос к таблице РГ накопления

это я туплю! тогда дата поможет!

или предварительно сделать запрос по регистру без ДЛЯ ИЗМЕНЕНИЯ, вытащив регистраторы, а потом вторым запросом залочить с отбором по регистраторам

ДЛЯ ИЗМЕНЕНИЯ это хинт поставить U блокировку, SERIALIZABLE ставится в автоматическом режиме у необъектных данных.

т.е. Вы хотите получить от блокировок MS SQL тот же эффект, как если бы был управляемый режим блокировок? на набор измерений?

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

регистр подчинён регистратору, если в разрезе него вытащить данные - то и получится типа управляемой блокировки, на наборы записей регистраторов. иль не?

а чем здесь управляемый режим поможет? Менеджер блокировок пропустит обе исключительеные блокировки, а дальше в ms sql уже отвалится по блокировкам субд

вместо REPEATABLE READ будет READ COMMITTED

+ но скажи лучше, помогло ли добавление периода (хоть и изврат :) )

вместо SERIALIZABLE

для мсскуля - именно repeatable read

если задавать условие на равенство периода, то получается один Clustered Index Seek и все хорошо, если период =< задать, то тот же план что и без условия на период с поиском по индексу номенклатуры

а у тебя документы разными периодами пишут данные?

изыскания начались с того что в модуле проведения (документ изменение заказа) есть запрос по этому регистру, к ВТ обороты, который не имеет ограничений по началу периода, а по концу периода ограничен моментом времени проводимого документа,  отсюда получился тестовый запрос к записям таблицы движений регистра и ограничение на период <= а ведь верное замечание  должно быть насчет управляемых блокировок. На скуле всегда будет read committed, а что выше обеспечивает уже  менеджер блокировок 1с, а на скл уходит в любом случае  read committed, так ведь?. И такая ситуация как в примере через явное наложение блокировок должна разрешиться думаю имелл ввиду что вместо serializable, как в моем примере.

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

.2 да

если речь про ресурс оборот

ок, спс

В можно выйти из положения, поместив выборку по ЗаказуПокупателя во временную таблицу, а потом её уже отфильтровать по номенклатуре.