Аудит блокировок

[miklenew]

Цитата:

Сообщение от Андре

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

Можно в info\add в файл писать весь инфолог.
При обновление этих таблиц всегда setPrefix на номенклатуру есть.

Цитата:

Сообщение от Андре

Ну и не совсем понятно, что даст на практике такая информация.

Да у меня остатки расходяться с проводками.
Написал джобик он недолго работает 10 минут.
Раз в неделю запускаю 6-8 позиций исправляет.
Но надо решать эту проблему.
Есть подозрения что это из-за блокировок.
Хотю удостовериться в этом или в обратном.
Есть мысль на inventTrans insert и update некую проверку повесить на время поиска откуда ноги растут.
Но очень хочется, чтоб это оказалось из-за блокировок.

[Vadik]

Цитата:

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

Да у меня остатки расходяться с проводками.
..
Есть подозрения что это из-за блокировок

Сами по себе блокировки - не абсолютное зло, как многие считают, а одно из средств обеспечения целостности данных в системе, поддерживающей работу нескольких конкурентных пользователей. И являться причиной неверных остатков в нормально спроектированной системе (а стандартную логику AX в области управления запасами я считаю нормально спроектированной ) не могут

Цитата:

Но очень хочется, чтоб это оказалось из-за блокировок

Увы

Я бы прислушался к совету Wamr

Если все-таки очень хочется найти "горячую" номенклатуру, можно попробовать такой "ход конем":
- настраиваем поголовный мониторинг длинных запросов всем пользователям
- включаем на AOS-е опцию internal=comments (в 3.0 работает, как в других версиях - не знаю). Теперь запрос сохранится со значениями литералов (в комментариях)
- собираем эту статистику какое-то время
- далее анализируем с группировкой (приводим текст запроса к varchar и группируем). Так как запрос "тяжелый", желательно делать это не на работающей системе, а выгрузить SYSTRACETABLESQL в отдельную БД. Еще лучше - на выделенный сервер. Еще лучше - дополнительно обработать табличку, добавив хэш по тексту запроса. Я таким образом строил куб на основе SYSTRACETABLESQL

Но все равно непонятно (с), что это даст. Рискну предположить, что "горячей" окажется наиболее часто продаваемая номенклатура. Предложим пореже продавать? Не оценят

[miklenew]

Цитата:

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

Сами по себе блокировки - не абсолютное зло, как многие считают, а одно из средств обеспечения целостности данных в системе, поддерживающей работу нескольких конкурентных пользователей. И являться причиной неверных остатков в нормально спроектированной системе (а стандартную логику AX в области управления запасами я считатаю нормально спроектированной ) не могут

Могут. Сам делал руками кривые проводки на стандарте Ax 3.0 sp4.
Долго подбирал данные, но смог подобрать.
Правда транзакции там ни причем были.
А потом мне нужно это найти не на стандарте.
Прилага на 80% модифицирована по формуле mazzy.

[Logger]

Цитата:

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

Могут. Сам делал руками кривые проводки на стандарте Ax 3.0 sp4.
Долго подбирал данные, но смог подобрать.

Интересно каким образом ?

[miklenew]

Цитата:

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

Интересно каким образом ?

1) Создаём новую номенклатуру new активны склад и ГТД
2) Создаём закупку
3) Создаём строку закупки new 2 шт (скл1 + гтд1) и
4) ещё одну строку закупки new 3 шт (скл1 + гтд2)
5) Разносим отборочную накладную
6) создаём журнал перенос (резервирование автоматическое)
7) Создаём строку журнала new 6 шт скл1->скл2. Сохраняем.
8) Смотрим проводки
-2шт
скл1 -> скл2
гтд1 -> гтд1
-3 шт
скл1 -> скл2
гтд2 -> гтд2
-1шт
скл1 -> скл2
9) уменьшаем количество по строке до 5 шт
сохраняем, смотрим
-2шт
скл1 -> скл2
гтд1 -> гтд1
-2шт
скл1 -> скл2
гтд1 -> гтд1
-1шт
скл1 -> скл2
гтд1 -> ?(пусто)

Ну т.е. вот так см картинку

[ZVV]

Цитата:

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

1) .........
.........
-2шт
скл1 -> скл2
гтд2 -> гтд2
-1шт
скл1 -> скл2
гтд2 -> ?(пусто)

Ну т.е. вот так см картинку

Прикольная картинка получилась, обязательно как-нить попробую повторить на досуге, но:
- откуда взялся странный вывод о том, что причина в блокировках? я бы сказал, что проблема в некорректной работе механизма авторезервирования, если всё так действительно происходит. Надо банально его протрейсить и найти баг....
- вы выше говорили что у вас "остатки расходяться с проводками", а здесь просто "испортилась" приходная проводка (InventTrans), при этом остатки у вас разве "разошлись" (InventSum)?

[miklenew]

Цитата:

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

- откуда взялся странный вывод о том, что причина в блокировках?

Да нет. Одно с другим не связано.
Там я вывернулся. Придумал выход.
Просто Vadim написал, что

Цитата:

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

И являться причиной неверных остатков в нормально спроектированной системе (а стандартную логику AX в области управления запасами я считатаю нормально спроектированной ) не могут

Я ответил, что могут.
Не стоит доверять системе на 100%. Всякое бывает.
A logger попросил пример.
Это пример с блокировками никак не связан.
Просто тема немного ушла.

[Logger]

Цитата:

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

включаем на AOS-е опцию internal=comments (в 3.0 работает, как в других версиях - не знаю). Теперь запрос сохранится со значениями литералов (в комментариях)

Спасибо за ценную инфу. Очень не хватало такой информации. Правда при использовании обнаружил один баг. - Иногда такое логирование неверно отображает значение параметра.

Как обнаружил - накладывал фильтр по таблице по полю modifiedDate
фильтр такой

...Addrange(...).value(date2strXpp(systemDateGet()));

отладочная инфа показала что на оракл уходит запрос
AND (MODIFIEDDATE=:IN2/*1900/1/1*/)
а datasource(1).tostring() выдал строку
SELECT * FROM VendTable WHERE (((modifiedDate = TO_DATE('2009-02-27 00:00:00','YYYY-MM-DD HH24:MI:SS'))))

Реально же вернулась нужная строка. Так что получается что для определенных значений параметров логирование SQL-запросов может показать неверную информацию.

[ZVV]

Цитата:

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

Спасибо за ценную инфу. Очень не хватало такой информации.

ошибка update_recordset

Обратите внимание, что лучше таки использовать совместно с NOCURSORREUSE, т.к. иначе рискуете отловить не все запросы:

Цитата:

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

∙ -Internal=Comments
∙ This option will insert value of bind variables as comment into the
generated SQL statement; Therefore, this option will cause insertion of
an odd number of the character ‘ in a STR field to fail.

∙ -Internal=NoCursorReuse
∙ This option will force Axapta not to reuse internal database cursors;
therefore, if you want to examine the value of bind variable for all
traced SQL statements you must use this option in connection with the
‘–internal = Comments’.

Цитата:

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

Правда при использовании обнаружил один баг. - Иногда такое логирование неверно отображает значение параметра.
...

Странно, не сталкивался... Возможно причина в системных полях (MODIFIEDDATE)? Можете вложить примерчик?

[Logger]

Цитата:

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

Да у меня остатки расходяться с проводками.

Блокировки не могут быть причиной такого расхождения. Ищите в другом месте.

Исключение - работа системы множественных складских транзакций. Но опять же там причина такого расхождения не в блокировках, а в прерывании работы системы, когда откатывается транзакция обновляющая inventTrans, но не откатывается транзакция обновлявшая inventsum. По Inventsumlogtts можно найти такие проблемы - если там есть записи с committed == 0
Но по идее Аксапта сама раз в 600 секунд делает эту проверку и таким образом восстанавливает соответствие InventTrans и InventSum

[Wamr]

Цитата:

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

Да у меня остатки расходятся с проводками.
Написал джобик он недолго работает 10 минут.
Раз в неделю запускаю 6-8 позиций исправляет.
Но надо решать эту проблему.
Есть подозрения что это из-за блокировок.

По первому предложению создается стойкое ощущение, что у вас InventSum != сумме InventTrans по полям ItemId & InventDimId.

Такое расхождение может возникнуть только при использовании doUpdate на InventTrans. Так как в update, insert, delete происходит обновление InventSum, то есть они всегда обновляются в паре.

Или я что-то опять не так понял?

[miklenew]

Цитата:

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

По первому предложению создается стойкое ощущение, что у вас InventSum != сумме InventTrans по полям ItemId & InventDimId.

Всё правильно.

Цитата:

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

Такое расхождение может возникнуть только при использовании doUpdate на InventTrans.

Я конечно поищу. Но всё же уже больше года работаю с этой прилагой и ламерских косяков в ней пока не встречал. Ошибки есть, я их исправляю, но не до такой же степени. В целом нормально, жить можно. Когда-то хорошую школу прошёл у человека, который учился у тебя. Сначала он у тебя, потом я у него.
Здесь степень модификаций (по формуле mazzy) даже чуть по меньше, чем у нас было на общем месте работы. Так что не привыкать.
Отвлёкся.

Цитата:

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

Так как в update, insert, delete происходит обновление InventSum, то есть они всегда обновляются в паре.
Или я что-то опять не так понял?

Всё правильно. Но классы то InventUpdate и InventMovement модифицированы, есть даже сильные утверждения, которые архитиктуры связей меняют. Сильно измененена связь InventTrans -> InventTransPosting.
Резервирование сильно переделано.
Блокировки я уже откинул.
Вчера сделал пересчёт InventSum. Сегодня появилось две позиции.
Причём по этим номенклатурам блокировок не было.
Буду дальше искать.
Эта проблема замечена была несколько месяцев назад.
Пересчёт InventSum-а раз в неделю помогал.
Просто текучки хватало. Щас посвободнее стало вот и решил пора искать.
Найду.

[raz]

Цитата:

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

Вчера сделал пересчёт InventSum. Сегодня появилось две позиции.

Если проблема так быстро проявляется, то рискну предложить вариант поиска.
Используем этот проект, включаем лог базы данных по всем операциям на InventTrans, через день отключаем лог, находим ошибочные позиции, смотрим по логу как это призошло.

[miklenew]

Цитата:

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

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

Спасибо. Классная штука.

[miklenew]

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

              if (!inventTrans.Qty)
                  inventTrans.delete();
              else
                  inventTrans.update();

На первый взгляд безобидный.
Только при qty = 0 inventTrans удалялся, а InventSum не пересчитывался. Понятно почему, количество то ноль.
Сделал так

              if (!inventTrans.Qty)
              {
                  inventTrans.update();
                  inventTrans.delete();
              }
              else
                  inventTrans.update();

Ошибка исчезла.

[Logger]

Цитата:

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

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

              if (!inventTrans.Qty)
                  inventTrans.delete();
              else
                  inventTrans.update();

На первый взгляд безобидный.
Только при qty = 0 inventTrans удалялся, а InventSum не пересчитывался. Понятно почему, количество то ноль.
Сделал так

              if (!inventTrans.Qty)
              {
                  inventTrans.update();
                  inventTrans.delete();
              }
              else
                  inventTrans.update();

Ошибка исчезла.

Ого !

Получается что в InventTrans.delete() есть ошибка.

Вместо вызова

        if (InventSum::mustInventTransBeUpdated(this))
        {
            inventSum = appl.inventUpdateTTSControl().inventSumSelectLocked(this);
            inventSum.updateInventTrans(this,NoYes::No);
        }

правильнее поставить

        if (InventSum::mustInventTransBeUpdated(this.orig()))
        {
            inventSum = appl.inventUpdateTTSControl().inventSumSelectLocked(this.orig());
            inventSum.updateInventTrans(this.orig(),NoYes::No);
        }

Потому что иначе легко развалить связку InventSum и InventTrans - что собственно и произошло в вашем примере. Сперва отредактировали количество в проводке, поняли что оно 0 и update() ни к чему - вызвали delete() и получили ошибку, там где не ожидали.

Delete() должен работать на основе значений которые лежат в базе, а не в текущем буфере.

В принципе нечто подобное сделано в методе inventTrans.update() - сперва из InventSum вычитаются значения this.orig() а затем прибавляются значения this. Нужно было код перенести убрав прибавку this но оставив вычитание this.orig() Т.е. автор InventTrans.delete() неявно заложился на то что удаляемый InventTrans перед удалением не редактировался.

[miklenew]

Спасибо ещё раз raz за проект.
Модераторам:
Почему тема с проектом raz-a не в Базе знаний?
Перенесите пожалуйста.