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

[Recoilme]

но ведь если все в одной транзакции то какую роль может играть порядок сортировки?
тормозят запросы - их надо оптимизировать, думать не надо )

[Logger]

Цитата:

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

но ведь если все в одной транзакции то какую роль может играть порядок сортировки?
тормозят запросы - их надо оптимизировать, думать не надо )

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

Ну смотрите :

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

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

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

В это же время с другого рабочего места начинается другая транзакция которая обрабатывает заказ 2 обработала в нем строчку номер 1 в которой находится номенклатура 2 и в резульате по номенклатуре 2 повесила блокировку на InventSum, так что никакая другая транзакция не может получить её ForUpdate

А дальше первая транзакция пытается получить forUpdate InventSum с номенклатурой 2 - но не может и ждет завершения второй транзакции.
а вторая транзакция хочет отобрать forUpdate InventSum с номенклатурой 1 но не может, потому что на ней висит блокировка от первой транзакции. И поэтому вторая транзакция тоже ждет.

Вот так они друг друга ждут - классический DeadLock.

Он может длиться сколь угодно долго пока БД по таймауту не откатит одну из транзакций.

Эта фигня может возникать на сколь угодно можных серверах и сколь угодно оптимизированных запросах. Все дело в порядке перебора записей разными транзакциями.


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

[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

?????

[Logger]

Цитата:

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

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

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

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

[Torin]

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

[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 гарантировнано не совпадут

[itfs]

Цитата:

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

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

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

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

[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. Может какая-то идея хитрая была.

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