Как уменьшить объем базы 1С

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

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

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

Как узнать, что именно занимает место в базе

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

В клиент-серверном варианте размер таблиц смотрят средствами СУБД: в MS SQL Server — через отчет «Disk Usage by Table» в Management Studio, в PostgreSQL — запросами к системным представлениям с функциями pg_relation_size. Чаще всего лидируют по объему регистры накопления и сведений, таблица версий объектов, таблица итогов и журнал регистрации.

Полезно заранее зафиксировать исходный размер базы и размеры крупнейших таблиц — потом по ним вы оцените эффект каждого шага и не будете работать вслепую.

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

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

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

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

Очистка журнала регистрации

Журнал регистрации хранится отдельно от основных данных (в файловой базе — в каталоге 1Cv8Log рядом с файлом базы), но его объем влияет на общее место на диске и на время выгрузки базы в dt. При включенной регистрации всех событий журнал может вырасти до десятков гигабайт.

Сократить журнал можно в конфигураторе: «Администрирование → Журнал регистрации → Сократить». Укажите дату, до которой события удаляются, и обязательно сохраните выгрузку старой части журнала в файл, если история может понадобиться для аудита. Параллельно проверьте настройку уровня регистрации событий — часто достаточно регистрировать ошибки и предупреждения, а не все действия пользователей.

Свертка базы: перенос остатков на дату

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

В типовых конфигурациях (Бухгалтерия, ERP, Управление торговлей и другие) есть штатная обработка свертки информационной базы. Она работает поэтапно: анализ данных, формирование остатков, контроль, удаление старых документов. Процесс на большой базе занимает от нескольких часов до нескольких суток и требует монопольного доступа.

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

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

Сжатие файлов базы: файловый и клиент-серверный варианты

Удаление данных внутри базы не всегда уменьшает файлы на диске — освободившееся место остается зарезервированным внутри файлов. Поэтому после массовых удалений нужна отдельная операция сжатия.

Для файловой базы используют тестирование и исправление (конфигуратор → «Администрирование → Тестирование и исправление») с включенной опцией сжатия таблиц, либо выгрузку базы в dt и загрузку обратно — новый файл создается без «дыр». Вариант с выгрузкой/загрузкой часто дает лучший результат, но требует времени и свободного места под dt-файл.

В клиент-серверном варианте сжатие выполняется средствами СУБД. Для MS SQL Server это операции DBCC SHRINKDATABASE или shrink файлов через Management Studio, для PostgreSQL — VACUUM FULL или pg_repack. Учтите, что shrink в MS SQL фрагментирует индексы — после него рекомендуется перестроить индексы и обновить статистику.

DBCC SHRINKDATABASE (N'ИмяБазы', 10); DBCC INDEXDEFRAG или перестроение индексов после сжатия

Как не допустить повторного разрастания базы

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

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

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