Как уменьшить базу 1С 8.3 Бухгалтерия

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

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

Важно понимать ключевой принцип: удаление данных внутри 1С почти никогда само по себе не уменьшает файл базы. Место освобождается только после сжатия таблиц — в файловом варианте через «Тестирование и исправление», в клиент-серверном — средствами СУБД (shrink в MS SQL, vacuum в PostgreSQL).

Определяем, что занимает место в базе

Прежде чем что-то удалять, полезно понять структуру занятого пространства. В файловом варианте размер базы — это размер файла 1Cv8.1CD в каталоге базы. В клиент-серверном варианте смотрят размер файлов данных и журнала транзакций в СУБД.

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

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

Обязательная подготовка: резервная копия и монопольный доступ

Любые операции по уменьшению базы необратимы, если что-то пойдёт не так. Перед началом сделайте полную резервную копию: для файловой базы — выгрузку в dt через конфигуратор («Администрирование» → «Выгрузить информационную базу») либо копирование файла 1Cv8.1CD при остановленной работе пользователей; для клиент-серверной — штатный бэкап средствами СУБД плюс выгрузку dt.

Проверьте, что копия действительно восстанавливается: загрузите dt в тестовую базу или разверните бэкап на копии сервера. Наличие файла бэкапа само по себе не гарантирует его пригодность.

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

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

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

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

Отдельно проверьте журнал регистрации. Через конфигуратор: «Администрирование» → «Журнал регистрации» → кнопка сокращения — укажите дату, до которой события можно удалить. Старый журнал регистрации в файловой базе хранится в отдельном файле 1Cv8.lgd и тоже может достигать значительных размеров.

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

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

Сжатие файловой базы через «Тестирование и исправление»

В файловом варианте удалённые данные остаются физически внутри файла 1Cv8.1CD до выполнения сжатия. Запустите конфигуратор, откройте «Администрирование» → «Тестирование и исправление» и отметьте пункт «Сжатие таблиц информационной базы». Обычно его совмещают с «Реиндексация таблиц» и «Проверка ссылочной целостности».

Режим «Тестирование и исправление» пересоздаёт таблицы, физически убирая удалённые записи, и файл базы уменьшается до реального объёма данных. На больших базах процесс занимает от десятков минут до нескольких часов — в это время база недоступна.

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

Уменьшение клиент-серверной базы средствами СУБД

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

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

В PostgreSQL применяют VACUUM FULL для возврата места системе (обычный VACUUM лишь помечает пространство как свободное внутри таблиц) и перестроение индексов через REINDEX. Эти операции требуют блокировок и свободного дискового пространства — планируйте их на нерабочее время.

Перед shrink в MS SQL убедитесь, что на диске достаточно свободного места — операция создаёт временные структуры. После сжатия рекомендуется перестроить индексы, так как shrink сильно фрагментирует данные и может временно замедлить работу.

Свёртка базы и перенос остатков в новую базу

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

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

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

Сравнение вариантов

Свёртка штатной обработкой

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

Перенос остатков в новую базу

Максимальное уменьшение и чистая структура. Ограничение: требует настройки переноса, тщательной сверки остатков и времени

Только сжатие без удаления

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

Работа с файловыми вложениями

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

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

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

Проверка результата и профилактика роста базы

После всех операций сравните размер базы с исходным: для файлового варианта — размер 1Cv8.1CD, для клиент-серверного — размер файлов данных и журнала в СУБД. Затем проверьте работоспособность: откройте основные отчёты (ОСВ, анализ счёта), проведите тестовый документ, убедитесь, что обмены и регламентные задания работают.

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

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

Контрольные точки

Как проверить результат

Размер файла 1Cv8.1CD / файлов СУБД

Норма

Заметно меньше исходного после сжатия

Тревожный признак

Размер не изменился — сжатие не выполнялось или завершилось с ошибкой

ОСВ и отчёты за текущий период

Норма

Остатки совпадают с данными до свёртки

Тревожный признак

Расхождения остатков — свёртка или перенос выполнены с ошибками

Открытие присоединённых файлов

Норма

Сканы открываются из томов

Тревожный признак

Ошибки доступа — перенос в тома не завершён

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

Можно ли уменьшить базу без конфигуратора?

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

Почему после удаления документов база не уменьшилась?

Удаление в 1С освобождает место только логически — страницы данных остаются внутри файла. Чтобы вернуть место операционной системе, нужно сжатие таблиц: «Тестирование и исправление» для файловой базы, SHRINK или VACUUM FULL для клиент-серверной.

Что безопаснее: свёртка или новая база с переносом остатков?

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

Как часто нужно сжимать базу?

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

Что делать, если файловая база приблизилась к пределу 4 ГБ на таблицу?

Срочно выполните свёртку старых периодов и сжатие, вынесите файловые вложения в тома. Это временные меры: при таком объёме данных стоит планировать переход на клиент-серверный вариант работы, где ограничение файлового формата отсутствует.

Нужно ли уменьшать базу, если она просто большая, но работает нормально?

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