При выполнении длительной серии обновлений (например, переход через 20–25 релизов подряд) администраторы часто сталкиваются с тем, что база данных 1С:Управление торговлей (УТ 11) начинает стремительно расти в объеме. В некоторых случаях база может увеличиться с 500 МБ до 7 ГБ и более. Это происходит из-за особенностей работы СУБД PostgreSQL, механизмов хранения конфигураций в 1С и накопления технических данных в процессе выполнения обработчиков обновления.
В данной статье мы подробно разберем, почему это происходит, и проанализируем шаги, которые помогут вернуть базе адекватный размер и стабильную производительность.
Прежде чем переходить к активным действиям, выясним причину «опухания» базы. Основных факторов три:
Config и ConfigSave. При многократных итерациях объем метаданных может увеличиться в разы.Первое, что мы должны рассмотреть — это регламентные процедуры самой СУБД. Если база сильно разрослась, стандартный autovacuum может не справляться. Проанализируем ситуацию: нам необходимо физически высвободить место на диске.
Рассмотрим выполнение полной очистки через pgAdmin или консоль запросов. Самым эффективным, но «тяжелым» методом является выполнение команды VACUUM FULL. Обратите внимание, что эта операция полностью блокирует таблицы, поэтому ее нужно выполнять в период отсутствия пользователей.
Последовательность действий в pgAdmin:
Эта команда пересоздаст файлы таблиц без «пустот». Также крайне рекомендуется выполнить REINDEX DATABASE, так как индексы при массовых обновлениях раздуваются не меньше, чем сами данные.
Если манипуляции с PostgreSQL не дали радикального уменьшения размера (или если база была временно переведена в файловый вариант для тестов), воспользуемся встроенными средствами платформы 1С.
Проанализируем работу функции Тестирование и исправление (ТиИ). Для наших целей критически важна опция «Сжатие таблиц информационной базы». Рассмотрим алгоритм действий:
Как показывает практика, выполнение ТиИ на файловой копии базы может сократить размер файла 1Cv8.1CD в несколько раз (например, с 6.5 ГБ до 2 ГБ), после чего чистую базу можно загрузить обратно на сервер.
Рассмотрим метод, который многие специалисты считают «золотым стандартом» очистки от мусора. Выгрузка в файл .dt и последующая загрузка в новую чистую базу данных на PostgreSQL позволяет полностью перестроить структуру таблиц и индексов на уровне СУБД.
Важно: Всегда делайте резервную копию перед этой процедурой!
Разберем последовательность действий:
.dt через Конфигуратор.lc_collate и lc_ctype)..dt в новую базу.Этот метод эффективно удаляет системный мусор и оптимизирует хранение данных, так как платформа при загрузке создает таблицы «с нуля».
Ситуация, когда конфигурация базы данных весит аномально много, часто связана с избыточными данными в конфигурации поставщика. Проанализируем состояние через меню Конфигурация — Поддержка — Настройка поддержки. Если вы видите, что база «пухнет» именно из-за метаданных, можно попробовать следующий прием:
.cf актуального релиза)..dt.Это удаляет историю изменений внутри системных таблиц 1С, которая могла накопиться за 25 этапов обновления.
Выясним причину роста в самой конфигурации УТ 11. Часто после обновлений остаются заполненными технические регистры. Рассмотрим, на что стоит обратить внимание в первую очередь:
ЗамерыВремени: Иногда при отладке или после обновлений он забивается тысячами записей, занимая гигабайты пространства.ВерсииОбъектов: Если включено версионирование, то массовое изменение документов обработчиками обновления создаст копию каждой версии каждого документа.Если в процессе работы с разросшейся базой клиенты начинают вылетать с ошибкой в модуле ucrtbase.dll, это часто сигнализирует о нехватке памяти или проблемах с кэшем. Выполним следующие действия:
snccntxt в каталоге службы сервера 1С).Подводя итог, можно сказать, что наиболее эффективным комплексом мер является выгрузка/загрузка через DT в сочетании с последующей настройкой регулярного VACUUM ANALYZE в PostgreSQL. Это не только уменьшит размер базы, но и значительно ускорит работу пользователей.