Чем раздувается база 1С Бухгалтерия и как её сократить

Объём базы 1С Бухгалтерия сокращают с двух сторон: сначала убирают из неё лишние данные — журнал регистрации, историю изменений, помеченные на удаление объекты, присоединённые файлы, — а потом физически сжимают сам файл или базу на SQL Server. Для файлового варианта главный инструмент — режим Тестирование и исправление в Конфигураторе и выгрузка в .dt; для клиент-серверного — свёртка старых периодов плюс DBCC SHRINKFILE на стороне СУБД.

Какой приём нужен именно вам, зависит от того, что раздувает базу. Иногда 20 ГБ из 30 занимают сканы документов, подшитые прямо в базу, — тогда чистить проводки бессмысленно, надо выносить файлы на диск. А бывает, что файл давно не сжимался после удаления данных и пустое место просто не возвращено операционной системе.

С чего начинать: найдите, что именно занимает место

Прежде чем что-то удалять, поймите структуру роста. Чаще всего базу 1С раздувают пять источников:

• 📓 Журнал регистрации — все действия пользователей. В файловом варианте это отдельный файл 1Cv8.lgd рядом с базой, он легко разрастается до нескольких гигабайт.
• 🕓 История изменений (версионирование объектов) — копии документов и справочников на каждое перепроведение. Если включено хранение по всем объектам, прирост огромный.
• 📎 Присоединённые файлы — сканы, договоры, картинки. По умолчанию хранятся двоичными данными внутри базы.
• 🗑 Помеченные на удаление объекты — пока не удалены физически, занимают место и тянут связи.
• 🔎 Индекс полнотекстового поиска — служебные данные, которые можно перестроить.

Для файловой базы оцените эффект просто: запишите размер файла 1Cv8.1CD до операции и после. Для клиент-серверной посмотрите, какие таблицы крупнее всего. В SQL Server это делает стандартный отчёт Disk Usage by Table в SSMS или запрос:

SELECT TOP 20
    t.name AS Таблица,
    SUM(a.total_pages) * 8 / 1024 AS Размер_МБ
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 Размер_МБ DESC;

Имена таблиц у 1С служебные (_Reference123, _AccumRg456, _InfoRg...), но по префиксу видно тип: Reference — справочник, Document — документ, AccumRg — регистр накопления, AccRg — бухгалтерский регистр. Если верх списка занимает одна таблица регистра — значит, базу раздувают движения по этому регистру, и тут поможет свёртка.

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

Безопасная чистка: помеченные объекты, журнал и история

Начните с того, что сокращает базу без риска для учёта.

Удаление помеченных объектов. В 1С:Предприятии откройте Администрирование → Обслуживание → Удаление помеченных объектов. Обработка проверит ссылки и физически уберёт всё, что помечено крестиком. Пустое место внутри файла при этом освободится только логически — вернуть его ОС поможет последующее сжатие (см. ниже).

Очистка журнала регистрации. В Конфигураторе откройте Администрирование → Настройка журнала регистрации. Там задаётся, какие события записывать и за какой срок хранить. Можно сократить журнал до выбранной даты — старые записи удалятся, а файл 1Cv8.lgd уменьшится. Разумная настройка — хранить журнал 3–6 месяцев и не писать в него обращения к данным (самый «шумный» класс событий).

Очистка истории изменений. Если в базе включено версионирование (Администрирование → Общие настройки → История изменений), проверьте, по каким объектам оно ведётся. Часто галка стоит на всём подряд. Ограничьте версионирование важными документами, задайте срок хранения версий и удалите устаревшие — настройки хранения вызываются из того же раздела.

Полнотекстовый индекс и кэш. Индекс поиска хранится в базе; его можно очистить и перестроить заново (Администрирование → Поиск данных), а временный кэш клиента лежит в профиле пользователя и на размер самой базы не влияет.

Сжатие файловой базы: тестирование и выгрузка в .dt

В файловом варианте удаление данных не уменьшает файл 1Cv8.1CD автоматически — внутри образуются «дыры», которые занимают место на диске. Чтобы вернуть его, базу нужно физически пересобрать.

Способ первый — режим «Сжатие таблиц информационной базы». Запустите Конфигуратор, Администрирование → Тестирование и исправление, снимите лишние галки и оставьте только Сжатие таблиц информационной базы (этот пункт работает именно для файловых баз). Платформа перестроит таблицы компактно.

Способ второй, самый надёжный — выгрузка в .dt и загрузка обратно. В Конфигураторе: Администрирование → Выгрузить информационную базу в файл .dt, затем в чистую или ту же базу — Загрузить информационную базу. При загрузке платформа создаёт файл заново, без внутренней фрагментации. Нередко база после такой процедуры уменьшается на 10–30 %, даже если данные не трогали.

Перед любой из этих операций сделайте резервную копию и убедитесь, что в базе никто не работает — обе блокируют базу монопольно.

Для проверки физической целостности файловой базы есть утилита chdbfl.exe из каталога платформы — она лечит повреждения, но объём не сокращает. Это разные задачи: chdbfl — про целостность, тестирование и .dt — про компактность.

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

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

Порядок такой:

1. Откройте Администрирование → Настройки работы с файлами.
2. Включите хранение файлов в томах на диске и укажите каталог (на сервере он должен быть доступен службе 1С на запись).
3. Запустите перенос уже накопленных файлов из базы в тома — для этого в типовых конфигурациях есть отдельная обработка переноса.

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

Клиент-серверная база: лог транзакций и shrink в SQL

Когда база работает на SQL Server, растёт не только файл данных .mdf, но и журнал транзакций .ldf — а он при полной модели восстановления без регулярного бэкапа лога способен занять больше самой базы.

Разберитесь сначала с логом:

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

Освободившееся в файле данных место после свёртки и чисток возвращают операционной системе командой SHRINKFILE:

-- при необходимости снять лишнее с лога
ALTER DATABASE [ИмяБазы] SET RECOVERY SIMPLE;
DBCC SHRINKFILE (N'ИмяФайлаЛога', 512);   -- оставить ~512 МБ

-- вернуть место из файла данных
DBCC SHRINKFILE (N'ИмяФайлаДанных', 0);

Проверьте и настройки автоувеличения файлов. Если база растёт шагами по 1 МБ, файл дробится на тысячи фрагментов на диске; задайте приращение в мегабайтах фиксированным разумным шагом (например, 256–512 МБ для файла данных), а не в процентах. На размер это напрямую не влияет, но убирает скрытую фрагментацию, из-за которой кажется, что «база тормозит, хотя места много».

Регулярное обслуживание SQL (обновление статистики, дефрагментация индексов) ускоряет базу, но объём почти не меняет — не путайте скорость и размер. И следите за tempdb: 1С активно создаёт в нём временные таблицы, но на размер вашей базы это не влияет.

Свёртка базы: радикальное сокращение за счёт старых периодов

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

Типовую обработку «Свёртка информационной базы» 1С поставляет для своих конфигураций; в разных релизах БП 3.0 она может быть в разделе Администрирование или подключаться внешней обработкой через Файл → Открыть. Общий порядок:

1. Выберите дату свёртки — обычно начало года, за который отчётность закрыта.
2. Обработка сформирует документы ввода остатков по счетам и регистрам.
3. Старые документы и движения пометятся и будут удалены.
4. После этого выполните удаление помеченных объектов и сжатие (для файловой) или SHRINKFILE (для SQL), иначе место не вернётся.

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

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

Профилактика: чтобы база не пухла заново

Сократили один раз — настройте так, чтобы рост не вернулся:

• 🧹 Регламентные задания. Проверьте в Администрирование → Обслуживание, что удаление помеченных объектов и очистка старых версий идут по расписанию, а не копятся годами.
• 📓 Журнал регистрации. Задайте разумный срок хранения и исключите самые «шумные» события — не нужно вечно хранить каждое открытие формы.
• 🕓 Версионирование. Включайте историю изменений точечно, только по тем документам, где она реально нужна для контроля.
• 📎 Файлы — сразу в тома. Если включите хранение в томах на старте, база не станет хранилищем сканов.
• 💾 Отдельный бэкап лога на SQL. Регулярный бэкап журнала транзакций не даёт .ldf разрастаться.

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

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