← На главную

Часто администраторы и программисты 1С сталкиваются с ситуацией, когда после глобальной очистки информационной базы (удаления старых документов, очистки регистров или справочников) размер файла базы данных на диске (MDF) практически не изменяется. Вы можете удалить 80% данных (например, если очистите базу от документов и справочников конкретной организации), но SQL Server продолжит удерживать все 50 или 100 ГБ дискового пространства. Рассмотрим подробно, почему это происходит и как правильно освободить место на сервере.

Анализируем причину: почему SQL не отдает место автоматически

Для начала разберем внутреннюю логику работы SQL Server. Когда вы удаляете данные в 1С, сервер SQL помечает страницы данных как пустые, но не возвращает их операционной системе. Это сделано для повышения производительности: если базе снова понадобятся данные, ей не придется запрашивать у Windows расширение файла, что является «дорогой» операцией. Однако, если данных удалено много и расширение в ближайшее время не планируется, нам нужно вмешаться вручную.

Шаг 1. Модель восстановления базы данных (Recovery Model)

Проанализируем настройки базы в SQL Server Management Studio (SSMS). Одной из главных причин раздувания файлов (особенно лога транзакций LDF, а иногда и препятствования сжатию MDF) является модель восстановления FULL. Рассмотрим два варианта:

1. Модель FULL: используется для возможности восстановления базы на любой момент времени. Требует постоянных бэкапов журнала транзакций. Если бэкапы журнала не делаются, файл LDF будет расти бесконечно, а операции очистки могут блокироваться.
2. Модель SIMPLE: журнал транзакций автоматически очищается после завершения операций. Для большинства баз 1С, где достаточно ежедневного полного бэкапа, эта модель является оптимальной.

Если ваша база находится в режиме FULL и вы не используете сложные схемы резервного копирования, рекомендуем временно (или постоянно) перевести ее в SIMPLE перед сжатием. Это позволит SQL Server «забыть» о старых транзакциях и подготовить место для освобождения.

Шаг 2. Параметр Initial Size (Начальный размер)

Выясним еще одну важную деталь. В свойствах базы данных (раздел «Files») для файла MDF указан параметр Initial Size. Если при создании базы кто-то установил его, например, в 50 ГБ, то никакая операция сжатия (Shrink) не сможет уменьшить файл ниже этой отметки. Проанализируем настройки: если текущий размер совпадает с начальным, то сначала нужно вручную уменьшить значение Initial Size в свойствах, и только потом запускать сжатие.

Шаг 3. Выполняем сжатие базы данных (Shrink)

После того как мы подготовили базу, перейдем к процедуре Shrink. Рассмотрим правильную последовательность действий в SSMS:

1. Нажимаем правой кнопкой на базу данных.
2. Выбираем Tasks (Задачи) -> Shrink (Сжать) -> Database (База данных).
3. В появившемся окне мы увидим, сколько места реально занято и сколько можно освободить.

Важный нюанс: операция сжатия базы сильно фрагментирует индексы. Это может привести к замедлению работы 1С. Поэтому после сжатия обязательно нужно выполнить перестроение индексов.

Шаг 4. Работа с индексами и «призрачными» записями

Иногда обычный Shrink не помогает, так как данные «размазаны» по страницам файла. Разберем, как это исправить. В SQL Server существует процесс Ghost Cleanup. Когда вы удаляете записи в 1С, они не исчезают мгновенно, а становятся «записями-призраками». SQL удаляет их физически в фоновом режиме. Если вы удалили терабайт данных, серверу может понадобиться несколько часов, чтобы реально освободить страницы.

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

1. Перестроение индексов (все данные сдвигаются в одну кучу).
2. Сжатие (отрезаем пустой хвост файла).
3. Повторное перестроение индексов (так как сжатие их снова перемешало).

Шаг 5. Очистка внутренних таблиц 1С и пересчет итогов

Проанализируем ситуацию со стороны самой 1С. Даже если вы удалили документы, в базе могут остаться «тяжелые» таблицы итогов регистров или системные таблицы. Выполним следующие действия в базе 1С:

• Запустим Тестирование и исправление (ТиИ) с установленным флажком «Сжатие таблиц информационной базы». Для клиент-серверного варианта это инициирует команды реорганизации на уровне SQL.
• Выполним Пересчет итогов. После удаления большого объема движений регистров таблицы итогов могут содержать много пустых или неактуальных записей.
• Проверим таблицу Config и расширения. Иногда старые версии конфигураций или неудаленные расширения занимают значительное место.

Шаг 6. Радикальный метод: Выгрузка и загрузка в .dt

Если ни один из способов не помог уменьшить MDF до желаемого размера (например, из-за специфической логической фрагментации), воспользуемся проверенным методом 1С:

1. Выполним выгрузку информационной базы в файл .dt.
2. Создадим на SQL Server новую пустую базу данных.
3. Загрузим .dt в новую базу.

При загрузке из .dt 1С создает структуру таблиц и индексов «с нуля». В этом случае файл MDF будет иметь минимально возможный размер, соответствующий реальному объему данных. Это самый эффективный способ «выжать всю воду» из базы.

Резюме и рекомендации

Посмотрим на итоговый алгоритм действий, который поможет вам вернуть место на диске:

1. Сделаем бэкап (обязательно!). При обслуживании нескольких баз этот шаг, а также их последующее тестирование, можно запускать в автоматическом режиме по расписанию.
2. Переведем базу в режим SIMPLE.
3. Проверим и при необходимости уменьшим Initial Size в свойствах файлов базы.
4. Выполним Index Rebuild для всех крупных таблиц.
5. Запустим DBCC SHRINKDATABASE или Shrink через интерфейс SSMS.
6. Вернем модель восстановления FULL, если это требуется регламентами безопасности.

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