Почему база 1С разрослась и как вернуть место на диске

Чтобы уменьшить размер файла базы 1С, сначала найдите, какие таблицы занимают место, затем удалите лишние данные и только после этого сожмите файл. Для файловой базы сжатие делает Конфигуратор → Администрирование → Тестирование и исправление с флажком «Сжатие таблиц информационной базы» или выгрузка и загрузка .dt. Для клиент-серверной базы место возвращают средствами СУБД: DBCC SHRINKFILE в SQL Server и VACUUM FULL в PostgreSQL.

Порядок важен. Если сжать файл до очистки, выигрыш будет копеечным. Если почистить данные и не сжать, платформа освободит страницы внутри файла, но сам 1Cv8.1CD или .mdf на диске не уменьшится.

Куда уходит место: диагностика разрастания базы

Гадать бесполезно. За 10 минут можно узнать, какие пять-десять таблиц дают основной объём, и чистить прицельно.

Частые виновники:

• 📎 присоединённые файлы — сканы, фото, PDF, хранящиеся прямо в базе;
• 🕓 версии объектов и история данных — каждая запись документа сохраняется заново;
• 📊 регистры сведений с периодичностью «секунда» и логи обменов;
• 🗂 помеченные на удаление документы и справочники, которые годами никто не удалял;
• 🧾 журнал транзакций SQL Server (файл .ldf), который растёт без резервного копирования;
• 📁 рядом с файловой базой — папки 1Cv8Log (журнал регистрации) и 1Cv8FTxt (индекс полнотекстового поиска).

Файловая база

Откройте папку базы и посмотрите размеры. Если 1Cv8.1CD весит 3 ГБ, а 1Cv8Log — 6 ГБ, проблема не в данных, а в журнале. Журнал и индекс поиска хранятся отдельно и в размер 1Cv8.1CD не входят.

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

Клиент-серверная база

Здесь размер таблиц показывает сама СУБД. Для SQL Server:

SELECT TOP 20
    t.name AS table_name,
    SUM(a.total_pages) * 8 / 1024 AS size_mb
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 size_mb DESC;

Для PostgreSQL:

SELECT relname AS table_name,
       pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 20;

Имена таблиц будут вида _InfoRg1234 или _Document567. Сопоставить их с объектами конфигурации поможет функция платформы ПолучитьСтруктуруХраненияБазыДанных(). Запустите код в обработке или консоли кода на сервере:

Структура = ПолучитьСтруктуруХраненияБазыДанных(, Истина);
Для Каждого Стр Из Структура Цикл
    Сообщить(Стр.ИмяТаблицыХранения + " -> " + Стр.ИмяТаблицы);
КонецЦикла;

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

Штатные средства платформы: удаление, сжатие, перезагрузка

Шаг 1. Удаление помеченных объектов

В типовых конфигурациях на Такси (БП 3.0, ЗУП 3.1, УТ 11) обработка находится в разделе Администрирование → Обслуживание, группа «Корректировка данных». Программа сама проверит ссылки и удалит только те объекты, на которые никто не ссылается.

1. Запустите обработку в режиме выборочного удаления, если помеченных много.
2. Просмотрите список «не удалось удалить»: там объекты, на которые остались ссылки.
3. Перезапустите удаление после разбора ссылок.

💡 Удаление помеченных само по себе не уменьшает файл. Оно освобождает страницы внутри базы, а вернуть их на диск — задача следующего шага.

Шаг 2. Тестирование и исправление со сжатием

Только для файловой базы.

1. Сделайте копию папки с базой.
2. Откройте базу в Конфигураторе. Монопольный режим нужен: все пользователи должны выйти.
3. Меню Администрирование → Тестирование и исправление.
4. Отметьте «Сжатие таблиц информационной базы». Остальные пункты оставьте по ситуации: «Реиндексация таблиц» и «Проверка логической целостности» полезны заодно.
5. Нажмите «Выполнить» и дождитесь протокола.

На базе 10 ГБ процедура идёт от 20 минут до пары часов, в зависимости от диска. SSD ускоряет её в разы.

Шаг 3. Выгрузка и загрузка .dt

Самый надёжный способ пересобрать файловую базу «начисто». В Конфигураторе: Администрирование → Выгрузить информационную базу, затем в новую пустую базу — Администрирование → Загрузить информационную базу.

Новый 1Cv8.1CD содержит только живые данные, без пустых страниц и фрагментации. Часто он на 20–50% меньше исходного, если база давно не обслуживалась.

Сравнение способов

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

В клиент-серверном варианте флажок «Сжатие таблиц» ничего не даёт: файлами управляет СУБД.

SQL Server: сначала журнал транзакций

Самая частая история — .mdf весит 15 ГБ, а .ldf — 80 ГБ. Причина: модель восстановления FULL, а резервные копии журнала никто не делает. Журнал копит все изменения бесконечно.

Решения:

• если копии журнала нужны (восстановление на момент времени) — настройте регулярный BACKUP LOG, и журнал перестанет расти;
• если хватает ежедневной полной копии — переведите базу в модель SIMPLE.

После этого журнал можно сжать:

USE [base1c];
ALTER DATABASE [base1c] SET RECOVERY SIMPLE;
DBCC SHRINKFILE (N'base1c_log', 1024);  -- до 1 ГБ

Логическое имя файла (base1c_log) посмотрите в свойствах базы на вкладке «Файлы» в SQL Server Management Studio — оно может не совпадать с именем базы.

SQL Server: файл данных

Файл данных сжимают реже и осознанно, после крупной очистки:

DBCC SHRINKFILE (N'base1c', 20480);  -- целевой размер 20 ГБ

После сжатия файла данных индексы сильно фрагментируются — перестройте их. Это делается планом обслуживания SQL Server или командой ALTER INDEX ALL ON <таблица> REBUILD. Без перестройки отчёты в 1С заметно замедлятся.

💡 Не сжимайте файл «в ноль». База снова вырастет, и каждый рост будет стоить паузы. Оставляйте запас 15–20%.

PostgreSQL: VACUUM

Обычный VACUUM (его же делает autovacuum) помечает место от удалённых строк как свободное для повторного использования, но файл не уменьшает. Вернуть место ОС может только VACUUM FULL:

VACUUM FULL VERBOSE _inforg1234;
VACUUM ANALYZE;

Особенности VACUUM FULL:

• переписывает таблицу целиком и блокирует её на время работы;
• требует свободного места на диске размером с обрабатываемую таблицу;
• на всю базу запускается без имени таблицы, но на больших базах лучше идти по таблицам из списка «самых тяжёлых».

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

Регистры сведений, версии объектов и журнал регистрации

Чистить данные приходится прицельно: универсальной кнопки «удалить лишнее» нет.

Версионирование объектов

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

1. В Администрирование → Общие настройки найдите блок хранения истории изменений.
2. Ограничьте срок хранения версий или отключите версионирование для объектов, по которым история не нужна.
3. Проверьте, что включено регламентное задание очистки устаревших версий (Администрирование → Обслуживание → Регламентные и фоновые задания).

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

Регистры сведений и логи обменов

Тяжёлые регистры сведений обычно бывают трёх видов:

• 🔁 протоколы и очереди обменов (с сайтом, ЭДО, другими базами);
• 💱 периодические регистры с частыми записями — курсы, цены, состояния;
• 🧩 служебные регистры доработок: кто-то писал лог в регистр и забыл про очистку.

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

Свёртка базы

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

Журнал регистрации

Журнал не входит в 1Cv8.1CD, но съедает диск рядом с ним. В Конфигураторе: Администрирование → Настройка журнала регистрации.

• уменьшите уровень регистрации, если там стоит «Регистрировать все события», а аудит не нужен;
• кнопкой «Сократить» удалите события до выбранной даты, при желании сохранив их в файл.

Присоединённые файлы: вынести из базы в тома на диске

Сканы первичных документов — главный пожиратель места в бухгалтерских базах. Один скан накладной — 300–800 КБ, а таких за год набираются десятки тысяч.

Механизм БСП позволяет хранить файлы не в базе, а в томах — обычных папках на диске или сетевом ресурсе.

1. В Администрирование → Общие настройки включите хранение файлов в томах на диске.
2. Создайте том: укажите путь (для сервера — UNC-путь вида \\fileserver\1c_files) и максимальный размер.
3. Перенесите уже загруженные файлы. В списке томов есть команда переноса файлов из базы в тома — название может отличаться в зависимости от версии БСП.
4. Сожмите базу одним из способов выше.

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

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

Авторасширение и плановая профилактика

Параметры авторасширения в SQL Server

По умолчанию в старых версиях SQL Server рост файла задан в процентах. При базе 100 ГБ рост на 10% — это 10 ГБ за один раз, и пользователи ждут.

Рекомендуемая настройка в свойствах базы на вкладке «Файлы»:

Фиксированный прирост в мегабайтах даёт предсказуемые паузы. Лимит на журнал не даст ему съесть весь диск при сбое резервного копирования.

Регламент обслуживания

Для файловых баз есть ещё один ориентир: когда 1Cv8.1CD переваливает за 10–15 ГБ и в базе работают 5–10 человек одновременно, пора думать о переходе на клиент-серверный вариант. Сжатие тут уже не спасёт — тормоза дают блокировки, а не размер.

Что не стоит делать при очистке

• ❌ Регулярно запускать DBCC SHRINKDATABASE по расписанию. Файл сжимается, снова растёт, индексы фрагментируются — диск работает вхолостую.
• ❌ Удалять файлы .ldf вручную. База не поднимется, восстановление потребует знания SQL Server и времени.
• ❌ Чистить таблицы СУБД напрямую SQL-запросами. 1С хранит связи между таблицами, итоги и служебные записи; ручной DELETE ломает целостность. Удалять данные нужно через 1С.
• ❌ Сжимать базу без копии. Сбой питания посреди сжатия файловой базы может повредить 1Cv8.1CD.
• ❌ Удалять папку 1Cv8FTxt как «мусор». Она безопасно пересоздаётся, но полнотекстовый поиск перестанет работать до перестроения индекса.

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