Мертвые блокировки при резерве

[Logger]

Цитата:

Сообщение от Torin

Logger, мы не сдвинемся с места, пока не скажете, участников дедлока, что они делали, и на каком уровне дедлок (запись, страница и т.п.). Подозреваю, что Оракл может также сказать на каком объекте и еще массу полезной информации.

Дедлок был на запросах вида

SELECT a.itemid, a.postedqty, a.postedvalue, a.deducted, a.received, a.reservphysical, a.reservordered, a.onorder, a.ordered, a.quotationissue, a.quotationreceipt, a.del_configid, a.inventdimid, a.closed, a.registered, a.picked, a.availordered, a.availphysical, a.physicalvalue, a.arrived, a.physicalinvent, a.closedqty, a.lastupddatephysical, a.lastupddateexpected, a.postedvalueseccur_ru, a.physicalvalueseccur_ru, a.recid

FROM inventsum a

WHERE ((SUBSTR(NLS_LOWER(dataareaid), 1, 3) = NLS_LOWER(:in1))
AND ((SUBSTR(NLS_LOWER(itemid), 1, 20) = NLS_LOWER(:in2))
AND (SUBSTR(NLS_LOWER(inventdimid), 1, 20) = NLS_LOWER(:in3)))) FOR UPDATE

Вроде как на записях (ну оракл обычно по записям и блокирует - по странично это MS SQL) - но точно сейчас не скажу.

[itfs]

Возникла мысль в защиту сортировки по lineNum, по факту в рамках заказа он совпадает с сортировкой по inventTransId. Не берусь судить, но может так получиться, что при смене сортировки от дедлоков в inventsum можно плавно перейти к дедлокам в inventTrans. А в рамках вашего рассуждения, полностью согласем. по itemId логичнее.

С уважением, itfs.

[Logger]

Цитата:

Сообщение от itfs

Возникла мысль в защиту сортировки по lineNum, по факту в рамках заказа он совпадает с сортировкой по inventTransId. Не берусь судить, но может так получиться, что при смене сортировки от дедлоков в inventsum можно плавно перейти к дедлокам в inventTrans. А в рамках вашего рассуждения, полностью согласем. по itemId логичнее.

С уважением, itfs.

А как возникнут дедлоки по InventTrans ? Поясните, я не понимаю.

[Logger]

Цитата:

Сообщение от itfs

Возникла мысль в защиту сортировки по lineNum, по факту в рамках заказа он совпадает с сортировкой по inventTransId. Не берусь судить, но может так получиться, что при смене сортировки от дедлоков в inventsum можно плавно перейти к дедлокам в inventTrans. А в рамках вашего рассуждения, полностью согласем. по itemId логичнее.

С уважением, itfs.

Кстати, они не совпадают. Если не ошибаюсь, то строчки можно вставлять между. Так что LineNum может быть дробный и даже отрицательный.
а InventTransId всегда растет, так как получается по номерной серии.

Если пользователи вставляли строки не в конец а в начало или где то посередине, то сортировки по LineNum и по InventTransId гарантировнано не совпадут

[Recoilme]

Цитата:

Сообщение от Logger

Ну я же написал в самом начале. :-(
Работа с разными строчками идет в одной транзакции, а заказы - в разных обрабатываются с разных рабочих мест, но одновременно

Ну смотрите :

заказ 1
Строка 1 Номенклатура1
Строка 2 Номенклатура2

заказ 2
Строка 1 Номенклатура2
Строка 2 Номенклатура1

С одного рабочего места начинается транзакция, которая перебирает строки заказа1
обновила строку с номенклатурой1 и на соответсвующей InventSum повесила блокировку, так что другая транзакция не сможет получить её forUpdate ( на чтение прочитает, а forUpdate - фиг)

Ну и что???
Смените Вы сортировку, что от этого изменится-то?? Не понимаю...
заказ 1
Строка 1 Номенклатура1
Строка 2 Номенклатура2
Строка 3 Номенклатура3

заказ 2
Строка 3 Номенклатура3
Строка 2 Номенклатура4
Строка 1 Номенклатура5

заказ 3
Строка 3 Номенклатура2
Строка 2 Номенклатура3
Строка 1 Номенклатура4

?????

[itfs]

Цитата:

Сообщение от Logger

Кстати, они не совпадают.

Да, мысль была так себе видно пора домой ....

С уважением, itfs.

[Logger]

Цитата:

Сообщение от Recoilme

Ну и что???
Смените Вы сортировку, что от этого изменится-то?? Не понимаю...

А то, что одна из транзакций заблокирует Номенклатуру1 а другая будет тоже пытаться заблокировать Номенклатуру1 , но не сможет и будет ждать окончания работы первой транзакции. Первая транзакция успешно отработает, потому что вторая транзакция не блокировала номенклатуру2, а просто курила бамбук все это время. Таким образом первая транзакция благополучно завершается, а вторая после этого продолжает работу.

Есть блокировка на некоторое время но нет мертвой блокировки и это хорошо !

[Волчара]

Цитата:

Сообщение от Wamr

Простое решение - сделать резервирование по всем строкам с транзакцией только на 1 строчку, а не весь заказ.

Вот предложено идеальное решение, существенно сокращает размер транзакции и как следствие транзакции не будут пересекаться...

Или у вас такой особый бизнес-процесс, что это не возможно?

[Logger]

Цитата:

Сообщение от Волчара

Вот предложено идеальное решение, существенно сокращает размер транзакции и как следствие транзакции не будут пересекаться...

Или у вас такой особый бизнес-процесс, что это не возможно?

Нароооод, ну почитайте постинги.
Идея действительно классная.

Но я же в самом начале ответил Wamr-у что для нас это наприменимо. Почему - долго объяснять. А вы опять то же самое повторяете.


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

[Волчара]

Цитата:

Сообщение от Logger

Не получится так.
Я тоже хотел для оптимизации сделать резерв по каждой строке в отдельной транзакции. Но по ряду причин требуют чтобы в одной транзакции было резервирование всех строк.

Если неправильно использовать механизмы системы то можно получить необходимость резервирования в одной транзакции...
Например если процесс резервирования использовать вместо документа "Заявка" или что то в этом роде...
Вы не моглибы по подробней описать причины, по которым приходится резервировать все целиком в одной транзакции?

Цитата:

Сообщение от Logger

Да, это DeadLock
Все хинты выключены.
База Оракл.
Версия Ax 3.0 sp3

Хочу обратить внимание, что на частоту DeadLock также влияет качество и настройка аппаратного обеспечения.

[Recoilme]

Если нельзя раздробить транзакции - попробуйте вынести функцию резервирования в пакетный режим, будет последовательная обработка.

[lev]

У меня обсалютно тажа проблема, только на СКЛ2000... И заказы у нас по 2000 а то и по 3000 строк ... пробывали делить транзакции по строкам, не помогло..

[Волчара]

Цитата:

Сообщение от lev

У меня обсалютно тажа проблема, только на СКЛ2000... И заказы у нас по 2000 а то и по 3000 строк ... пробывали делить транзакции по строкам, не помогло..

Господа специалисты, просьба ко всем: Давайте Больше Информации, иначе помочь очень трудно. Например, если один компьютер не видит другой компьютер, то дело может быть в плате, в шнуре, в программе, в настройках и т.е. Все это описать в виде ответа не реально - это статья или книга....

Делить транзакцию по строкам не помогло, совсем?
Надо делать так:
1. Попытаться зарезервировать строчку в отдельной транзакции
2. Если не помогло перейти к следующей строке
3. По завершении, попытаться повторно зарезервировать строчки, где были проблемы...
Если все сделано все правильно то эффект хоть какойто должен быть. Не забывайте его измерять по возможности более точно.

А если после одной не удачной строки отменять все предыдующие, или останавливать процесс, то конечно лучше не будет

Еще раз обращаю внимание, на железо: дело может быть еще и там.....

[AvrDen]

Возникла такая же проблема. В одной транзакции необходимо необходимо произвести резервирование заказа. Заказы бывают по 1000 и более строк. При параллельной обработке таких заказов (абсолютно разные номенклатуры и разные склады) возникают блокировки на InventSum в методе (InventUpd_Rezervation/updateRezerveMore). Тип блокировки Блокировка ключа индексации.
Может кто-нибудь за это время решил эту проблему..

[kashperuk]

Цитата:

Сообщение от AvrDen

Возникла такая же проблема. В одной транзакции необходимо необходимо произвести резервирование заказа. Заказы бывают по 1000 и более строк. При параллельной обработке таких заказов (абсолютно разные номенклатуры и разные склады) возникают блокировки на InventSum в методе (InventUpd_Rezervation/updateRezerveMore). Тип блокировки Блокировка ключа индексации.
Может кто-нибудь за это время решил эту проблему..

Конечно решили.
Разработчики Microsoft Dynamics AX 4.0

Также, следует почитать вот эту статью участника fed
http://www.ms-dynamics.ru/blog/2007/...s-ax-4-i-imts/

[gl00mie]

Цитата:

Сообщение от Logger

Есть проблема - возникают мертвые блокировки при резервировании по заказу. В системе создана функция которая в одной транзакции резервирует все строки по заказу. Мертвые блокировки возникли на таблице InventSum. Первая догадка - мертвые блокировки возникают потому что при резервировании разных заказов номенклатуры в них перебираются в разном порядке. Чтобы этого избежать правильнее было бы везде при переборе строк заказа ставить сортировку по ItemId а также в классах ответственных за резервирование стараться чтобы аналитики перебирались в одном порядке.

Эх, а я надеялся это первым сказать Но уже опередили:

Цитата:

Сообщение от kashperuk

Конечно решили. Разработчики Microsoft Dynamics AX 4.0 Также, следует почитать вот эту статью участника fed http://www.ms-dynamics.ru/blog/2007/...s-ax-4-i-imts/

Именна шта!

Цитата:

От пользователей, работающих со старыми версиями Dynamics AX, достаточно часто приходится слышать жалобы на низкую производительность модуля логистики. Что нибудь типа “У нас стоит сервер БД на 4-х двухядерных Xeon (Opteron), 16 гигабайт оперативки и на небольшой 5 гигабайтной базе [...] можно увидеть длинную очередь блокировок процессов, причем все блокированные процессы ожидают освобождения записей в таблице inventSum

Непонятно, почему разработчики кода из sys-слоя только к 4-й версии додумались, что фигова туча кода завязана на обновление InventSum и выполнение различного рода логики по ходу этого обновления, из-за чего длительность блокировок нескольких записей может заметно затянуться. Цитата оттуда же:

Цитата:

Посмотрев на проблему свежим взглядом, разработчики (кстати – уже в Microsoft, a не в Navision), сделали простой вывод: Раз мы не можем отказаться от блокировки остатков, надо просто перенести операции блокировки остатков, их проверки и обновления в самый конец транзакции, чтобы блокировка (которая длится до конца транзакции) не длились слишком долго. Сделано это было следующим образом: При обновлении таблицы складских проводок (inventTrans), обновления в inventSum НЕ ПИШУТСЯ. Вместо этого добавляется информация об обновлении в таблицу inventSumDelta и inventSumDeltaDim. При этом делается это в основном соединении и транзакции – дополнительных соединений не открывается в принципе.

Отсюда - мораль: на 3-ке надо либо хирургически прикрутить механизм, применяемый в 4-ке (что чревато... и вообще непросто ), либо допиливать выявленные в данном конкретном случае "узкие места"...

Цитата:

Сообщение от Torin

А, ну вот я и пашел себе своей дорогой, раз Оракл ;-) Сори, тут я некомпетентен.

Тю! при чем тут Оракл? Это классическая схема возникновения клинчей (deadlock'ов, взаимоблокировок - как угодно), совершенно, к слову, не привязанная даже к полю деятельности СУБД. Код, выполняющийся в многозадачных ОСях, подвержен этому в не меньшей степени при использовании более чем одного объекта синхронизации. Правда, в тех же многозадачных ОСях есть обычно и штатные механизмы разруливания таких ситуаций (в виндах - SEH).

Цитата:

Сообщение от Logger

Вот я сижу и думаю, почему разработчики аксапты поставили везде сортировки по LineNum. Может какая-то идея хитрая была.

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

[Logger]

Цитата:

Сообщение от gl00mie

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

Дык...
Хочется же надеяться на лучшее.

к слову, проблема вылезает не только при описанном способе резервирования, а и при обработке заказов.

Ну с обработкой заказов скорее всего на IMTS закладывались.