Удаление помеченных объектов тормозит: где теряется время и как ускорить

Долгое удаление помеченных объектов в 1С почти всегда упирается в одно — контроль ссылок. Программа не просто стирает строки, а перед удалением каждого объекта обходит всю базу и ищет, где на него ещё ссылаются. Отсюда и минуты, иногда часы ожидания.

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

Почему физическое удаление идёт так медленно

Пометка на удаление и само удаление — два разных действия. Когда вы ставите флажок «Пометить на удаление», в поле объекта меняется один реквизит, DeletionMark=True. Объект остаётся в базе и продолжает участвовать в отборах и отчётах, пока вы его не исключите вручную.

Физическое удаление запускается отдельно и работает в два этапа:

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

Медленный именно второй этап. Если на объект кто-то ссылается, удалить его нельзя — 1С покажет список «мест использования» и оставит объект в базе. Чем больше помеченных объектов и чем крупнее база, тем дольше обход.

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

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

• Пометка на удаление — ставит флажок, объект остаётся в базе.
• Исключение из удаления — снимает флажок, объект возвращается к обычной жизни.
• Физическое удаление — тот самый долгий процесс с контролем ссылок, который стирает объект насовсем.

Когда помечаете на удаление группу или папку справочника, пометку получают и все подчинённые элементы. Если потом удалять их по одному, контроль ссылок отработает по каждому отдельно — медленно. Удаляйте такие ветки целиком одним запуском обработки, тогда поиск ссылок пройдёт пакетно.

Где найти обработку удаления в разных конфигурациях

Сама обработка входит в состав типовых конфигураций на БСП. Пути отличаются по конфигурациям, но логика одна — раздел администрирования, группа обслуживания.

В окне обработки есть два режима:

• Автоматическое удаление — программа сама находит всё помеченное и пытается удалить с полным контролем ссылок.
• Выборочное — вы отмечаете только нужные группы объектов. Удобно, когда часть помеченного удалять пока рано.

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

Права, без которых удаление не запустится

Физическое удаление — административная операция. Обычному пользователю с правами на ввод документов она недоступна, и это правильно: удаление необратимо.

Чтобы запустить обработку, у пользователя должен быть профиль с административными правами:

• в конфигурациях на основе БСП это профиль «Администратор» в Администрирование → Настройки пользователей и прав → Профили групп доступа;
• на уровне ролей за операцию отвечает роль интерактивного удаления помеченных объектов — она входит в административный профиль по умолчанию.

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

Монопольный режим: когда он нужен и чем опасен

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

• нет конкурентных блокировок — поиск ссылок не ждёт, пока освободятся занятые другими сеансами таблицы;
• пока идёт контроль, никто не создаёт новых документов со ссылками на удаляемые объекты, поэтому не возникает ситуаций «объект нельзя удалить, появилась свежая ссылка».

Стандартная обработка сама предложит установить монопольный режим и предупредит, что активные пользователи будут отключены.

Если установить монопольный режим не удаётся, 1С покажет список активных сеансов, которые мешают. В клиент-серверном варианте их можно посмотреть и завершить в консоли администрирования кластера — но помните, что завершение сеанса обрывает работу пользователя.

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

Если база работает в распределённом варианте (РИБ), помните о порядке: удалять объект стоит там, где он создаётся, а затем дать отработать обмену. Удаление в подчинённом узле без синхронизации приводит к тому, что объект «возвращается» следующим обменом из главного узла. Это не про скорость, но именно это часто выглядит как «удалил, а оно опять помечено».

Прямые SQL-запросы: почему это не способ ускорения

В выдаче по этой теме часто всплывает совет «удалить объекты напрямую через SQL, минуя платформу». Разберёмся честно: на рабочей базе так делать нельзя.

1С хранит данные в таблицах СУБД, но имена таблиц и полей обфусцированы (_Reference123, _Document45), а связи между объектами платформа держит в своей логике, а не в ограничениях базы. Прямое DELETE из таблицы:

• не проверяет ссылки — вы получите «висящие» ссылки на несуществующий объект и битые отчёты;
• не трогает связанные регистры и движения — данные рассинхронизируются;
• делает базу некорректной с точки зрения платформы, вплоть до невозможности провести документы.

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

Для MS SQL Server перед массовым удалением полезно:

• обновить статистику по базе;
• перестроить или реорганизовать индексы (REBUILD / REORGANIZE);
• проверить, что база не упёрлась в автоувеличение файла и свободное место на диске есть.

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

То есть правильный «SQL-способ» — это не удалять данные руками, а держать СУБД в форме, чтобы быстрее работала штатная обработка.

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

Фоновое удаление по расписанию

Самый спокойный вариант для рабочей базы — не запускать удаление руками днём, а поручить его регламентному заданию. В типовых конфигурациях есть регламентное задание удаления помеченных объектов, которое отрабатывает по расписанию без участия пользователя.

Что это даёт:

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

Расписание настраивается там же, в разделе обслуживания, либо в списке регламентных и фоновых заданий (Администрирование → Обслуживание → Регламентные операции). Проверьте два момента: задание включено (стоит флажок активности) и задано разумное расписание — например, ежедневно ночью. Если задание выключено, помеченное будет копиться, и ручной запуск снова окажется долгим.

Фоновое удаление не контролирует ссылки менее строго — оно так же не удалит объект, на который ссылаются. Разница лишь в том, что процесс идёт без вашего участия и в удобное время. Объекты, которые не удалились из-за ссылок, останутся помеченными до следующего запуска, и их стоит периодически разбирать вручную.

Если удаление зависает или не идёт

Когда обработка «висит» или объекты не удаляются, причина обычно не в скорости, а в конкретном препятствии. Сопоставьте симптом с причиной.

Что в итоге реально ускоряет

Сведём способы по эффекту и трудозатратам.

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

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