УПП взаимоблокировки на регистре партий при перепроведении #755601

Добрый день! Есть такая проблема в УПП: При перепроведении документов "Перемещение товаров" и "Реализация товаров и услуг" происходят взаимоблокировки. В процессе расследования было выяснено, что взаимоблокировки возникают на регистре ПартииТоваровНаСкладах при чтении остатков. У регистра включено разделение итогов. Первая блокировка регистра ставится в момент удаления старых движений (удалять движения автоматически выключено). После этого, видимо, в момент чтения остатков блокировка хочет захватить таблицу остатков, часть которой уже может быть захвачена. Редакция УПП: 1.3.62.1 переписанная. Механизм типовой. По идее, если после записи идет чтение, то для набора записей нужно ставить свойство БлокироватьДляИзменения, но при удалении движений оно не ставиться. Либо убрать у регистра свойство Разделение итогов. Однако смущает то, что такая проблема есть в типовом механизме. Сталкивался ли кто-нибудь с такой проблемой? Если да, то как лучше решать? Может я чего-нибудь не учел и в УПП есть какая-то настройка на этот счет?

ну так двигай партии отдельно, зачем самой реализаций списывать и расчитывать партии. А вообще Рауз форева

нужна упр блокировка ДО чтения остатков

Был выбран именно онлайн расчет партий, ещё до меня, сейчас так работает. Тем более что механизм типовой. Да, это ещё один вариант исправить ситуацию. Сейчас базы под рукой нет, однако если там идет рассчет остатков, то управляемая блокировка все же должна быть до чтения остатков. Однако даже если она есть, то все равно при удалении движений будет блокировка СУБД части записей таблицы итогов (до удаления движения там никаких блокировок точно не ставится). Так что если только ставить управляемую блокировку ещё до удаления движений. Получается, что сначала идет удаление движений - запись, потом чтение остатков, потом запись уже нового набора. А когда идет сначала запись, потом чтение, можно вроде как использовать свойство БлокироватьДляИзменения (если, конечно, проблема в блокировке именно по разделителю). Кстати, между двумя документами ПеремещениеТоваров тоже идет такая взаимоблокировка. Они там все используют одни и те же процедуры для удаления движений и для чтения остатков. Есть у кого-нибудь УПП с онлайн расчетом партий и типовым перемещением? Если открыть две сессии и поперепроводить там перемещения взаимоблокировки есть? Возможно есть какие-то галки, которые можно проставить и все будет работать, а я просто о них не знаю. А так завтра попробую сначала поставить БлокироватьДляИзменения в истину/убрать разделитель и протестировать, если не получится, тогда буду писать управляемые.

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

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

В УПП? есть )))

В общем, основная проблема не в отсутствие упр. блокировок (хотя, конечно, блокировки надо будет поставить), а в не оптимальном запросе. Итоговый запрос, который блокирует регистр при проверке остатков такой:             КОНЕЦ)             И (ПартииТоваровНаСкладах.Склад = СписанныеТовары.Склад ИЛИ ПартииТоваровНаСкладах.Склад = &ПустойСклад)

В УПП есть управляемые блокировки, куда ты собрался их вставить? 0_о

Его план получается вот такой (не знаю, как тут отформатируется): Rows         Executes     StmtText                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      StmtId       NodeId       Parent       PhysicalOp           LogicalOp            Argument                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             DefinedValues                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               EstimateRows EstimateIO   EstimateCPU  AvgRowSize   TotalSubtreeCost OutputList                                                                                                                                                                                                                                                                                                                                                                  Warnings     Type         Parallel     EstimateExecutions

+ Так же естественно при проверке остатков и записи может блокироваться большой диапозон запией который приводит к эскалации. Так что лучшим решением это отложенное проведение по партиям.

не от запроса.

Да, точно, это после улучшения...

Старый я что-то не сохранил, это при помещении во временную таблицу партии товаров на складах, там из-за условия по ИЛИ план возвращает 56000 записей для физ таблицы партий.

ну не сам план в конце, а промежуточно

вот тебе и ответ 56000 строк.

Блокировки-то есть, но вот только перед удалением движений никаких блокировок не ставится, а сам факт удаления движений порождает Х-блокировку СУБД. по небольшому набору. А потом при проверке остатков из-за запроса ещё проставляется S-блокировка на больший диапазон.

Повторюсь, уже давно определились что надо делать, но ты упорный, толку только ноль.

Все правильно, а говоришь что блокировок нет.

Ну так в том месте где нужно, управляемых блокировок нет. А я сказал только о блокировках СУБД. После исправления запроса риск взаимоблокировки все равно останется.

Блокировки есть, так где они нужны они установлены. При записи набора явно прописывать блокировки не нужно. Еще раз, тебя не смущает эскалация? Так что решение тут дано не раз

Эскалация? Конечно я её исправлю. Я просто говорю, что взаимоблокировки все равно будут. Гораздо реже (может даже не встретятся), но будут.

к

точнее к

Решение у меня есть. Я просто отписываюсь, в чем в итоге была проблема и как её буду исправлять.

Почему ты считаешь, что при записи набора не надо прописывать блокировки? Ведь при контроле остатков, даже если убрать эскалацию, все равно будет блокироваться больший диапазон, чем блокируется при удалении движений? По крайней мере у меня после того, как я убрал условие по ИЛИ в параметрах вирт таблицы (ну ещё вынес подзапросы во временные на всякий случай) все равно выбиралось около 400 записей в процессе работы плана запроса.

при записи блокировки устанавливаются АВТОМАТИЧЕСКИ

Опять же если включено разделение итогов, то такой блокировки НЕ ДОСТАТОЧНО

Возможно, действительно, после исправления запроса будут выбираться только записи по набору измерений в наборе и тогда останется только поставить флаг БлокироватьДляИзменения при записи набора (разделение включено) и не ставить управляемые блокировки. Надо смотреть...

Только этого может быть недостаточно. Например, если мы в проведенном документе добавили строку, а потом нажали перепровести, то у нас: Удаляются движения - блокировка набора без новой строки. Запрос остатка - Блокировка всех записей с новой строкой. Результат предсказуем.

И какой результат? )))

Пока результат такой - после оптимизации запроса взаимоблокировки остались. После детального изучения выяснилось, что 56000 строк после выполнения Clustered index seek - это если не использовать индекс ни по складу, ни по номенклатуре. После оптимизации запроса - 400 строк это без использования индекса по номенклатуре. Посмотрел, какие там вообще индексы есть. Оказалось, по номенклатуре вообще индекса нет. Номенклатура стоит первым измерением, но для регистров накопления это не важно. Снял замок с номенклатуры и проиндексировал. Сейчас протестировал - взаимоблокировок не тех документах, на которых раньше были сейчас нет. Это с учетом нового запроса и прописанных мною блокировок. Завтра уберу управляемые блокировки, оставлю только флаг БлокироватьДляИзменения на будущее и снова протестирую.