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

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

Прежде чем что-либо удалять, важно понять, чем именно занят объём. Часто основной вес дают не сами документы, а регистры сведений с историей, хранилища версий объектов, журналы регистрации и присоединенные файлы. Стратегия сокращения базы выбирается под конкретный «тяжёлый» участок — универсальной кнопки «сжать всё» в 1С нет.

Все операции, описанные ниже, выполняйте только после создания резервной копии и желательно сначала на копии базы. Ошибка при свёртке или удалении данных необратима: восстановить «как было» можно только из бэкапа.

Сначала выясните, что занимает место

Без диагностики уменьшение базы превращается в стрельбу вслепую. Для файловой базы посмотрите размер файла 1Cv8.1CD и сравните его с тем, что было полгода назад — темп роста подскажет масштаб проблемы. Для клиент-серверной базы на MS SQL Server полезно посмотреть размеры таблиц: стандартный отчёт «Disk Usage by Table» в Management Studio покажет, какие таблицы самые тяжёлые.

Типичные «пожиратели» объёма в 1С: регистры сведений с периодической историей (курсы валют, версии объектов, история изменений), журнал регистрации при включённом подробном уровне, присоединенные файлы, хранящиеся в базе, а также движения по регистрам накопления за много лет. Нередко половину объёма дают данные, которые бизнесу уже не нужны.

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

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

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

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

Выполните свёртку базы на дату

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

В типовых конфигурациях (Бухгалтерия предприятия, Управление торговлей, ERP) есть штатная обработка «Свёртка базы». Она работает в несколько этапов: формирование остатков, создание документов ввода, пометка на удаление старых документов, затем удаление помеченных. Каждый этап нужно контролировать: сверьте оборотно-сальдовую ведомость и ключевые отчёты до и после свёртки — цифры на дату свёртки обязаны совпасть.

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

1. 1
   Сделайте полную резервную копию и проверьте, что она восстанавливается
2. 2
   Разверните копию базы и отработайте свёртку на ней
3. 3
   Сформируйте контрольные отчёты (ОСВ, остатки склада, взаиморасчёты) на дату свёртки
4. 4
   Запустите штатную обработку свёртки в монопольном режиме
5. 5
   Проверьте документы ввода остатков и сверьте отчёты с контрольными
6. 6
   Удалите помеченные объекты и выполните реструктуризацию/сжатие
7. 7
   Повторите процедуру на рабочей базе в нерабочее время

Почистите журнал регистрации, регистры и присоединенные файлы

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

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

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

Сожмите таблицы после очистки

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

Для MS SQL Server используйте сжатие базы или отдельных файлов (DBCC SHRINKDATABASE / SHRINKFILE) с осторожностью: частое сжатие вызывает фрагментацию индексов, после него обязательно выполните реорганизацию или перестроение индексов. Более правильный подход — настроить сжатие данных на уровне таблиц (PAGE compression) для самых больших таблиц, это даёт устойчивую экономию места без ручных операций.

Дополнительно обновите статистику и очистите процедурный кэш после массовых операций — это поможет оптимизатору СУБД строить адекватные планы запросов на «новой» компактной базе.

DBCC SHRINKFILE (N'MyBase1C_Data', TRUNCATEONLY); EXEC sp_updatestats;

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

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

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

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

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

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

Не менее распространены технические промахи: запуск длительных операций в рабочее время с вытеснением пользователей, прерывание сжатия по питанию, отсутствие сверки отчётов после свёртки и забытое перестроение индексов после сжатия базы на SQL Server. Каждый из этих пунктов способен свести на нет весь эффект или создать новую проблему.

Как проверить результат и оценить эффект

Эффективность работ по уменьшению базы оценивайте по трём признакам: физический размер файла или базы на диске, скорость типовых операций (проведение документа, формирование ОСВ) и длительность регламентных задач вроде бэкапа. Замеры делайте до и после — иначе эффект останется субъективным.

Контрольная точка корректности — совпадение учётных данных. Сравните оборотно-сальдовую ведомость, остатки по складу и взаиморасчётам на дату свёртки в старой копии и в уменьшенной базе. Любое расхождение — повод остановиться и разобраться до запуска базы в работу.

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