Почему база 1С весит десятки гигабайт и что с этим делать

Уменьшить базу 1С быстрее всего двумя действиями: сократить журнал регистрации (Конфигуратор → Администрирование → Журнал регистрации) и сжать таблицы через Администрирование → Тестирование и исправление с флажком «Сжатие таблиц информационной базы». Для файловой базы ещё надёжнее выгрузить её в .dt и загрузить обратно: файл 1Cv8.1CD пересобирается без пустых страниц. Для базы на MS SQL или PostgreSQL методы очистки другие — там место освобождают средствами самой СУБД.

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

Что раздувает базу 1С: ищем причину до очистки

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

🔍 Типичные «пожиратели» места:

• 📜 Журнал регистрации — за несколько лет на 20–30 пользователей легко набирает 5–15 ГБ.
• 🗂 Версии объектов — механизм версионирования хранит копию документа после каждой записи. В базах, где документы часто перезаписывают, эта таблица бывает крупнейшей.
• 🔄 Регистрация изменений для обменов — если узел обмена давно не работает (закрыли филиал, отключили сайт), изменения копятся в таблицах ...ChngR годами.
• 📦 Присоединённые файлы — сканы, PDF, вложения ЭДО, хранящиеся внутри базы.
• 🧾 Движения регистров за много лет без свёртки.
• 🕳 Пустые страницы в файле 1Cv8.1CD после удаления данных.

Файловая база: смотрим на диск

Откройте каталог базы (путь виден в списке баз в окне запуска, кнопка Изменить). В нём:

Частая картина: 1Cv8.1CD весит 4 ГБ, а папка 1Cv8Log — 9 ГБ. Тогда пользователь видит «база 13 ГБ», хотя данных втрое меньше.

Клиент-серверная база: смотрим таблицы СУБД

В MS SQL посмотрите двадцать самых больших таблиц:

SELECT TOP 20
    t.name AS table_name,
    SUM(a.total_pages) * 8 / 1024 AS total_mb,
    SUM(CASE WHEN i.index_id IN (0, 1) AND a.type = 1 THEN p.rows ELSE 0 END) AS rows_count
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 total_mb DESC;

В PostgreSQL то же самое:

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

Имена таблиц будут служебными: _InfoRg1234, _AccumRg567, _Document89_VT90. Чтобы понять, какой объект метаданных за ними стоит, вызовите в консоли запросов или внешней обработке функцию ПолучитьСтруктуруХраненияБазыДанных(). Она вернёт таблицу соответствия «имя в СУБД → объект конфигурации».

💡 Если в топе таблица с окончанием ChngR — это регистрация изменений плана обмена. Если регистр сведений с именем вроде «ВерсииОбъектов» — версионирование. Это два самых частых сюрприза.

Очистка журнала регистрации и служебных данных

Журнал регистрации полезен для расследований, но держать в нём пять лет истории редко нужно.

Сокращение журнала через Конфигуратор

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

Настройка, чтобы журнал не рос снова

В том же меню есть Администрирование → Настройка журнала регистрации. Там задаются:

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

⚠️ Перевод журнала на уровень «Не регистрировать» лишит вас истории при разборе инцидентов. Не делайте так в рабочей базе.

Где журнал у серверной базы

У клиент-серверной базы журнал хранится не в SQL, а в каталоге кластера, по умолчанию C:\Program Files\1cv8\srvinfo\reg_1541\<GUID базы>\1Cv8Log. Поэтому его сокращение освобождает диск сервера, но не уменьшает базу в СУБД. Сокращать его лучше тем же способом из Конфигуратора, а не удалять файлы руками.

Версии объектов и присоединённые файлы

В типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) версионирование настраивается в Администрирование → Общие настройки, блок «Версионирование объектов». Там можно:

• отключить хранение версий для объектов, где история не нужна;
• задать срок хранения;
• удалить устаревшие версии.

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

Тестирование и исправление: сжатие таблиц базы

Это штатный механизм платформы. Он проверяет структуру и физически сжимает таблицы.

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

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

Для уменьшения размера ключевые флажки — сжатие и реиндексация. Остальные запускают при подозрении на ошибки.

💡 Для файловой базы есть ещё утилита chdbfl.exe в каталоге bin установленной платформы. Она проверяет физическую целостность 1Cv8.1CD без запуска Конфигуратора. Место она почти не освобождает, но полезна, если база не открывается и тестирование запустить нельзя.

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

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

Удалять имеет смысл, если в базе тысячи помеченных на удаление документов и элементов справочников.

Удаление помеченных

В Бухгалтерии 3.0, ЗУП 3.1 и УТ 11 обработка запускается из раздела Администрирование → Обслуживание, группа «Корректировка данных», команда «Удаление помеченных объектов».

1. Выберите автоматическое удаление всех помеченных или выборочное.
2. Программа проверит, нет ли ссылок на удаляемые объекты.
3. Объекты, на которые кто-то ссылается, останутся — обработка покажет, где именно ссылка.

⚠️ Удаление необратимо. Восстановить удалённый документ можно только из резервной копии, поэтому проверьте список перед запуском.

Что даёт перепроведение

Само по себе перепроведение базу не уменьшает. Оно пересоздаёт движения документов, и объём остаётся примерно тем же. Пользу оно приносит в двух случаях:

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

В Бухгалтерии 3.0 групповое перепроведение находится в разделе Операции, в группе закрытия периода: команда «Групповое перепроведение документов ». Запускайте его на закрытых периодах осторожно: могут измениться сформированные отчёты.

Свёртка базы

Если основной объём — движения регистров за 7–10 лет, удаление помеченных не поможет. Варианты:

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

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

Выгрузка и загрузка базы 1С в .dt и XML

Для файловой базы это самый действенный способ сжатия. При загрузке из .dt платформа создаёт 1Cv8.1CD заново, без накопленных пустых страниц.

1. Все пользователи выходят из базы.
2. Конфигуратор → Администрирование → Выгрузить информационную базу, сохраните файл .dt.
3. Создайте новую пустую базу в другом каталоге.
4. В новой базе: Конфигуратор → Администрирование → Загрузить информационную базу, укажите файл .dt.
5. Проверьте работу, сверьте пару отчётов и только потом подменяйте старую базу.

Пример из практики: база после удаления помеченных и сокращения журнала весила 11 ГБ, после цикла выгрузки-загрузки — 6,3 ГБ. Выгрузка .dt переносит пользователей, конфигурацию и данные, но не переносит журнал регистрации.

💡 Загрузку делайте в новый каталог, а не поверх рабочей базы. Если что-то пойдёт не так, у вас останется исходник.

Когда нужна выгрузка в XML

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

Особенности уменьшения базы на MS SQL и PostgreSQL

В клиент-серверном варианте 1С не управляет файлами данных напрямую. Место после удаления записей остаётся зарезервированным за СУБД.

MS SQL Server: лог транзакций

Самая частая причина, почему «база» на SQL весит 200 ГБ при 30 ГБ данных, — файл журнала транзакций .ldf. Он растёт, если база в модели восстановления Full, а резервное копирование журнала не настроено.

Узнайте логические имена файлов:

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

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

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

Здесь 1024 — целевой размер файла в мегабайтах.

⚠️ Переход на SIMPLE обрывает цепочку резервных копий журнала. Если у вас настроено восстановление на момент времени, вместо смены модели сделайте резервную копию журнала и уже потом сжимайте файл.

MS SQL Server: файл данных

DBCC SHRINKFILE для файла данных (.mdf) освобождает место, но сильно фрагментирует индексы. Если всё же сжимаете, после этого перестройте индексы — регламентным заданием обслуживания или через «Тестирование и исправление» с реиндексацией. Регулярно сжимать файл данных не нужно: он снова вырастет, а запросы начнут работать медленнее.

PostgreSQL

В PostgreSQL удалённые строки остаются «мёртвыми» до очистки:

• VACUUM ANALYZE — помечает место для повторного использования, работает без блокировок, но файл не уменьшает;
• VACUUM FULL имя_таблицы — переписывает таблицу и возвращает место диску, но блокирует таблицу на всё время работы.

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

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

Частые вопросы об уменьшении базы 1С