Как ускорить удаление помеченных объектов в 1С

Удаление помеченных объектов — одна из самых ресурсоёмких штатных операций в 1С. На большой базе обработка «Удаление помеченных объектов» может идти часами, блокировать работу пользователей и заканчиваться ошибкой нехватки памяти или таймаута транзакции. Причина почти всегда не в самом удалении, а в проверке ссылочной целостности: платформа просматривает все объекты конфигурации, ищет ссылки на каждый удаляемый элемент, и чем больше база, тем дольше этот проход.

Ускорить процесс можно на нескольких уровнях: правильно подготовить сеанс (монопольный режим, выбор времени), сократить объём работы (порционное удаление, предварительная чистка ссылок), оптимизировать СУБД (индексы, статистика, журнал транзакций) и выстроить регламент, чтобы не накапливать миллионы помеченных объектов. Ниже — конкретные приёмы для файловых и клиент-серверных баз.

Все действия, связанные с массовым удалением, выполняйте только после создания резервной копии. Удаление необратимо: если по ошибке будет удалён нужный объект, восстановить его можно только из архива.

Почему удаление работает медленно

Стандартная обработка «Удаление помеченных объектов» (Администрирование → Обслуживание → Удаление помеченных объектов) работает в два этапа. Сначала она собирает список всех помеченных объектов, затем для каждого ищет ссылки на него во всех таблицах конфигурации — в реквизитах справочников, документов, регистрах сведений, табличных частях. Если ссылка найдена, объект нельзя удалить, пока ссылка не будет очищена.

Именно поиск ссылок занимает основное время. В конфигурации уровня ERP или «Комплексная автоматизация» сотни типов объектов и тысячи реквизитов ссылочных типов. Платформа фактически выполняет серию запросов ко всем этим таблицам, и на базе в сотни гигабайт без подходящих индексов каждый такой запрос превращается в полное сканирование таблицы.

Второй фактор — конкуренция с пользователями. Если во время удаления в базе работают люди, транзакции удаления конкурируют за блокировки, возникают взаимоблокировки, и обработка либо зависает, либо падает с ошибкой конфликта блокировок. Третий фактор — объём журнала транзакций на СУБД: массовое удаление генерирует огромное количество записей в лог, и при неправильной модели восстановления диск с логом может переполниться.

Подготовка: монопольный режим и резервная копия

Первое и самое простое ускорение — выполнять удаление в монопольном режиме. Завершите работу пользователей (в консоли кластера или через «Блокировку работы пользователей» в типовых конфигурациях на базе БСП), остановите регламентные и фоновые задания. Без конкурирующих транзакций удаление идёт заметно быстрее и не рискует упасть на конфликте блокировок.

Перед запуском сделайте резервную копию: выгрузку в dt для файловой базы или средствами СУБД для клиент-серверной. Проверьте, что копия создалась и её размер адекватен. Это не формальность: при массовом удалении ошибка в отборе объектов (например, пометили лишнее обработкой) обнаруживается уже после удаления.

Также заранее освободите место на дисках СУБД. Массовое удаление временно увеличивает журнал транзакций, а в файловом варианте платформа может создавать временные файлы. Нехватка места в середине операции — один из самых неприятных сценариев.

Порционное удаление вместо «всё сразу»

Главный приём ускорения — не пытаться удалить всё за один проход. В типовых конфигурациях обработка позволяет выбрать режим «Выборочное удаление объектов»: отметьте только один вид объектов, например помеченные документы определённого типа или один справочник. Объём проверок ссылок сокращается пропорционально, и каждая порция завершается за приемлемое время.

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

Если помеченных объектов очень много, разбейте работу на несколько ночей: сегодня — документы одного вида, завтра — другого. Это предсказуемее, чем один многодневный марафон, и каждая завершённая порция уже освобождает место.

1. 1
   Создайте резервную копию базы и проверьте её наличие
2. 2
   Завершите сеансы пользователей и отключите регламентные задания
3. 3
   Обновите статистику и перестройте индексы на СУБД (для клиент-серверного варианта)
4. 4
   Запустите «Удаление помеченных объектов» в режиме выборочного удаления — по одному виду объектов
5. 5
   Дождитесь завершения порции, проверьте журнал регистрации на ошибки
6. 6
   Повторите для следующих видов объектов, затем сожмите лог транзакций и проверьте свободное место

Оптимизация на стороне СУБД

В клиент-серверном варианте (MS SQL Server, PostgreSQL) значительная часть времени удаления уходит на запросы поиска ссылок, и их скорость напрямую зависит от состояния индексов и статистики. Перед большим удалением выполните обновление статистики и реорганизацию индексов по основным таблицам — это штатные операции обслуживания, которые часто дают ускорение в разы.

Проверьте модель восстановления базы. Если база в модели Full, а лог никто не обслуживает, массовое удаление раздует журнал транзакций до десятков гигабайт. На время регламентного удаления допустимо переключить базу в простую (Simple) модель восстановления — с обязательным возвратом и полным бэкапом после, если того требует ваша политика резервного копирования. Это решение должен принимать администратор СУБД.

Для файловых баз инструментов оптимизации меньше: помогает размещение базы на быстром диске (SSD), достаточный объём оперативной памяти и отсутствие антивирусного сканирования каталога с базой в реальном времени. Проверьте, что файл базы не фрагментирован и на диске есть запас свободного места.

Если удаление десятков тысяч объектов занимает у вас больше нескольких часов даже в монопольном режиме, это почти всегда признак проблем на уровне СУБД: устаревшая статистика, разросшиеся индексы, медленный диск под логом. Начните с обслуживания СУБД, а не с поиска «волшебной» обработки.

Предварительная очистка ссылок

Обработка удаления тратит много времени на объекты, которые в итоге не удаляются, потому что на них есть ссылки. Если заранее очистить эти ссылки, проход удаления сокращается. Типовой сценарий: перед удалением старых контрагентов или номенклатуры выполните замену ссылок на актуальные значения с помощью обработки «Поиск и замена значений» (в типовых конфигурациях она доступна в разделе администрирования).

Также полезно заранее разобраться с объектами, которые система показывает как «не удалённые» после прошлых попыток. Откройте список мест использования помеченного объекта (в обработке удаления есть соответствующая команда), очистите или замените ссылки, и при следующем запуске объект удалится быстро, без повторного полного сканирования.

Для массовых операций существуют специализированные обработки свёртки и чистки базы, но любые нештатные инструменты, удаляющие данные напрямую, используйте только после тестирования на копии: прямое удаление записей из таблиц СУБД в обход платформы разрушает целостность данных и лишает поддержки.

Регламент: как не допустить замедления в будущем

Лучший способ ускорить удаление — делать его регулярно и понемногу. В типовых конфигурациях на базе Библиотеки стандартных подсистем есть регламентное задание «Удаление помеченных объектов», которое можно настроить на ночное время. Еженедельный автоматический запуск удаляет свежие пометки небольшими порциями, и ситуация «миллион помеченных объектов за три года» не возникает.

Дополнительно настройте регламентные задания обслуживания СУБД: обновление статистики и реорганизацию индексов. Это ускоряет не только удаление, но и всю работу базы. Для больших баз рассмотрите свёртку старых периодов — перенос остатков на дату и удаление документов прошлых лет, что радикально уменьшает объём данных.

Наконец, дисциплинируйте пользователей: пометка на удаление должна означать «это будет удалено при ближайшем регламенте», а не «пусть лежит». Чем меньше накопленных помеченных объектов и «битых» ссылок, тем быстрее и безопаснее проходит каждая чистка.

Контрольные точки

Как проверить результат

Список помеченных объектов после прохода

Норма

Помеченных объектов не осталось или остались только связанные, с понятным списком мест использования

Тревожный признак

Те же объекты остаются помеченными без объяснения причин

Журнал регистрации

Норма

Нет ошибок удаления и конфликтов блокировок

Тревожный признак

Ошибки СУБД, таймауты, обрывы транзакций

Свободное место на дисках

Норма

Лог транзакций сжат после операции, место в норме

Тревожный признак

Лог раздут и занимает большую часть диска

Работа пользователей после удаления

Норма

База работает без ошибок, отчёты открываются

Тревожный признак

Появились «битые» ссылки вида «Объект не найден»

Частые вопросы

Можно ли удалять помеченные объекты, пока пользователи работают?

Технически — да, обработка это позволяет. Практически — нежелательно: возрастает риск конфликтов блокировок, удаление идёт медленнее, а пользователи могут в этот момент создать новые ссылки на удаляемые объекты. Для больших объёмов планируйте операцию на нерабочее время.

Почему некоторые объекты не удаляются, хотя помечены?

На них есть ссылки из других объектов: документов, справочников, регистров. В обработке удаления выберите объект и откройте список мест использования — там видно, кто ссылается. Очистите или замените эти ссылки, затем повторите удаление.

Безопасно ли удалять объекты напрямую SQL-запросом?

Нет. Прямое удаление записей из таблиц в обход платформы нарушает ссылочную целостность, приводит к «битым» ссылкам и ошибкам в работе, а также противоречит условиям поддержки. Используйте только штатные механизмы платформы или проверенные обработки на копии базы.

Как часто нужно запускать удаление помеченных объектов?

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

Обработка зависла и не отвечает. Что делать?

Не перезапускайте её сразу. Проверьте в консоли кластера или в мониторе СУБД, идёт ли реальная работа (активные запросы, рост лога). Если процесс действительно завис — завершите сеанс, убедитесь, что транзакция откатилась, и повторите удаление меньшей порцией после обслуживания индексов и статистики.

Ускорит ли удаление переход с файловой базы на клиент-серверную?

Как правило, да: на больших объёмах СУБД с нормальными индексами и параллелизмом выполняет проверку ссылок значительно быстрее файлового движка. Но переход ради одной операции не оправдан — это решение принимается по совокупности нагрузки на базу.