тупость при удалении из InventJournalTrans

[SHiSHok]

удаляли сегодня инвентаризационный журнал,я громко матюкался когда обнаружил этот тупняк (88000 строк журнала удалялось 4 часа).
итак таблица: InventJournalTrans

void delete()
{
    ;
    ttsbegin;
    appl.inventUpdateTTSControl().setTTSBeginLock();

    super();

    if (this.journalType == InventJournalType::Count)
        InventItemLocation::updateStopCountingJournal(this);

    InventUpd_DeleteMovement::newMovement(InventMovement::construct(this)).updateNow();

    if (this.voucher)
    {
        if (this.numOfVoucherLines() == 0) // нас интересует эта строка !!!
            JournalError::deleteVoucher(tableNum(InventJournalTable),this.journalId,this.voucher);
    }

    appl.inventUpdateTTSControl().setTTSCommitLock();
    ttscommit;

}

смотрим метод numOfVoucherLines()

Integer numOfVoucherLines()
{
    return (select forceplaceholders count(recId) from inventJournalTrans
                index hint VoucherIdx
                where inventJournalTrans.journalId == this.journalId &&
                      inventJournalTrans.voucher   == this.voucher).recId;
}

т.е. для того чтобы узнать есть такие строки или нет мы считаем их количество! и так для каждой строки журнала - я офигел . сделал так:

// SHiSHok 20070331
boolean voucherLineExist()
{
    return (select firstfast firstonly forceplaceholders recId from inventJournalTrans
            index hint VoucherIdx
            where inventJournalTrans.journalId == this.journalId &&
                  inventJournalTrans.voucher   == this.voucher).recId != 0;
}

void delete()
{
    ;
    ttsbegin;
    appl.inventUpdateTTSControl().setTTSBeginLock();

    super();

    if (this.journalType == InventJournalType::Count)
        InventItemLocation::updateStopCountingJournal(this);

    InventUpd_DeleteMovement::newMovement(InventMovement::construct(this)).updateNow();

    if (this.voucher)
    {
//        if (this.numOfVoucherLines() == 0)  //
        if (!this.voucherLineExist())
            JournalError::deleteVoucher(tableNum(InventJournalTable),this.journalId,this.voucher);
    }

    appl.inventUpdateTTSControl().setTTSCommitLock();
    ttscommit;

}

при удалении подобного журнала на тестовой выдало оценочное время 35мин (грубо говоря в 6 раз прирост производительности)

[wojzeh]

ну, собственно, в 4-й версии таким широким жестом проверяется наличие строк для удаления (метод Delete()) в следующих таблицах:

InventJournalTrans
ProdJournalBOM
ProdJournalProd
ProdJournalRoute
ProjJournalTrans
TutorialJournalTrans (sic! чему нас учат!)

более нигде этот волшебный метод numOfVoucherLines не вызывается.

[SRF]

Хоть и было, это давно, но все же спрошу, а действительно ли прирост был в 6 раз, ну или хотя бы в 2 или 3 раза ?

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

Да, на тестовой выдало время 35 мин, а дальше, что ? Думаю, если подождать эти 35 минут, то Progress Bar будет показывать уже совсем другое время (проверял, будет показывать другие числа, на DAX 4.0 (виртуальная машина от MS) ).

На мой взгляд, проблема того, что строки удаляются долго, в том, что все они удаляются в одной транзакции.

Безусловно, при проверке на существование одной записи прирост производительности операции удаления будет, но не в разы.

[fed]

Стоит помнить, что для складских журналов можно настроить режим, при котором один ваучер выделяется не на строку, а на все строки с одинаковой датой . Для этого случая - гипотеза о сопоставимости времени выполнения count() и загрузки одной строки не срабатывает...
Да и в режиме Номенклатура+дата, выделение нового ваучера происходит только если в очередной строке номенклатура отличается от номенклатуры в предыдущей строке. Если у тебя, скажем, списывается много одинаковой номенклатуры с разными серийными номерами - гипотеза тоже не срабатывает.

[wojzeh]

да, мне тоже показался прирост совсем незначительным. на 2500 записях я никакого прироста не ощутил. но методы поправил.

кстати, вопрос методологический: а зачем вообще удалять строки из инв. журнала?

[AraraT®]

Цитата:

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

да, мне тоже показался прирост совсем незначительным. на 2500 записях я никакого прироста не ощутил. но методы поправил.

кстати, вопрос методологический: а зачем вообще удалять строки из инв. журнала?

А смысл разносить фактическое нувое количество если по системе также 0?

[wojzeh]

а поразвёртнутей можно? я не компетентен в вопросе настолько, чтоб из вопроса на вопрос составить себе ответ.

[Zabr]

Цитата:

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

На мой взгляд, проблема того, что строки удаляются долго, в том, что все они удаляются в одной транзакции.

Как раз наоборот. Много мелких транзакций в цикле выполняются заметно дольше, чем одна общая транзакция на весь цикл. Время тратится на отдельное открытие-закрытие каждой мелкой транзакции.

[sukhanchik]

Цитата:

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

Как раз наоборот. Много мелких транзакций в цикле выполняются заметно дольше, чем одна общая транзакция на весь цикл.

... но при этом на больших объемах данных и при многопользовательской работе это ставит БД колом на время выполнения транзакции. Хотя формально получается быстрее (аналогично тому, что цикл с прогресс-баром крутится медленнее, чем без него, но при этом психологически кажется что быстрее)

[kashperuk]

Цитата:

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

Как раз наоборот. Много мелких транзакций в цикле выполняются заметно дольше, чем одна общая транзакция на весь цикл. Время тратится на отдельное открытие-закрытие каждой мелкой транзакции.

Так ведь куча логов пишется, и чем дольше транзакция открыта, тем больше их пишется, и тем больше памяти используется для этого (чтобы можно было успешно откатить транзакцию в случае сбоя).
Также могут начать возникать блокировки чтения (правда зависит от версии системы и уровня изоляции при чтении - READ_COMMITTED_SNAPSHOT в SQL 2005 говорят проблему эту решает)
И если транзакция будет длится, скажем, 4 часа, но через 3:59 выключат свет в серверной , то после перезагрузки 4 часа БД будет недоступна, пытаясь откатить все эти изменения. То же будет в случае отката по ошибки в процессе обработки (я думаю, что именно по этой причине там сделали создание журнала с ошибками вместо отката всех строк, как в заказах на покупку/продажу).

Поэтому время на открытия/закрытия мелких транзакций выгоднее с точки зрения скорости. Но целостность данных дороже.