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

[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
Где-то на форуме было как это через перекрестные ссылки найти.

[Logger]

Цитата:

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

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

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

[miklenew]

Цитата:

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

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

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

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

[Logger]

Джобец

// GRD_fixQueryValue_pkoz    // pkoz 27.02.2009
static void Job463(Args _args)
{
    int         dd;
//    str         data;// = 27\02\2009;
    date        data = dateNull();
//    date        data = 27\02\2009;
    vendTable   vendTable;
    Query       Query;
    QueryRun    qr;

    str getRange()
    {
        ;
        //return date2strXpp(data);
        return
            strFMT( '((%1==%2))',
                        fieldStr(vendTable, modifiedDate),

                        //QueryValue(data) // с таким параметром кривая дата будет пр использовании расширенных запросов
                        date2strXpp(data) // а при таком все нормально
                        )
        ;
    }
    void qu(boolean _lit, boolean _ext, str _s)
    {
        boolean     good;
        ;
        //info("");
        Query = New Query();
        if (_lit)
            Query.literals(1);

        if (_ext)
            Query.addDataSource(tableNum(vendTable)).addRange(fieldNum(vendTable,
                //modifiedDate
                recId
                )).value(
                getRange()
                );
        else
            Query.addDataSource(tableNum(vendTable)).addRange(fieldNum(vendTable, modifiedDate)).value(QueryValue(data));

        info(Query.dataSourceNo(1).toString());
        qr = New QueryRun(Query);
        good = qr.next();
        info(strFMT("%3 Литералы %1, Расш запрос %2,  recId = %4", _lit, _ext, good ? "Есть результат" : "Нет результата", good ? qr.getNo(1).RecId : 0));
        info("");

        //info("");

    }
    ;
    setPrefix("Оператор SQL");
    info(getRange());

    //GRD_SqlTraceOn();
    //info("");

    qu(0, 0);
    qu(0, 1);
    qu(1, 0);
    qu(1, 1);
    //info("");
    //GRD_SqlTraceOff();

}

Как вы и предполагали, проблема связана с использованием -Internal=NoCursorReuse
Без использования этого ключа логирование может выдавать неверную информацию. modifiedDate - ни при чем

При изменении даты фильтрации

date        data = dateNull();

- логирование показывает значение которое использовалось в первый раз. Запрос на БД в любом случае правильный уходит.