Добрый день.
Надо удалить ~500к документов. Обычной обработкой пометить на удаление, а потом через стандартное "Удаление помеченных объектов" удалить что помечено.
Вопрос в том, что скорость пометки на удаление падает. Помечаю в транзакции по месяцу. Количество документов в одном месяце примерно одинаково, но первые 2 месяца помечаются по 2-3 минуты, а дальше скорость серьезно падает. Если через контроль удалить то, что уже помечено, то скорость вновь становится нормальной.
Как обойти данную хрень? Чтоб сразу пометить всё, а потом всё удалить без потери в скорости?

ТА перевёл на самый первый документ в базе.

а чо этой обычной обработкой сразу не выпилить?

(1) Ссылки нужно сохранить. Много документов друг на друга ссылкаются. Думаю, если их по каждому удаляемому документу искать внутри обработки, то будет еще дольше.

(2): Так сохраняй предварительно в список значений.
Потом по этому СЗ иди и ищи объекты - помечай их.

Попробуй транзакциями по 100 штук

(3) Немного не понял ход мыслей... взять объект, записать в СЗ, а потом шерстить СЗ, ища ссылки на каждый объект?
(4) Сейчас попробую.

ТА перенести перед перед удаляемым документом
По штук 100 можно помечать

(0) Скорость падает из-за "особенностей" SQL-а.
Простейший способ обойти - сделать выход из 1С после определенного количества документов, потом по шедулеру вход, с автоматическим запуском обработки. Ну и как выше написано - удалять в транзакциях, по 100-1000 документов.

Да, помнится при восстановлении посл-ей юзал реконнект натив

(6) Каждый раз переность ТА на удаляемый документ?
(7) Тоже была мысль в планировщик запихать через каждые 2 месяца помеченных.

(9) ТА перед началом обработки убрать в самое начало, а вернуть только после пометки всех документов. Естественно.
Насчет планировщика была правильная мысль. Ибо обработка мало того что замедляется, она после большого количества данных может просто упасть.

(10) ТА убрал на самое начало, да. Буду пробовать через планировщик, наверное, делать. Самый простой выход, как мне кажется.

(5): Да. Именно так.
Транзакциями по 100-1000 записей СЗ.

(0) тупо так
delete жур from _1sjourn as Жур where Жур.date_time_iddoc <=:КонДата~
далее почистить таблички шапок/тч документов по условию
iddoc not in (select iddoc from _1sjourn)

аналогично с табличками движений регистра, проводками и операциями + почистить табличку ссылок  и _1sconst
пересчитать итоги, наслаждаться.

(13) Если б умел так "тупо :)", то давно бы сделал. Пытался когда-то прямыми удалить, но не врубился как почистить движения регистров. Да вообще пока что совсем мало опыта прямыми выкашивать документы.

(13) И, кстати, если в наглую так косить, то удалится всё, что есть. А некоторые надо оставить, ссылки на которые есть в документах нынешних.

Ну, да ладно. Как прижмёт, так и до удаления прямыми дойду. А пока через планировщик буду мутить :)

(15) как бэ, условия в текстах запроса еще никто не отменял

(17) Не знаю как ссылки проверить в прямом запросе. Ну гуглил правда...

(18) через запрос к 1SCRDOC

(19) нуну. Если у меня в реквизите справочника будет ссылка на документ, никакой scrdoc об этом не узнает.

(20) В справочниках, к счастью, ссылок на документы нет. Только если в периодике.

(20) ну дык..он же вроде как доки пока удаляет :)

(22) Ссылка-то есть...

А зачем ссылки проверять? Ты же не удаляешь, а помечаешь на удаление.

А база SQL или DBF?

На файловой удалял файлы RG.dbf и RA.dbf, штатной обработкой помечал на удаление, штатно удалял и перепроводил оставшиеся. Удаление порядка 230 т. доков , проведение оставщихся, ТиИ и сжатие ИБ заняло совокупно 3,5 часа на сервере 10-летней давности. Предварительно обработкой на конец обрезаемого периода были созданы документы по вводу нужных остатков (непроведенные).