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

[miklenew]

Переодически возникают блокировки по InventSum и по InventTrans.
Можно ли средствами Axapt-ы где нибудь посмотреть эти блокировки?
Нужна информация были ли блокировки за последний месяц по заданной номенклатуре.
Если так нельзя.
То как это можно настроить или запрогроммировать чтоб за следующий месяц была такая информация.
Заранее спасибо.

[ivas]

\Classes\JournalCheckPost\runDeadLock

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

на правах пердположения) сам не пробовал...

[Logger]

Администрирование - Запросы - База данных - Журнал трассировки операторов SQL

Туда попадают Deadlock и долгие запросы.
Deadlock - всегда идет по причине блокировок.

Долгий запрос тоже может быть следствием блокировки, поэтому можно просто наложить фильтр по этому логу и проанализировать записи.

[ZVV]

Не представляю даже как такое можно сделать в разрезе номенклатуры...

Долгие запросы и дедлоки - это хорошо, конечно, но никакой информации по исходному вопросу не дают.

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

[Logger]

Цитата:

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

Не представляю даже как такое можно сделать в разрезе номенклатуры...

Долгие запросы и дедлоки - это хорошо, конечно, но никакой информации по исходному вопросу не дают.

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

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

[Андре]

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

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

[miklenew]

Цитата:

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

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

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

Цитата:

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

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

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

[Wamr]

Миша, лучше попытаться найти doUpdate по InventTrans или InventSum
Где-то на форуме было как это через перекрестные ссылки найти.

[Vadik]

Цитата:

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

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

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

Цитата:

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

Увы

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

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

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

[Logger]

Цитата:

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

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

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

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

[Logger]

Цитата:

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

Миша, лучше попытаться найти doUpdate по InventTrans или InventSum
Где-то на форуме было как это через перекрестные ссылки найти.

Как отловить отладчиком DoUpdate, DoDelete?

[miklenew]

Цитата:

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

Миша, лучше попытаться найти doUpdate по InventTrans или InventSum
Где-то на форуме было как это через перекрестные ссылки найти.

И что мне это даст?
Нужен трэйс. А для трэйса сначала надо локолизовать проблему.
Это редко происходит.

[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 попросил пример.
Это пример с блокировками никак не связан.
Просто тема немного ушла.

[raz]

ГТД не является правильной складской аналитикой. Не стоит её считать таковой и использовать. Если вы сравните в коде ГТД с любой другой аналитикой, вы все поймете.

[miklenew]

Цитата:

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

ГТД не является правильной складской аналитикой. Не стоит её считать таковой и использовать. Если вы сравните в коде ГТД с любой другой аналитикой, вы все поймете.

Вечером попробую с другой аналитикой.
Но насколько я понял, что в кишках происходит, ГТД тут не причём, этот эффект должен и на других аналитиках повториться.
Просто он мне подруку подвернулся.
Да и забыл написать как исправил:
InventUpd_Estimated\updateDepreciateReceipt()
Место

    while select forupdate inventTrans
        index hint TransIdIdx
        order by statusReceipt desc,inventRefTransId,inventDimId desc
        where inventTrans.inventTransId         == movement.transId()               &&
              inventTrans.transChildType        == movement.transChildType()        &&
              inventTrans.transChildRefId       == movement.transChildRefId()       &&
              inventTrans.statusIssue           == StatusIssue::None                &&
              inventTrans.statusReceipt         >= StatusReceipt::Ordered           &&
              inventTrans.statusReceipt         <= StatusReceipt::QuotationReceipt

поставил

    while select forupdate inventTrans
        index hint TransIdIdx
        order by statusReceipt desc,inventRefTransId,inventDimId
        //order by statusReceipt desc,inventRefTransId,inventDimId desc
        where inventTrans.inventTransId         == movement.transId()               &&
              inventTrans.transChildType        == movement.transChildType()        &&
              inventTrans.transChildRefId       == movement.transChildRefId()       &&
              inventTrans.statusIssue           == StatusIssue::None                &&
              inventTrans.statusReceipt         >= StatusReceipt::Ordered           &&
              inventTrans.statusReceipt         <= StatusReceipt::QuotationReceipt

Не знаю у всех так или нет, но в силу наших бизнес процессов.
InventDimId без ГТД появляются раньше. Следовательно между ними такая связь.
InventDimId(без ГТД) < InventDimId(с ГТД)
Этим и воспользовался. Просто сортировку поменял.

[raz]

Насчет ГТД... давно это было, ну и уже не помню что там с ней не так, но как минимум нужно в группу полей InventDimensions на InventDim добавить ГТД. Помоему еще что то в коде криво сделано. Может уже исправлено. Мы же стараемся не использовать ГТД как складскую аналитику.

На всякий случай... у нас AX3 SP4.