Как уменьшить базу 1С на SQL Server

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

Порядок действий принципиально важен. Если сначала выполнить shrink базы, а потом чистить данные, место снова освободится внутри файла, и сжатие придётся повторять. Правильная последовательность: резервная копия → очистка данных в 1С → обслуживание журнала транзакций → сжатие файлов → проверка результата. Ниже разобран каждый шаг с конкретными командами и ограничениями.

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

Что занимает место в базе 1С и как это оценить

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

Быструю оценку даёт отчёт в SQL Server Management Studio: правый клик по базе → Reports → Standard Reports → Disk Usage by Table. Он покажет самые тяжёлые таблицы. В терминах 1С имена таблиц выглядят как _AccumRg, _InfoRg, _Document и подобные, соответствие можно сопоставить через функцию ПолучитьСтруктуруХраненияБазыДанных() в конфигураторе.

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

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

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

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

Очистка данных штатными средствами 1С

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

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

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

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

1. 1
   Сделайте полную резервную копию базы и проверьте её наличие
2. 2
   Завершите сеансы пользователей, удалите помеченные объекты
3. 3
   Ограничьте срок хранения версий объектов и очистите старые версии
4. 4
   Удалите неиспользуемые узлы обменов и устаревшую регистрацию изменений
5. 5
   При необходимости выполните свёртку базы на дату с проверкой остатков

Уменьшение журнала транзакций

Если файл .ldf непропорционально велик, причина почти наверняка в модели восстановления Full без регулярного бэкапа журнала. В этой модели SQL Server не переиспользует место в журнале, пока не сделан бэкап журнала, — файл растёт бесконечно. Проверить модель можно в свойствах базы: Options → Recovery model.

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

ALTER DATABASE [MyBase1C] SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE (N'MyBase1C_log', 1024);
GO

Здесь 1024 — целевой размер журнала в мегабайтах; задайте значение с запасом под пиковые операции, обычно достаточно нескольких гигабайт. Если требуется восстановление на произвольный момент времени, оставьте модель Full, но обязательно настройте регулярный бэкап журнала (например, каждые 15–60 минут) — только тогда журнал будет усечён и перестанет расти.

Сжатие файлов данных: как делать правильно

После очистки данных внутри файла .mdf образуется свободное место. Сжатие выполняется через SSMS: правый клик по базе → Tasks → Shrink → Files, выбор файла данных и опция «Reorganize pages before releasing unused space» с указанием целевого размера. Либо командой:

DBCC SHRINKFILE (N'MyBase1C', 51200);
GO

Целевой размер указывайте с запасом 15–25% сверх фактически занятого объёма: база 1С постоянно растёт, и если сжать файл «в ноль», SQL Server начнёт сразу расширять его обратно, что даёт фрагментацию и лишнюю нагрузку. Автоприрост файла при этом настройте фиксированным значением в мегабайтах, а не в процентах — процентный прирост на большой базе приводит к огромным разовым выделениям места.

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

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

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

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

Чтобы база не разрослась снова, настройте регламент: регулярное удаление помеченных объектов, ограниченный срок хранения версий и протоколов обменов, план обслуживания SQL Server с перестроением индексов и обновлением статистики, бэкап журнала при модели Full. Контролируйте рост раз в месяц по отчёту Disk Usage — так вы увидите аномалию (например, включённое лишнее версионирование) на ранней стадии.

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

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

Размер файлов .mdf и .ldf на диске

Норма

Файлы уменьшились, журнал занимает разумный фиксированный объём

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

Размер не изменился или журнал снова быстро растёт

Свободное место внутри файла данных

Норма

Небольшой запас 15–25% под рост

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

Свободного места почти нет — скоро начнётся автоприрост

Скорость типовых операций 1С

Норма

Отчёты и проведение работают как до сжатия или быстрее

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

Заметные тормоза — вероятно, индексы не перестроены

Сверка остатков и оборотов

Норма

Данные совпадают с контрольными значениями до очистки

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

Расхождения после свёртки или удаления — восстанавливайте копию и разбирайте причину

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

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

SQL Server не возвращает освободившееся место операционной системе автоматически — оно остаётся свободным внутри файла для будущих данных. Чтобы вернуть место диску, нужно явно выполнить сжатие файла через DBCC SHRINKFILE или SSMS после завершения удаления.

Опасно ли сжатие базы для данных 1С?

Операция shrink не удаляет и не изменяет данные, она только перемещает страницы внутри файла. Реальные риски — высокая нагрузка на диски во время операции и фрагментация индексов после неё. Опасна не сама команда, а массовое удаление данных перед ней, поэтому резервная копия обязательна.

Журнал транзакций вырос до огромного размера. Можно ли просто удалить файл .ldf?

Нет, удалять или отсоединять файл журнала вручную нельзя — это приведёт к потере базы или невозможности её присоединить. Правильный путь: переключить базу в модель Simple (или сделать бэкап журнала при Full) и затем сжать журнал командой DBCC SHRINKFILE для логического файла журнала.

Какую модель восстановления выбрать для базы 1С?

Если допустима потеря изменений с момента последнего ночного бэкапа — выбирайте Simple: журнал не растёт, обслуживание минимально. Если нужно восстановление на произвольный момент времени — Full с обязательным регулярным бэкапом журнала, иначе файл .ldf будет расти бесконечно.

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

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

База большая, а удалять данные нельзя. Есть ли способы уменьшить объём?

Да: проверьте включённое сжатие данных на уровне таблиц и индексов (PAGE compression в SQL Server даёт заметную экономию на типовых таблицах 1С), вынесите файловые вложения из базы в тома на диске, если конфигурация это поддерживает, и перенесите старые периоды в отдельную архивную базу-копию.