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

[Logger]

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

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

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

[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]

Цитата:

Сообщение от 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-запросов может показать неверную информацию.

[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-а раз в неделю помогал.
Просто текучки хватало. Щас посвободнее стало вот и решил пора искать.
Найду.