Как очищать служебные сообщения в 1С

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

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

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

Что относится к служебным сообщениям и где они хранятся

Прежде чем что-то удалять, нужно понять, какие именно сообщения раздувают базу. В типовых конфигурациях и на уровне платформы встречаются несколько независимых хранилищ, и чистить их нужно по-разному.

• Регистры сведений очередей сообщений — используются в модели сервиса и при асинхронном обмене между приложениями. Записи накапливаются, если обработчики сообщений завершаются с ошибками.
• Сообщения системы взаимодействия — переписка пользователей, уведомления и обсуждения внутри 1С. Хранятся на сервере взаимодействия и в базе.
• Служебные сообщения обмена данными — квитанции, подтверждения доставки, служебные пакеты в планах обмена и универсального формата EnterpriseData.
• Журнал регистрации — технически это не сообщения, но именно его рост администраторы часто принимают за «мусор» и чистят вместе с остальным.

Подготовка: резервная копия и анализ объёма

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

Далее оцените, какие таблицы реально занимают место. В клиент-серверном варианте это делается запросами к системным представлениям СУБД (например, pg_stat_user_tables в PostgreSQL или sys.dm_db_partition_stats в MS SQL). В файловом варианте ориентируйтесь на косвенные признаки: количество записей в регистрах сведений с «сообщением» в имени, которое видно через консоль запросов или универсальный отчёт.

Очистка регистров сведений очередей сообщений

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

Штатная очистка через интерфейс

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

Очистка встроенным языком

Для массовой очистки удобнее выполнить код через консоль кода (обработку «Консоль кода» из состава инструментов разработчика или аналог). Типовой подход — выбрать записи старше пороговой даты и удалить их наборами записей:

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 10000
| Очередь.Идентификатор
|ИЗ
| РегистрСведений.ОчередьСообщений КАК Очередь
|ГДЕ
| Очередь.ДатаСоздания < &ПорогДаты";
Запрос.УстановитьПараметр("ПорогДаты", ДобавитьМесяц(ТекущаяДатаСеанса(), -1));
Результат = Запрос.Выполнить().Выбрать();
Пока Результат.Следующий() Цикл
Набор = РегистрыСведений.ОчередьСообщений.СоздатьНаборЗаписей();
Набор.Отбор.Идентификатор.Установить(Результат.Идентификатор);
Набор.Записать(); // запись пустого набора = удаление
КонецЦикла;

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

1. 1
   Сделайте резервную копию базы и убедитесь, что она восстанавливается
2. 2
   Найдите точное имя регистра сведений в конфигураторе
3. 3
   Проверьте, нет ли незавершённых обменов и ошибок фоновых заданий
4. 4
   Удалите записи старше порога порциями через консоль кода или интерфейс
5. 5
   Проверьте количество оставшихся записей и работу обмена после очистки

Очистка сообщений системы взаимодействия

Система взаимодействия (обсуждения, уведомления, видеозвонки) хранит сообщения на сервере взаимодействия. Если база работает давно и обсуждения активно используются, объём переписки может стать заметным, а старые сообщения редко представляют ценность.

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

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

Очистка служебных сообщений обмена данными

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

Штатные механизмы

Проверьте настройки плана обмена: во многих конфигурациях есть параметры хранения истории обмена и автоматического удаления служебных файлов после выгрузки. Включите их, если это не сделано. Для обменов через каталог или FTP также проверьте сами каталоги — файлы сообщений обмена (XML-пакеты) часто копятся на диске, а не в базе, и их нужно чистить отдельно.

Регистрация изменений

Отдельная статья расхода места — регистрация изменений в узлах планов обмена. Если узел обмена больше не используется, удалите его вместе с регистрацией изменений (штатная команда удаления узла очищает связанную регистрацию). Не удаляйте регистрацию изменений у действующих узлов — это приведёт к необходимости полной повторной выгрузки всех данных.

Сокращение журнала регистрации

Журнал регистрации формально не относится к сообщениям, но чистится в рамках той же процедуры обслуживания. В файловом варианте журнал хранится в формате lgd и при долгой работе может занимать гигабайты, замедляя открытие базы и запись событий.

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

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

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

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

Размер базы после очистки

Норма

Размер файла или таблиц СУБД заметно уменьшился после сжатия/реиндексации

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

Размер не изменился — вероятно, данные удалились, но таблицы требуют сжатия средствами СУБД

Работа обменов

Норма

Обмены выполняются без ошибок, квитанции приходят

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

Ошибки «сообщение не найдено» или повторная полная выгрузка — удалены нужные служебные данные

Фоновые задания

Норма

Задания обработки очереди завершаются успешно

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

Задания падают с ошибками — нужна диагностика обработчиков

Автоматизация: регламентные задания и расписание обслуживания

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

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

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

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

Удалятся ли служебные сообщения при тестировании и исправлении базы?

Нет. Тестирование и исправление проверяет целостность данных и может удалять битые ссылки, но целенаправленно не очищает очереди сообщений и журнал регистрации. Эти области обслуживаются отдельными операциями.

Можно ли очистить регистр сообщений напрямую запросом к СУБД?

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

Какой срок хранения сообщений выбрать?

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

Почему после удаления записей размер файла базы не уменьшился?

Удаление строк освобождает место внутри файла или таблиц, но не сжимает их физически. В файловом варианте выполните тестирование и исправление с сжатием, в клиент-серверном — сжатие таблиц средствами СУБД (shrink/reindex по регламенту администратора СУБД).

Что делать, если очередь сообщений растёт снова сразу после очистки?

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