Свертка базы данных 1С — это процедура, к которой часто прибегают для повышения производительности системы и уменьшения занимаемого пространства на диске. Однако на практике администраторы баз данных и программисты часто сталкиваются с парадоксальной ситуацией: после удаления сотен тысяч документов прошлых периодов размер базы данных в СУБД PostgreSQL практически не уменьшается, а иногда даже временно увеличивается.
В этой статье мы подробно разберем, почему стандартная свертка в конфигурации «1С:Бухгалтерия предприятия 3.0» (БП 3.0) на СУБД PostgreSQL не приносит ожидаемого сокращения объема, и рассмотрим пошаговые инструкции, как реально освободить дисковое пространство.
При стандартной свертке внутри рабочей базы (так называемый метод «in-place») происходит пометка документов на удаление с последующим запуском регламентной процедуры «Удаление помеченных объектов». На этом этапе многие ожидают увидеть пропорциональное уменьшение размера файлов базы данных. Но этого не происходит по следующим причинам:
Контрагенты, Номенклатура, Договоры контрагентов, а также адресные классификаторы ФИАС/КЛАДР разрастаются до огромных размеров. Именно индексы и таблицы справочников часто составляют до 70% реального объема базы.DELETE не удаляет строки физически с диска. СУБД лишь помечает эти строки как «мертвые» (dead tuples). Место, занимаемое этими строками, резервируется под будущие записи этой же таблицы, но операционной системе физический объем файлов не возвращается.Прежде чем приступать к каким-либо операциям сжатия, нам необходимо локализовать проблему и понять, какие именно таблицы занимают дисковое пространство. Для этого используются специализированные внешние обработки 1С (в сообществе называемые «пузомерами») или прямые SQL-запросы к СУБД.
Проанализируем ситуацию в СУБД напрямую. Выполним следующий SQL-запрос в консоли управления PostgreSQL (например, через pgAdmin), чтобы вывести список самых больших таблиц базы данных:
SELECT
relname AS table_name,
pg_size_pretty(pg_total_relation_size(pg_class.oid)) AS total_size,
pg_size_pretty(pg_relation_size(pg_class.oid)) AS table_size,
pg_size_pretty(pg_indexes_size(pg_class.oid)) AS index_size
FROM pg_class
LEFT JOIN pg_namespace ON pg_namespace.oid = pg_class.relnamespace
WHERE nspname = 'public' AND relkind = 'r'
ORDER BY pg_total_relation_size(pg_class.oid) DESC
LIMIT 20;
Этот запрос поможет нам увидеть реальную картину. Если верхние строчки отчета занимают таблицы с именами вида _DataHistory... (версионирование объектов) или таблицы индексов, то удаление обычных документов не принесет видимого результата без дополнительной очистки технических таблиц.
Если массовое удаление документов все же было проведено успешно, нам необходимо физически вернуть освободившееся пространство операционной системе. Встроенный механизм автоматического обслуживания PostgreSQL (autovacuum) в штатном режиме лишь подготавливает страницы для новой записи, но не уменьшает размер файлов на диске.
Для физического освобождения дискового пространства выполним процедуру полного вакуумирования. Обратите внимание, что эта операция требует **монопольного доступа** к базе данных (все пользователи и фоновые задания 1С должны быть отключены):
VACUUM FULL ANALYZE;
Эта команда полностью перестроит таблицы, удалив из них «мертвые» строки, и вернет неиспользуемое пространство операционной системе.
REINDEX DATABASE имя_вашей_базы;
Важное примечание: Операция VACUUM FULL создает временную копию каждой сжимаемой таблицы, поэтому на диске сервера должно быть свободно не менее 100% объема самой большой таблицы вашей базы.
Массовое изменение и удаление сотен тысяч документов в 1С генерирует терабайты сопутствующего системного «мусора». Рассмотрим, какие механизмы необходимо временно отключать перед запуском процедуры свертки:
_ChngR). База гарантированно раздуется. На время свертки удалите регистрацию изменений или временно отключите узлы планов обмена.Практика администрирования крупных баз данных показывает, что стандартная свертка «in-place» в БП 3.0 практически никогда не дает ожидаемого уменьшения размера. Наиболее эффективным, чистым и быстрым способом является **перенос остатков в новую пустую информационную базу**.
Рассмотрим пошагово этот алгоритм:
Ввод остатков, сформированные на шаге 2.При таком подходе вся история версий, старые неиспользуемые элементы справочников (контрагенты и договоры, по которым давно нет движений), зависшие записи регистров и битые ссылки гарантированно останутся в старой базе. Новая база будет максимально оптимизированной, ее размер сократится в несколько раз (например, с 12.5 Гб до стабильных 1.5–2 Гб), а скорость обновлений и резервного копирования увеличится в разы. При этом старая база сохраняется на сервере в режиме «Только для чтения» как архив для построения исторических отчетов.