Сжатие таблиц информационной базы 1С 8.3: что это и зачем оно нужно

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

Термин «сжатие таблиц» в контексте 1С 8.3 используется в двух разных смыслах, и их важно различать. Первый — shrink (усечение) файлов базы данных на уровне СУБД: физическое уменьшение файлов .mdf и .ndf в MS SQL Server или аналогичные операции в PostgreSQL. Второй — компрессия данных (data compression), когда СУБД хранит строки и страницы в сжатом виде, экономя место ценой дополнительной нагрузки на процессор. Оба приёма применяются администраторами, но преследуют разные цели.

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

Что происходит с базой при удалении данных

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

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

Два вида сжатия: усечение файлов и компрессия данных

Усечение (shrink) — операция, которая перемещает занятые страницы из конца файла в свободные участки ближе к началу и отсекает пустой «хвост». В MS SQL Server это делается командой DBCC SHRINKDATABASE или DBCC SHRINKFILE, в PostgreSQL аналогичного эффекта добиваются через VACUUM FULL или pg_repack. Усечение — разовая процедура после большого удаления данных, а не регулярное обслуживание.

Компрессия данных — постоянный механизм хранения. В MS SQL Server доступны ROW- и PAGE-компрессия для отдельных таблиц и индексов, в PostgreSQL сжатие больших значений выполняется механизмом TOAST автоматически. Компрессия уменьшает объём данных и ускоряет чтение с диска (меньше страниц — быстрее ввод-вывод), но повышает нагрузку на процессор при записи и чтении. Для баз 1С с интенсивной записью эффект нужно оценивать на тестовом контуре.

Когда сжатие действительно нужно

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

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

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

Как выполнить сжатие в MS SQL Server

Перед началом убедитесь, что есть актуальная резервная копия и достаточно свободного места на диске — в процессе усечения СУБД перемещает страницы, и журнал транзакций может заметно вырасти. Операцию выполняют в окно обслуживания, когда пользователи не работают с базой.

Сначала оцените объём свободного места в файлах, чтобы понять, есть ли смысл в операции:

DBCC SHRINKFILE (N'MyBase1C' , 0, TRUNCATEONLY); -- отсечь пустой хвост без перемещения данных
DBCC SHRINKFILE (N'MyBase1C', 60000); -- сжать файл данных до ~60 ГБ с перемещением страниц

Вариант с TRUNCATEONLY безопаснее и быстрее: он отсекает только непрерывное пустое пространство в конце файла и не фрагментирует индексы. Полное усечение с указанием целевого размера перемещает страницы и почти гарантированно приводит к высокой фрагментации — после него обязательна перестройка индексов.

1. 1
   Сделайте полную резервную копию базы средствами SQL Server
2. 2
   Оцените свободное место: свойства базы или запрос к sys.database_files
3. 3
   Завершите сеансы пользователей и фоновые задания 1С
4. 4
   Выполните DBCC SHRINKFILE, начав с варианта TRUNCATEONLY
5. 5
   Выполните перестройку индексов (ALTER INDEX ... REBUILD) по всем таблицам
6. 6
   Обновите статистику и проверьте скорость типовых операций
7. 7
   Убедитесь, что файл журнала транзакций вернулся к рабочему размеру

Сжатие в PostgreSQL и файловых базах

В PostgreSQL обычный VACUUM возвращает место для повторного использования внутри таблиц, но не уменьшает файлы. Для физического уменьшения применяют VACUUM FULL для конкретных таблиц — он переписывает таблицу целиком и требует блокировки на всё время выполнения. Альтернатива без длительной блокировки — расширение pg_repack, которое перестраивает таблицу в фоне. Для больших таблиц регистров накопления и сведений это основной рабочий инструмент.

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

Риски и частые ошибки

Главный риск усечения файлов в MS SQL — фрагментация индексов до 90% и выше. На базе 1С это проявляется как резкое замедление проведения документов, отчётов и закрытия месяца сразу после «успешного» сжатия. Поэтому усечение без последующей переиндексации — незавершённая операция.

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

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

После завершения операции сравните размер файлов базы до и после — в свойствах базы в Management Studio или запросом к системным представлениям. Проверьте фрагментацию ключевых индексов: для самых крупных таблиц она не должна превышать 10–15% после перестройки.

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

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