Как уменьшить объем базы данных 1С и освободить место на SQL-сервере после удаления данных?

← На главную

Нередко после физического или программного удаления сотен тысяч записей из регистров и документов размер файлов информационной базы на диске (.mdf и .ldf) не уменьшается ни на один мегабайт. Разберем детально, почему это происходит, как выяснить истинных «пожирателей» дискового пространства и какие регламентные процедуры необходимо выполнить для реального уменьшения объема информационной базы.

Почему размер базы данных не уменьшается автоматически

Проанализируем механику работы СУБД Microsoft SQL Server. Когда в 1С удаляются записи или целые документы, СУБД физически не возвращает освободившиеся экстенты и страницы данных операционной системе. Эти страницы помечаются внутри файла .mdf как свободные и резервируются для будущих операций вставки. В результате размер файла данных остается неизменным, а файл журнала транзакций .ldf при массовом удалении данных может многократно увеличиться из-за фиксации всех транзакций.

Кроме того, при масштабных изменениях в базе данных накапливаются служебные структуры, о которых часто забывают. Рассмотрим основные скрытые источники разрастания базы:

Таблицы итогов регистров накопления и бухгалтерии: если в регистрах образовались незакрытые остатки с нулевыми значениями, платформа продолжает ежемесячно формировать срезы итогов по незакрытым измерениям, увеличивая таблицы агрегатов.
Служебные таблицы планов обмена: при наличии неактуальных или «зависших» узлов обмена регистрация изменений дублирует каждую транзакцию в служебные таблицы, раздувая базу на десятки гигабайт.
Хранилища прикрепленных файлов и версионирование объектов: двоичные данные файлов (сканы, документы, прайс-листы) и постоянная запись версий справочников и документов быстро занимают основной объем базы.

Шаг 1. Анализ распределения дискового пространства по таблицам

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

Откроем SQL Server Management Studio (SSMS).
Нажмем правой кнопкой мыши на нужную базу данных и перейдем в меню Reports -> Standard Reports -> Disk Usage by Top Tables.
Проанализируем отчет: он покажет распределение места по строкам, данным (Data) и индексам (Indexes) для каждой физической таблицы.

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

Шаг 2. Оптимизация данных на уровне платформы 1С

Рассмотрим комплекс мер по уменьшению объема хранимой информации на стороне прикладного решения:

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

Очистка таблиц регистрации изменений: проверим состояние узлов обмена и выполним программную очистку неиспользуемых регистраций:


ВыборкаУзлов = ПланыОбмена.Полный.Выбрать();
Пока ВыборкаУзлов.Следующий() Цикл
    Если ВыборкаУзлов.ЭтотУзел() Тогда
        Продолжить;
    КонецЕсли;
    ПланыОбмена.УдалитьРегистрациюИзменений(ВыборкаУзлов.Ссылка);
КонецЦикла;

Свертка информационной базы и управление итогами: при наличии огромного массива исторических документов выполним свертку базы с формированием остатков на начало расчетного периода. В режиме Управление итогами установим актуальную границу рассчитанных итогов, чтобы платформа не рассчитывала срезы по неактуальным периодам.

Шаг 3. Сжатие файлов и обслуживание базы на стороне MS SQL Server

После удаления лишней информации из базы данных освободим физическое место на диске с помощью инструментов СУБД. Выполним регламентные процедуры по шагам:

Создание резервной копии: перед любыми манипуляциями с файлами создадим полную резервную копию (Full Backup) средствами MS SQL.
Усечение журнала транзакций: при использовании модели восстановления Full переполнение лога .ldf устраняется созданием резервной копии журнала транзакций или временным переводом базы в модель Simple с последующим сжатием файла журнала:
```
USE [Имя_Базы_Данных];
ALTER DATABASE [Имя_Базы_Данных] SET RECOVERY SIMPLE;
DBCC SHRINKFILE (N'Имя_Файла_Лога' , 1024);
ALTER DATABASE [Имя_Базы_Данных] SET RECOVERY FULL;
```
Сжатие файла данных (Shrink Data File): выполним операцию сжатия файла .mdf для возврата свободного пространства операционной системе. Обратите внимание: не следует использовать постоянный параметр autoshrink, так как он вызывает циклическую фрагментацию диска.
Обязательное перестроение индексов (Rebuild Indexes): операция SHRINK перемещает страницы в конец файла, вызывая колоссальную фрагментацию индексов (до 90–99%), что приводит к резкому падению производительности запросов. Запустим процедуру полного перестроения:
```
USE [Имя_Базы_Данных];
EXEC sp_MSforeachtable @command1="ALTER INDEX ALL ON ? REBUILD WITH (ONLINE = OFF);";
```
Обновление статистик: после перестроения индексов актуализируем статистику СУБД для построения оптимальных планов выполнения запросов:
```
USE [Имя_Базы_Данных];
EXEC sp_updatestats;
```

Шаг 4. Настройка параметров производительности сервера

Для предотвращения повторного падения производительности и неконтролируемого разрастания файлов проверим параметры экземпляра MS SQL Server:

Параметр MAXDOP (Max Degree of Parallelism): для баз данных 1С установим значение 1, чтобы исключить взаимные блокировки при сложных запросах.
Шаг автоувеличения файлов (Autogrowth): отключим автоувеличение в процентах (по умолчанию 10%) и установим фиксированный шаг в мегабайтах (например, 256–512 МБ для файла данных и 128–256 МБ для журнала транзакций). Это исключит сильную фрагментацию файлов на уровне файловой системы диска.