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

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

Ну я так и думал. Ваше исходное сообщение можно было понять словно из-за блокировок развалились InventSum и InventTrans. Как видно из примера ничего похожего и близко нет.

[miklenew]

Процитирую сам себя

Цитата:

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

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)? Можете вложить примерчик?