← На главную

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

Почему Shrink не уменьшает размер базы?

Операция Shrink (сжатие) пытается переместить данные из конца файла в его начало. Однако SQL Server оперирует страницами данных (размером 8 КБ). Если на странице остается хотя бы одна запись, SQL Server не может её «передвинуть» и освободить место для операционной системы. Кроме того, после массового удаления документов в таблицах остаются пустые пространства внутри страниц, которые Shrink не всегда способен эффективно уплотнить без полной перестройки структуры.

Важно понимать: постоянное выполнение сжатия — это «зло». Этот процесс вызывает колоссальную нагрузку на дисковую подсистему и приводит к сильной фрагментации индексов. В результате база данных после сжатия работает медленнее, чем до него, а при добавлении новых документов серверу приходится тратить ресурсы на повторное увеличение размера файла.

Стратегия обслуживания: «Оставить как есть»

Вместо того чтобы постоянно пытаться «ужать» базу, разберем более профессиональный подход:

1. Определите рабочий объем: Если ваша база весит 80 ГБ и этого объема хватает для комфортной работы, оставьте его. Это ваш зарезервированный запас пространства.
2. Исключите циклы роста: Если файл БД уже имеет определенный размер, он не будет тратить ресурсы на динамическое расширение при записи новых данных. Это снимает нагрузку с дисков и исключает «зависания» пользователей в моменты нехватки места.
3. Обслуживание логов: Вместо ограничения размера файла журнала транзакций (Log File), что может привести к аварийной остановке базы при переполнении, настройте регулярное обслуживание. Если база работает в модели восстановления Simple, лог будет очищаться автоматически при выполнении контрольных точек. Если в Full — настройте регулярное создание бэкапов журнала.

Альтернативный метод: создание «чистой» базы

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

• Создайте новую пустую информационную базу.
• Перенесите в неё текущие остатки по счетам или регистрам.
• Этот метод позволяет избавиться от «мусора» в системных таблицах и перестроить все индексы с нуля. Как показывает практика, размер базы после такой операции может уменьшиться в разы (например, с 60 ГБ до 8 ГБ).

Настройка производительности: автоувеличение и планы обслуживания

При настройке свойств базы данных в SQL Server Management Studio обратите внимание на следующие моменты:

Автоувеличение (Autogrow): Никогда не настраивайте увеличение базы в процентах (например, 10%). Для базы в 65 ГБ это означает мгновенный запрос к системе на 6.5 ГБ, что вызовет блокировку работы пользователей. Устанавливайте фиксированное значение в мегабайтах (например, 512 МБ или 1 ГБ).

План обслуживания (Maintenance Plan): Вместо ручного сжатия настройте автоматический план обслуживания, который должен включать:

• Проверку целостности базы (DBCC CHECKDB).
• Обновление статистики (Update Statistics) — критически важно для того, чтобы оптимизатор запросов 1С строил эффективные планы выполнения.
• Реорганизацию или перестройку индексов (Rebuild/Reorganize).

Аппаратные аспекты

Помните, что быстродействие базы данных зависит не только от настроек SQL, но и от «железа». Если база работает на массиве типа RAID 5, производительность записи будет низкой из-за накладных расходов на вычисление контрольных сумм. Для полноценной работы 1С рекомендуется использовать RAID 10. Также убедитесь, что файлы данных и логи располагаются на правильно настроенных разделах с учетом размера кластера дисков.

Итог: Перестаньте «насиловать» базу частыми сжатиями. Обеспечьте наличие свободного места на диске, настройте правильный график обслуживания индексов и статистики, и ваша система будет работать стабильно и предсказуемо.