Массовое удаление записей через CCADOConnection

[sukhanchik]

Цитата:

Сообщение от Shirmin Oleg

От безысходности параметр выставлял аж в значение 1000000, визуально вообще ничего не изменилось (падало за то же время, что и без него)
...
Отказаться, к сожалению, невозможно, надо удалять.
...
Удаляемая часть данных - малая толика от всей таблицы, боюсь в данном случае времени на перекачку данных в новую таблицу уйдет еще больше, чем при удалении через delete_from

Тогда могу лишь порекомендовать либо последовать совету lev, либо ... последовать его совету, но попытаться бить на отдельные транзакции удаляемые записи.
Т.е. написать что-то типа этого:

Counter i;
;
ttsbegin;
while select forupdate mytable
{
      mytable.dodelete();
      i++;
      if (i > 10000) // Число подобрать надо
      {
            break;
      }
}
ttscommit;

И вызывать этот метод несколько раз. Общее время может увеличиться, но зато не будет "зависаний" надолго, как и уменьшится вероятность блокировок. Плюс еще прогресс-бар можно вставить.

[S.Kuskov]

Цитата:

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

попытаться бить на отдельные транзакции

И даже тогда можно не отказываться от преимуществ конструкции delete_from. 'Порционного' удаления можно добиться при помощи фильтрации.

SALESTABLE_TONTRA40478 Table;
date month = 01\03\2010;
RecId minRecId, maxRecId, fromRecId, toRecId;
int partSize = 10000 // Число подобрать надо;

select minof(RecId) from Table where Table.month == month;
fromRecId = Table.RecId;

select maxof(RecId) from Table where Table.month == month;
toRecId = Table.RecId;

for(fromRecId = minRecId; fromRecId <= maxRecId;  fromRecId += partSize)
{
    toRecId = fromRecId + partSize;
    
    Table.skipDatabaseLog(true);
    Table.skipDeleteActions(true);
    Table.skipDeleteMethod(true)
    delete_from Table 
    where 
        Table.month == month &&        
        Table.RecId >= fromRecId &&
        Table.RecId <= toRecId;
}

[mazzy]

Сложно то как

Цитата:

Сообщение от S.Kuskov

'Порционного' удаления можно добиться при помощи фильтрации.

Да. Но брать порциями по PartSize - бесполезно. В интервале может быть и 10тыс записей, и ни одной. Достаточно просто сузить диапазон.

А главное - обрамить tts-скобками

SALESTABLE_TONTRA40478 Table;
date month;

while(true)
{
    select minof(month),minof(recid) from Table;
    if( !Table.recid ) break;

    month = Table.month;

    ttsbegin;
    Table.skipDatabaseLog(true);
    Table.skipDeleteActions(true);
    Table.skipDeleteMethod(true)
    delete_from Table 
    where 
        Table.month == month;
    ttscommit;
}

[S.Kuskov]

Цитата:

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

Сложно то как

Зато универсально. Таким способом можно удалить любую другую выборку.

Цитата:

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

Да. Но брать порциями по PartSize - бесполезно. В интервале может быть и 10тыс записей, и ни одной.

Идея в том что их гарантированно не будет больше 10тыс. Те таблица если и будет заблокированна то не на долго. А если цикл прогонит пару итераций в холостую, что ж с того?

Цитата:

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

Достаточно просто сузить диапазон

На сколько я понял условие задачи. Удаляють нужно не все записи из таблицы, а только за определённый месяц. Причём даже за один месяц число записей > 600 000;

Цитата:

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

А главное - обрамить tts-скобками

Зачем? Или это шутка юмора такая?

[mazzy]

Цитата:

Сообщение от S.Kuskov

Идея в том что их гарантированно не будет больше 10тыс. Те таблица если и будет заблокированна то не на долго. А если цикл прогонит пару итераций в холостую, что ж с того?

Может быть и так...
Но может быть просто поискать другое поле? Которое и с индексом, и дает относительно небольшое число записей? Например, не месяц, а дату.

Цитата:

Сообщение от S.Kuskov

Зачем? Или это шутка юмора такая?

Нет.
Если база установлена в Recovery Model = Full, то разницы действительно не будет.
Если же база установлена в Recovery Model = Simple, то после окончания каждой транзакции transaction log будет очищаться.

вполне возможно, что у автора transaction log сильно растет, а на диске места свободного мало. Вот и мучается SQL, затрачивая каждый раз много времени на увеличение transaction log.

[S.Kuskov]

Цитата:

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

далеко не всегда существует индекс в котором бы было единственное поле - RecID

Уточню. Необходим индекс, где поле - RecID стоит на первом месте.

И да, естественно, включать индекс по RecId будет необходимо.

Цитата:

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

после окончания каждой транзакции transaction log будет очищаться

Это понятно, я просто рассчитывал, что конструкция delete_from cамостоятельно открывает и закрывает транзакцию.

[mazzy]

Цитата:

Сообщение от S.Kuskov

Это понятно, я просто рассчитывал, что конструкция delete_from cамостоятельно открывает и закрывает транзакцию.

Э-э-э... По-моему, нет. Хотя могу ошибаться.

[sukhanchik]

Цитата:

Сообщение от S.Kuskov

И даже тогда можно не отказываться от преимуществ конструкции delete_from. 'Порционного' удаления можно добиться при помощи фильтрации.

У фильтрации есть тот минус, что по фильтруемому полю нужно иметь адекватный индекс, дабы фильтрация состоялась в ожидаемое время, а не произошел бы Full Table Scan. А далеко не всегда существует индекс в котором бы было единственное поле - RecID.
Конечно брать тупо по 10 (20,30) тыс. записей - тоже не вариант - объем записей бывает разный.
В общем - надо искать "золотую" середину.

[mazzy]

Цитата:

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

У фильтрации есть тот минус, что по фильтруемому полю нужно иметь адекватный индекс, дабы фильтрация состоялась в ожидаемое время, а не произошел бы Full Table Scan.

Тоже верно!
причем в сообщении автора условие по этом полю и было. вполне возможно, что проблема с отсутствии индекса и в Full Table Scan.