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

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

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

Перед любыми операциями с продуктивной базой сделайте полную резервную копию средствами SQL Server и проверьте, что она восстанавливается. Операции shrink и массового удаления необратимы без бэкапа, а прерывание сжатия может оставить базу в нестабильном состоянии.

Сначала выясните, что занимает место

Прежде чем что-то удалять, определите структуру занятого пространства. В SQL Server Management Studio откройте свойства базы: там видны размер файла данных, размер журнала транзакций и объём свободного места внутри файлов. Если свободного места внутри .mdf много — данные уже удалены, и нужно только сжатие. Если свободного места мало — сначала предстоит чистка данных.

Для поиска самых больших таблиц используйте стандартный отчёт SSMS: правый клик по базе → Reports → Standard Reports → Disk Usage by Table. В базах 1С лидерами по объёму обычно оказываются журнал регистрации, регистры сведений с версионированием, таблицы итогов регистров накопления и хранилища двоичных данных (присоединённые файлы).

Удалите помеченные объекты и лишние данные средствами 1С

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

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

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

1. 1
   Сделайте полную резервную копию базы средствами SQL Server
2. 2
   Выполните удаление помеченных объектов в монопольном режиме 1С
3. 3
   Сократите журнал регистрации до нужной глубины
4. 4
   Очистите старые версии объектов и неиспользуемые присоединённые файлы
5. 5
   Проверьте свободное место внутри файлов данных
6. 6
   Выполните сжатие файлов, если свободного места много

Приведите в порядок журнал транзакций

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

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

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

USE [ИмяБазы]; GO SELECT name, size*8/1024 AS SizeMB FROM sys.database_files; DBCC SHRINKFILE (N'ИмяЛогическогоФайла', 1024); GO

Выполните сжатие файлов данных

Когда данные удалены и внутри файла появилось свободное место, выполните сжатие. В SSMS: правый клик по базе → Tasks → Shrink → Files, выберите тип файла Data и целевой размер. Альтернатива — команда DBCC SHRINKFILE с параметром TRUNCATEONLY, которая освобождает только хвостовое пустое пространство без перемещения страниц: она работает быстрее и не фрагментирует индексы.

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

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

Очистите служебные данные и пересчитайте итоги

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

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

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

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

Если значительную часть базы занимают присоединённые файлы (сканы, изображения, документы), переведите их хранение из базы в тома на диске: Администрирование → Общие настройки → Хранение присоединённых файлов. Типовые механизмы позволяют перенести уже накопленные файлы из базы в тома обработкой, после чего данные из таблиц удаляются, а место освобождается при сжатии.

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

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

Настройте регламентное обслуживание, чтобы база не росла снова

Разовая чистка не решает проблему, если не устранить причины роста. Настройте регулярное обслуживание на стороне SQL Server: резервные копии журнала транзакций (при модели Full), обновление статистики и регламентное перестроение или реорганизацию индексов. Для этого подойдёт план обслуживания (Maintenance Plan) или скрипты по расписанию через SQL Server Agent.

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

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

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