delete_from performance

[Oleksandr]

Всем привет.

Занимаюсь оптимизацией импорта большого колиства записей из внешней системы в АХ4.0.

Перед импортом нужно очистить таблицу.

    ForecastSales           sales;
    ;
    ttsbegin;
    sales.skipDeleteActions(true);
    sales.skipDeleteMethod(true);
    delete_from sales;
    ttscommit;

Что интресно - на 10000 записей удаление занимает около минуты, а на 100 000 - час. Реальный сценарий - до миллиона...

В чем причина такой нелинейости?

Спасибо.
П.С. direct SQL спасает, конечно.

[DSPIC]

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

Edit: Чтобы затухание не возникало, удаляйте записи по-одной в рамках транзакции ttsbegin\ttscommit.

[miklenew]

Цитата:

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

Перед импортом нужно очистить таблицу.

Иногда можно применить и Truncate.

new SqlDataDictionary().tableTruncate(tableNum(ForecastSales ));

Удаляет моментально. Правда из всех компаний.
В некоторых случаех это не важно.
Может это ваш случай.

[blokva]

Цитата:

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

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

Edit: Чтобы затухание не возникало, удаляйте записи по-одной в рамках транзакции ttsbegin\ttscommit.

...или придумвйте критерий и удаляйте по частям, например по 10 000 записей.

[Didukh84]

Добрый день!

Цитата:

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

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

Согласен. В принципе логично.

Цитата:

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

Edit: Чтобы затухание не возникало, удаляйте записи по-одной в рамках транзакции ttsbegin\ttscommit.

Здесь мне кажеться лучше организовать цикл по удалению (но без ttsbegin\ttscommit!), a через delete_from. Что-то типа

int i = -1* maxuint();
while(i < maxuint())
{
   delete_from Table where Table.RecId<i;
    i = i + 10000;
}

По идее результат тот же, а выполнится быстрее.

[glibs]

Цитата:

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

...
В чем причина такой нелинейости?
...

Еще вариант — начинает банально не хватать памяти на сервере БД, что уменьшает долю закешированных данных от общего объема обрабатываемых, и приводит к росту ввода-вывода.

Там индексов 9 штук. От удаления по одной записи тоже чуда ожидать не стоит, мягко говоря.

[_scorp_]

Только что проверил на таблице с 370 000 записей. delete_from - 367 секунд. while select forupdate - 472 секунды.

[DSPIC]

Цитата:

Edit: Чтобы затухание не возникало, удаляйте записи по-одной в рамках транзакции ttsbegin\ttscommit.

Цитата:

...или придумвйте критерий и удаляйте по частям, например по 10 000 записей.

Ну, примерно это я и имел ввиду. ;-) Понятно, что если миллион записей то по-одной удалять слишком дорого.
а:

new SqlDataDictionary().tableTruncate(tableNum(ForecastSales ));

вам не подходит? По-моему, выглядит привлекательней, причём для импорта из других систем использование вполне обосновано, если компании не используются.

[Recoilme]

Всем ПРВТ!
Я только на секундочку.., хочу bbcode посмотреть как реализовывать) А где ещё тестить ббкоде как на не любомом некогда форуме?
Чтобы зазря буквы не тратить..

    skipTTScheck(1); //отключит транзакции и удалит пулей (ttsbegin/commit - надо будет стереть)
    skipDataBaseLog(1); //отключит лог

и вот ещё

    tableTruncate// удаляет ссылку на данные(мгновенно), восстановить нельзя будет даже через бэкап

вроде работает)

[DSPIC]

Цитата:

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

Вопрос был больше о причине нелинейности. Если > миллиона записей, то удаление сразу всех записей вообще может не произойти, вывалясь например на ошибку о нехватке памяти, что не произойдет в случае удаления по-одной(или серии) записей.

Цитата:

олько что проверил на таблице с 370 000 записей. delete_from - 367 секунд. while select forupdate - 472 секунды.

Нужно больше рекорд чтобы увидеть эффект затухания

[Recoilme]

2 Mazy (или кто сейчас у руля?)
тег code - не закрыт у тебя, из-за этого используется не моноширинный шрифт и исходники X++ - разъезжаются.

[Oleksandr]

Цитата:

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

Только что проверил на таблице с 370 000 записей. delete_from - 367 секунд. while select forupdate - 472 секунды.

Ошибочка в код закралась - забыл-таки поставить параметр (true) в skipdeletActions(), skipdeleteMethos().

Теперь все чики-пики, несколько секунд.

Хотя вопрос все-равно интересный - о нелинейности, даже с исполнением триггеров и делит - экшинов.

Спасибо за ответы.

[Oleksandr]

Цитата:

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

Ну, примерно это я и имел ввиду. ;-) Понятно, что если миллион записей то по-одной удалять слишком дорого.
а:

new SqlDataDictionary().tableTruncate(tableNum(ForecastSales ));

вам не подходит? По-моему, выглядит привлекательней, причём для импорта из других систем использование вполне обосновано, если компании не используются.

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