DynamicsAxSCM: Back ported features from Dynamics AX 2012 to Dynamics AX 2009

[Blog bot]

Источник: http://blogs.msdn.com/b/dynamicsaxsc...s-ax-2009.aspx
==============

Some of the new functionality that is created in the Dynamics AX development cycle brings about so much feedback from customers and partners that we decide to back port the features to previous versions of Dynamics AX products. The back ported features become available as part of hot fixes or service packs to previous versions of Dynamics AX.

Today, we would like to bring your attention to the great SCM features that were developed as part of the Dynamics AX 2012 release cycle and which are already included in Dynamics AX 2009 Service Pack 1 (Hotfix rollup 5 for Microsoft Dynamics AX 2009 Service Pack 1)

Close non-financial transfers

This feature significantly improves performance for the inventory closing and inventory recalculation processes. The essence of the feature is the fact that inventory transactions which represent the physical transfers are disregarded during cost calculation. For example, inventory transactions might indicate a physical item movement between different warehouses or warehouse locations. However, from a costing perspective, the movement does not contribute to the final item cost.

With the new approach, the cost calculation process becomes significantly faster and more accurate. Please refer to the following white paper to learn more about the feature. Microsoft Dynamics AX 2009 White Paper: Close Non-Financial Transfers

Inventory Reconciliation and Reporting

The Inventory value report framework allows you to report and reconcile Inventory and WIP values on one report. The new report framework replace six individual reports and manual adjustments, which were required in previous versions of Dynamcs AX to achieve the same result.

Also, the Potential conflicts report can be used to report transactions that violate rules as defined by parameter settings in various modules. This report significantly reduces the time spent on identifying the causes of discrepancies between Inventory and General ledger values. Please refer to the following white paper to learn more about the feature. Microsoft Dynamics AX 2009 White Paper: Inventory Reconciliation and Reporting



Disclaimer

All the information about AX 2012 posted here is a pre-release. Any feature is a subject to be changed before the release without notice.
This disclaimer is applicable to all posts about AX 2012 in this blog.




Источник: http://blogs.msdn.com/b/dynamicsaxsc...s-ax-2009.aspx

[EVGL]

Close non-financial transfers - хреновая штука, при тестировании, которое коллега проводил, создавало блокировки и могло бы потенциально остановить работу предприятия.

[fed]

Цитата:

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

Close non-financial transfers - хреновая штука, при тестировании, которое коллега проводил, создавало блокировки и могло бы потенциально остановить работу предприятия.

Там все нефинансовые переносы закрываются в одной транзакции. При этом на каждую группу складских аналитик генерится один нехилый update. (Можно посмотреть в inventCostNonFinancialTransferHandler.updateInventTrans()). Как только число обновляемых записей в одном update превысит порог в 5000 (кажется такой порог сейчас в SQL Server 2005/2008), начнется эскалация блокировок с записей на страницы и кучу невинных пользователей заблокируют нахрен.

Возможное решение проблемы - переписать этот класс на обновление по одной номенклатуре, и переместить вызов куда-нить в inventCostItemDim.updateItem(), в ту веточку которая только на нулевой итерации отрабатывает. Я, правда,этого не пробовал.
Кроме того, мне не нравиться что эти складские проводки закрываются вообще без создания записей в inventSettlement. Почему-то для закрытых проводок по услугам, такие записи создаются, а для нефинансовых переносов - нет...

[Ievgenii]

Спасибо за отзывы. Интересно!

Цитата:

5000 (кажется такой порог сейчас в SQL Server 2005/2008),

Порог там вроде 50.000-70.000, но это конечно ничего не меняет.

Цитата:

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

Хм, тут наши ПМы очень хотят понять что имено будет блокироваться, как долго и почему это так критически. Пожалуйста опишите более детально. Спасибо!

История у этой фичи такая, что она ускоряет IC чуть не в 3 раз для наших TAP AX 2012 и Dynamics AX 2009 пользователей (которые с ней работают сегодня). То есть, ее перенесли на прошлую версию иммено потому что она конкретно ускоряет IC. Более того, это первый раз мы получаем негативный отзыв о фичи за 2 года..

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

Цитата:

Возможное решение проблемы - переписать этот класс на обновление по одной номенклатуре,

По разным причинам (не предмет обсуждения) эта фича так и реализована в Dynamics AX 2012 .

Цитата:

Кроме того, мне не нравиться что эти складские проводки закрываются вообще без создания записей в inventSettlement. Почему-то для закрытых проводок по услугам, такие записи создаются, а для нефинансовых переносов - нет...

Наши ПМы убедеждены что этого делать не надо, чтобы не терять времени. По-этому для не финансовых переносов убрали. Для услуг - это легаси код, который не меняли.

[fed]

Про полезность фичи, никто не спорит. Но как-то отрыв inventTrans от inventSettlement несколько смущает.В прочем на фоне того что натворили в DAX2012, это не самая большая проблема совместимости.
Эскалация блокировок (если верить MSDN), случается если "A single Transact-SQL statement acquires at least 5,000 locks on a single nonpartitioned table or index."
Теперь представь картину:
1. У нас есть 10 групп складской аналитики
2. По каждой группе система одним update'ом помечает нефинансовые переносы закрытыми. Есть большие шансы что часть этих updateов будет обновлять более 5000 записей и блокировки будут эскалированы до уровня страниц.
3. Я, конечно, не до самого конца понимаю, как как эскалация блокировок работает, но рискну предположить что по кластерному индексу окажутся заблокированы записи с соседними inventTransId, которые (вполне возможно) не имеют отношения к текущему закрытию и вообще еще в статусе Ordered/onOrder.
4. Как результат, либо закрытие будет ждать пользователей, которые заблокировали записи, не имеющие отношения к закрытию, либо наоборот - пользователи будут ждать закрытия.
5. Поскольку блокировки будут создаваться не все сразу, в порциями по одному созданию (и ожиданию) блокировок на одну группу складских аналитик, шансы на создание дидлока или, по крайней мере, дерева блокировок, резко возрастают.

То есть - идея состоит не в том чтобы от механизма отказаться, в просто в том чтобы постараться не генерировать update-statement, которые обновляют слишком много складских проводок в одной операции...

[fed]

Цитата:

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

Наши ПМы убедеждены что этого делать не надо, чтобы не терять времени. По-этому для не финансовых переносов убрали. Для услуг - это легаси код, который не меняли.

В качестве конструктивного предложения: Может для приходов закрытых без использования inventSettlement, устанавливать какую-то новую птичку в inventTrans ? Чтобы можно было бы легко подкурочить всякие самописные отчеты на неиспользование таких проводок...

[fed]

Цитата:

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

В качестве конструктивного предложения: Может для приходов закрытых без использования inventSettlement, устанавливать какую-то новую птичку в inventTrans ? Чтобы можно было бы легко подкурочить всякие самописные отчеты на неиспользование таких проводок...

Оказывается галочка-то уже есть. Называется NonFinancialTransferInventClosingRecId и содержит ссылку на inventClosing.recId, по которой данная запись была закрыта. Осталось в этот же механизм услуги засунуть, и все более или менее логично получится...

[Ievgenii]

Ясно. Посмотрим что можно сделать.

[Logger]

Цитата:

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

Ясно. Посмотрим что можно сделать.

Кстати, а по поводу этого
пересчет себестоимости в журналах переноса?

ПМ-ы ничего нового не решили ?
Переносы и заполненные лоты возврата в будущем продолжат себестоимости разных аналитик перемешивать ? (по-моему, так это просто дыра в архитектуре - пока она не вылечена - нет смысла говорить о LIFO, FIFO при расчете себестоимости)

[fed]

Кстати - насчет двух лет: Фича была включена в ru6, которая вышла не так уж давно. До этого она существовала в качестве патча (который не так уж много кто ставил). В ru6 и ru7, чтобы фича работала, нужно включить галочку, про которую мало кто знает...
Возможно статистика за 2 года, она не совсем представительная...

[Ievgenii]

Спасибо за детальный ответ! Проблема ясна, более того SQL lock manager довольно быстро ескалайтит описанную ситуацию до полного блокинга всей таблицы.

Наши ПМы рассуждают так:
1. Блокировка всей таблицы может возникнуть только если за последний период существует большое количество не финансовых переносов. С их опыта и опыты кастомеров что используют фичу такое не случаеться у них на практике (бизнесы такие наверное). Я так понял что речь идет о интервале в 1 месяц.
2. IC рекомендуеться запускать когда система минимально используеться пользователями и тут нам важно скорость выполнения. Например, в MRP некоторые транзакции удаляються по номенклатурам. При этом подходе само выполнени естественно медленее, но блокировок значительно меньше может быть. В нашем случае - это не target сценарий, ибо IC запускаеться на огромные обьемы данних не каждый день.
3. Из пункта 1 следует что в самом плохом случаи идет речь о обновлении несколько тысяч записей. Сколько это займет на современном сервере? На моей машине (далеко до самого современного сервера) 1 мил. записей занимает вроде 2-5 минут, точно не помню.

Выводы (не окончательные)
1. Проблема если и случаеться, то должа случаться крайне редко. Блокировка может мериться в секундах.

Евгений,
Расскажы пожалуйста немного о ваших данных на которых тестировали.

Чтобы все понимали - у нас в МС ваши отзывы все утро обсуждаем :0)

[egorych]

Цитата:

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

Выводы (не окончательные)
1. Проблема если и случаеться, то должа случаться крайне редко. Блокировка может мериться в секундах.

Понимаете в чем вопрос-то - если в момент эскалации есть блокировки на другие номенклатуры/аналитики, то этот самый lock manager остановится и будет ждать! Соответственно то что он успел залочить так и будет лоченое. Далее все нарастает лавиной - другие юзеры начинают становиться в ожидание, тоже залочив какие-то записи и т.д. - до полной победы блокировок над всеми пользователями!
И поверьте - при кол-ве пользователе от 100 это дело 10 секунд!
Поэтому, если есть возможность - нужно избегать подобных алгоритмов, ну или сразу лочить таблицу, делать что надо и отпускать - так будет действительно быстро и надежно.

[Logger]

Цитата:

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

...
Наши ПМы рассуждают так:
...

Хм. Но ведь для 2012-й проблемы блокировок нет, сделали все так как и fed предлагал.
Уж так и бы и сказали что не хотят ничего менять в 2009-й

P.S.
Вопрос наверно для другой ветки, но неужели MS до сих пор не может решить проблему эскалации блокировок ? Неужели нельзя сделать настоящий версионник, а-ля Оракл, Postgre, FireBird и не мучаться ? Мы сейчас живем на оракл - вообще не знаем таких слов "эскалация". Очень радует

[fed]

Цитата:

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

Вопрос наверно для другой ветки, но неужели MS до сих пор не может решить проблему эскалации блокировок ? Неужели нельзя сделать настоящий версионник, а-ля Оракл, Postgre, FireBird и не мучаться ?

Версионник уже давно сделали. Но блокировки все равно нужны для:
1. Предотвращения конфликтов записи
2. Ситуаций, грубо говоря, продажи билетов на поезд. Когда надо обеспечить чтобы между чтением ресурса и его обновлением он был заблокирован и недоступен для обновления другими сессиями.

Кроме того, сами по себе эскалация блокировок - не такое уж зло. Если у тебя таблица построчных блокировок разростается в памяти, то каждая новая операция обновления занимает все больше времени, поскольку надо все больше и больше времени искать в таблице блокировок ID текущего объекта. И во многих случаях, эскалация на самом деле повышает производительность работы с БД. Идеальным вариантом, на мой взгляд, была бы возможность отключать эскалацию каким-то хинтом в конкретном запросе, а главное - интерфейс к этому хинту из X++.

[Logger]

Цитата:

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

Версионник уже давно сделали. Но блокировки все равно нужны для:
1. Предотвращения конфликтов записи
2. Ситуаций, грубо говоря, продажи билетов на поезд. Когда надо обеспечить чтобы между чтением ресурса и его обновлением он был заблокирован и недоступен для обновления другими сессиями.

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

Цитата:

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

Кроме того, сами по себе эскалация блокировок - не такое уж зло. Если у тебя таблица построчных блокировок разростается в памяти, то каждая новая операция обновления занимает все больше времени, поскольку надо все больше и больше времени искать в таблице блокировок ID текущего объекта. И во многих случаях, эскалация на самом деле повышает производительность работы с БД. Идеальным вариантом, на мой взгляд, была бы возможность отключать эскалацию каким-то хинтом в конкретном запросе, а главное - интерфейс к этому хинту из X++.

Ключевое слово - "памяти". Денис, ты неявно предполагаешь какую то конкретную реализацию механизма блокировок (как я понимаю майкрософтовскую) и говоришь о её недостатках. Если не ошибаюсь оракл хранит инфу о блокировках на диске в самих записях, так что при большом числе блокировок памяти дополнительной не тратится. Работает достаточно шустро.

Наверно есть и другие способы реализации механизма блокировок, экономно расходующие память и прочие ресурсы БД. Обсуждение куда-то в сторону уходит.

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

[Evgeniy2020]

а OCC выключен для этих таблиц? или в данной задаче OCC не поможет?
или там принудительно включен PCC?

[fed]

Цитата:

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

Ключевое слово - "памяти". Денис, ты неявно предполагаешь какую то конкретную реализацию механизма блокировок (как я понимаю майкрософтовскую) и говоришь о её недостатках. Если не ошибаюсь оракл хранит инфу о блокировках на диске в самих записях, так что при большом числе блокировок памяти дополнительной не тратится. Работает достаточно шустро.

Я когда-то на информиксе начинал. Там таблица блокировок в памяти хранилась, при этом размер таблицы блокировок был фиксированным и задавался в конфигурационном файле. Если ты пытался обновить больше строк чем было свободного места в таблице блокировок, то твой update, без объявления войны, завершался с кодом ошибки. Там мне как раз эскалации не хватало, поскольку при загрузке справочников приходилось их резать на порции по 10000 записей. (Возможно в свежих версиях информикса это дело поправили, но я давно им не занимаюсь).
В оракле информация о блокировках храниться в заголовке блока. Подробности про это рассказаны в http://my-oracle.it-blogs.com.ua/post-239.aspx. Тоже, на самом деле, не идеальный вариант. Во первых - часть полезного пространства блока отъедается под данные о блокировках, во вторых - если ты с числом слотов под данные о блокировках не угадал при создании таблицы, то транзакции точно также блокируются в ожидании места под запись о блокировке, даже если никаких объективных конфликтов блокирования нету... Ну то есть - оба подхода имеют свои плюсы и минусы, в каких-то случаях оракловский подход лучше работает, в каких-то микрософтовский. Хочешь работу без эскалации, будь готов получить какие-то другие грабли взамен...

[EVGL]

Цитата:

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

Евгений,
Расскажы пожалуйста немного о ваших данных на которых тестировали.

Я попросил человека, который этим занимался, отписаться в тему по-английски. Надеюсь, в течение 2-3 дней он найдет время.

Цитата:

Наши ПМы рассуждают так:
1. Блокировка всей таблицы может возникнуть только если за последний период существует большое количество не финансовых переносов. С их опыта и опыты кастомеров что используют фичу такое не случаеться у них на практике (бизнесы такие наверное). Я так понял что речь идет о интервале в 1 месяц.
2. IC рекомендуеться запускать когда система минимально используеться пользователями и тут нам важно скорость выполнения. Например, в MRP некоторые транзакции удаляються по номенклатурам. При этом подходе само выполнени естественно медленее, но блокировок значительно меньше может быть. В нашем случае - это не target сценарий, ибо IC запускаеться на огромные обьемы данних не каждый день.

Чтобы пояснить: на наших подшефных предприятиях количество нефинансовых переносов зашкаливает, поскольку каждая машина подключена к складу, имеет входную и выходную ячейки. Каждые 100 штук в коробке получают серийный номер; один производственный заказ делает до 5 000 000 штук меньше, чем за неделю. Это связано со спецификой отрасли, где нужно отследить потенциально опасную партию, попавшую в соприкосновение с пищей (см. историю с микробами EHEC : ). Тем самым за 3 года набежало около 15 млн. складских проводок, из которых большая часть - переносы сер. номеров из ячейки А в ячейку Б.

Запустить закрытие склада тогда, когда хочется, можно не всегда. Подшефные заводы работают в режиме 24x7 или 24x5. Даже в последнем случае не всегда получается запустить закрытие на выходных, поскольку внутренный распорядок концерна предполагает закрытие месяца и подготовку отчетности в первые три рабочих дня. Если первый день месяца выпадает на понедельник - среду, то возможности ждать нет, а по опыту незакрытые приходы/расходы за месяц значительно искажают баланс.

[fed]

Не забывай что:
1. Кроме эскалации блокировок до уровня таблицы есть еще и эскалация блокировок до уровня страниц. Она как раз гораздо чаще случается.
2. Проблема в том, что да, каждый индивидуальный апдейт идет быстро ( секунд 10-15). Но, поскольку вся операция идет в одной транзакции, то после очередного апдейта записи (а скорее - страницы) остаются заблокироваными в то время пока система ждет доступности блокировок записей по очередной группе складских аналитик. Получается что мы можем заметную часть активных (не очень старых) записей в inventTrans заблокировать, а потом впасть в зависание потому что кто-то из пользователей почему-то заблокировал запись которую мы хотим обновить. В итоге - у нас куча записей (точнее страниц) заблокирована, а мы никого не пускаем и ждем пока какой-то отщепенец, работающий по ночам, освободит свою единственную обновленную запись.
То есть - можно попробовать решить проблему просто заменив одну большую транзакцию на несколько не очень больших ( по одной транзакции для каждой группы складских аналитик). Конечно экскалации при этом остануться (и это по прежнему нехорошо), но ситуации когда мы какие-то записи (скорее страницы) мы заблокировали, и с заблокированными страницами чего-то ждем - удастся избежать...

P.S. Привет AEGу

[fed]

OCC помогает (точнее вообще хоть как-то работает и на что-то влияет), только в том случае, если ты сначала читаешь запись через select forupdate table, а потом обновляешь ее через table.update(). Если у тебя update_recordset, то записи выбираются, лочаться и обновляются одной операцией на сервере БД. При этом поднятые блокировки держаться до конца транзакции. Соответственно - OCC/PCC в этом случае никак не влияет.