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

[ZVV]

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

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

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

[Logger]

Цитата:

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

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

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

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

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

[Андре]

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

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

[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.
Долго подбирал данные, но смог подобрать.

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

[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, через день отключаем лог, находим ошибочные позиции, смотрим по логу как это призошло.