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

[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. Тоже, на самом деле, не идеальный вариант. Во первых - часть полезного пространства блока отъедается под данные о блокировках, во вторых - если ты с числом слотов под данные о блокировках не угадал при создании таблицы, то транзакции точно также блокируются в ожидании места под запись о блокировке, даже если никаких объективных конфликтов блокирования нету... Ну то есть - оба подхода имеют свои плюсы и минусы, в каких-то случаях оракловский подход лучше работает, в каких-то микрософтовский. Хочешь работу без эскалации, будь готов получить какие-то другие грабли взамен...

[Logger]

Цитата:

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

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

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

По опыту использования - мы на такие блокировки вроде бы не натыкались. Видимо наш админ угадал с числом слотов под блокировки. Либо значение по умолчанию там удачное стоит.

[Maxim Gorbunov]

Пожалуй, оставлю здесь ссылку на свою связанную тему:

Нефинансовые перемещения не раскрываются при отмене закрытия

[EVGL]

Цитата:

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

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

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

Цитата:

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

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

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