База 1С разрослась до десятков гигабайт: где лишний объём и как его убрать

Уменьшить вес базы 1С можно в два этапа: сначала удалить лишние данные (старые версии объектов, зависшую регистрацию обменов, вложенные файлы, помеченные на удаление объекты), затем сжать сам файл. В файловом варианте это Конфигуратор → Администрирование → Тестирование и исправление с флагом сжатия таблиц или выгрузка в .dt и загрузка обратно. В клиент-серверном — обслуживание на стороне СУБД.

Без второго этапа чистка почти не видна: файл 1Cv8.1CD и файлы данных SQL сами не уменьшаются, освободившееся место остаётся внутри них. Поэтому многие удаляют гигабайты версий, а размер базы на диске не меняется ни на байт.

Подготовка: замерить, что именно занимает место

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

Резервная копия

Выгрузка: Конфигуратор → Администрирование → Выгрузить информационную базу. Для неё нужен монопольный доступ, поэтому делайте её вне рабочего времени.

Файловая база

Откройте каталог базы и посмотрите на файлы:

• 📁 1Cv8.1CD — сами данные. Именно его и уменьшаем.
• 📁 1Cv8Log — журнал регистрации. Хранится отдельно и на размер 1Cv8.1CD не влияет, но раздувает каталог и резервные копии.
• 📁 Папки томов с файлами, если их уже настраивали.

Узнать, какие таблицы внутри 1CD самые тяжёлые, штатными средствами нельзя. Практичный путь — загрузить .dt во временную базу на SQL или PostgreSQL и посмотреть там. Обычно хватает и косвенных признаков: смотрите, включено ли версионирование и есть ли обмены.

Клиент-серверная база

На MS SQL список самых тяжёлых таблиц даёт запрос:

SELECT t.name AS table_name,
       SUM(a.total_pages) * 8 / 1024 AS size_mb
FROM sys.tables t
JOIN sys.indexes i ON t.object_id = i.object_id
JOIN sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id
JOIN sys.allocation_units a ON p.partition_id = a.container_id
GROUP BY t.name
ORDER BY size_mb DESC;

На PostgreSQL:

SELECT relname,
       pg_size_pretty(pg_total_relation_size(relid)) AS size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 20;

Имена вида _InfoRg12345 или _ReferenceChngR678 ничего не говорят. Сопоставить их с объектами конфигурации помогает метод платформы ПолучитьСтруктуруХраненияБазыДанных(). Его можно выполнить во внешней обработке на сервере:

Структура = ПолучитьСтруктуруХраненияБазыДанных(, Истина);
Для Каждого Стр Из Структура Цикл
    Сообщить(Стр.ИмяТаблицыХранения + " — " + Стр.ИмяТаблицы);
КонецЦикла;

Второй параметр Истина возвращает имена таблиц так, как их видит СУБД. Найдите в выводе три-пять самых тяжёлых таблиц из запроса выше, и станет ясно, с какого раздела ниже начинать.

История изменений: главный источник лишних гигабайт

В типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) каждая запись документа или справочника может сохранять полную копию объекта. Копии лежат в регистре сведений ВерсииОбъектов. Документ, который перепроводили 20 раз, хранится 21 раз.

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

Как сократить историю

1. Откройте Администрирование → Общие настройки.
2. Найдите группу настроек истории изменений и перейдите по ссылке настроек хранения.
3. Для каждого вида объектов задайте, хранить ли версии и сколько: за последний год, за последние полгода и так далее.
4. Для объектов, где история не нужна (например, служебные справочники), отключите её совсем.
5. Запустите удаление устаревших версий кнопкой в той же форме или дождитесь регламентного задания.

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

История данных платформы

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

Свёртка и удаление устаревших данных

Если база ведётся 8–10 лет, основной объём дают сами документы и движения регистров. Удалить «старые годы» простым удалением нельзя: сломаются остатки.

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

Начните с малого. Объекты, помеченные на удаление, занимают место, пока их не удалят окончательно:

1. Откройте Администрирование → Обслуживание.
2. Найдите команду удаления помеченных объектов.
3. Выберите автоматический режим или отметьте объекты вручную.
4. Объекты, на которые остались ссылки, программа не удалит и покажет, где они используются.

Свёртка информационной базы

Свёртка заменяет документы до выбранной даты на документы ввода остатков. В Бухгалтерии 3.0 и УТ 11 для этого есть обработка свёртки в разделе Администрирование → Обслуживание. Она может работать несколько часов на крупной базе.

Перед свёрткой:

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

Новая база с остатками

Альтернатива свёртке — начать новую базу с начала года и перенести в неё справочники и остатки. Старая база остаётся архивом только для чтения. Этот вариант надёжнее на «тяжёлых» базах с ошибками в прошлых периодах, где свёртка падает.

Обмены данными: зависшая регистрация изменений

Каждое изменение объекта, который участвует в обмене, регистрируется для каждого узла плана обмена. Пока узел не принял пакет и не подтвердил его, записи копятся.

Классическая ситуация: магазин закрыли, филиал перешёл на другую базу, интеграцию с сайтом отключили, а узел остался. За пару лет таблицы регистрации набирают миллионы строк.

Что делать

1. Откройте Администрирование → Синхронизация данных и посмотрите дату последнего успешного обмена по каждой настройке.
2. Неиспользуемые настройки синхронизации удалите из этой формы: типовой механизм очистит и узел, и его регистрацию.
3. Если узел нужен, но регистрация скопилась ошибочно, очистите её программно для конкретного узла:

ПланыОбмена.УдалитьРегистрациюИзменений(Узел);

Таблицы регистрации в СУБД узнаются по окончанию ChngR в имени. Если именно они в верхних строках замера, проблема в обменах.

Журнал регистрации, кэш и временные файлы

Эти данные не лежат внутри 1Cv8.1CD, но часто дают те самые «лишние 20 ГБ» на диске сервера.

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

Сократить его можно в Конфигуратор → Администрирование → Настройка журнала регистрации. Там же задаётся уровень регистрации. Кнопкой сокращения удаляются записи до выбранной даты, при этом их можно сохранить в отдельный файл.

• 📌 Уровень «Регистрировать всё» на загруженной базе даёт гигабайты в месяц. Для повседневной работы обычно хватает ошибок и предупреждений.
• 📌 Перед сокращением сохраните старые записи в файл, если журнал может понадобиться для разбора инцидентов.

Кэш клиента

Локальный кэш хранится в профиле пользователя: %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8. Папки с длинными именами-идентификаторами внутри — это кэш конфигураций. На размер базы он не влияет, но на терминальном сервере с 30 пользователями легко занимает десятки гигабайт.

Удалять кэш можно, только когда пользователь вышел из 1С. Для одного запуска есть параметр /ClearCache:

"C:\Program Files\1cv8\common\1cestart.exe" /ClearCache

Временные файлы сервера

На сервере 1С временные файлы сеансов хранятся в каталоге кластера srvinfo. Чистить его вручную при работающей службе нельзя.

Вложения и картинки: перенос в тома на диске

Сканы первичных документов, фото номенклатуры и вложения писем по умолчанию хранятся прямо в базе. Тысяча сканов по 2–3 МБ — это уже 2–3 ГБ, которые попадают в каждую резервную копию.

Типовые конфигурации умеют хранить файлы в томах — обычных папках на диске или в сетевом хранилище:

1. Откройте Администрирование → Общие настройки, группу присоединённых файлов.
2. Включите хранение файлов в томах на диске.
3. Создайте том: укажите путь к папке. Для серверной базы путь должен быть доступен пользователю, от имени которого работает служба 1С, лучше в UNC-формате \\server\1c_files.
4. Перенесите уже загруженные файлы в том командой переноса в той же группе настроек.

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

Сжатие файла: как вернуть место на диске

После чистки физический размер базы не меняется. Освобождённые страницы нужно вернуть операционной системе.

Файловая база

Способ 1 — тестирование и исправление:

1. Выгоните всех пользователей из базы: нужен монопольный доступ.
2. Конфигуратор → Администрирование → Тестирование и исправление.
3. Отметьте «Сжатие таблиц информационной базы». Остальные флаги для задачи уменьшения размера не нужны.
4. Нажмите «Выполнить».

Способ 2 — выгрузка и загрузка .dt. База пересобирается с нуля, без фрагментации и пустых страниц. Обычно этот способ даёт заметно больший эффект, чем сжатие таблиц. Для проверки физической целостности перед сжатием можно запустить утилиту chdbfl.exe из каталога bin платформы.

MS SQL Server

Частая причина огромной базы — не данные, а файл журнала транзакций .ldf. При модели восстановления FULL и без регулярного резервного копирования журнала он растёт бесконечно.

Сначала посмотрите размеры и логические имена файлов:

SELECT name, type_desc, size * 8 / 1024 AS size_mb
FROM sys.database_files;

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

ALTER DATABASE [buh] SET RECOVERY SIMPLE;
DBCC SHRINKFILE (N'buh_log', 1024);

Здесь buh — имя базы, buh_log — логическое имя журнала из предыдущего запроса, 1024 — целевой размер в мегабайтах.

Сжимать файл данных (DBCC SHRINKFILE для ROWS) стоит только после крупной чистки. Сжатие сильно фрагментирует индексы, поэтому сразу после него перестройте их в плане обслуживания.

PostgreSQL

Обычный VACUUM помечает место для повторного использования, но файл не уменьшает. Вернуть место ОС может VACUUM FULL, он переписывает таблицу целиком:

VACUUM FULL VERBOSE _inforg12345;

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