← На главную

При административной работе с базами данных 1С Предприятие, развернутыми на базе СУБД MS SQL Server, системные администраторы и разработчики часто сталкиваются с ситуацией, когда незначительное изменение метаданных (например, увеличение длины наименования справочника с 20 до 30 символов) приводит к взрывному росту файла первичных данных (.mdf). В некоторых случаях файл базы данных может мгновенно вырасти в полтора-два раза, вызывая вполне логичный вопрос: нормальное ли это поведение и нужно ли сжимать базу обратно.

В этой статье мы подробно проанализируем, почему происходит скачок размера файла .mdf, что на самом деле происходит внутри структуры данных MS SQL Server в момент реструктуризации, и почему использование встроенного механизма сжатия (Shrink) на продуктивной базе данных может нанести ущерб производительности вашей системы.

Причина роста файла MDF при изменении реквизитов

Выясним причину, почему изменение длины одного поля заставляет файл данных разрастаться до огромных размеров. Вся причина кроется в механизме реструктуризации таблиц, который использует платформа 1С при взаимодействии с СУБД MS SQL Server.

Когда мы изменяем тип или длину реквизита в конфигураторе 1С и применяем изменения, система не просто выполняет точечную команду изменения колонки (ALTER TABLE). В большинстве случаев платформа 1С выполняет полную пересборку таблицы по следующему алгоритму:

1. Создание временной структуры: Платформа 1С создает на SQL-сервере новую служебную таблицу с обновленной структурой (с новой длиной наименования 30 символов).
2. Копирование данных: Все существующие записи из исходной таблицы полностью переносятся во вновь созданную таблицу. Если исходная таблица содержала миллионы строк и занимала гигабайты памяти вместе со своими индексами, система создает в базе вторую такую же копию.
3. Пересоздание индексов: На новой таблице формируются все необходимые первичные и вторичные индексы.
4. Удаление старой таблицы: После успешного копирования и проверки целостности исходная таблица удаляется.

Проанализируем ситуацию с точки зрения дискового пространства. Во время выполнения переборки таблицы в файле .mdf одновременно находились две полные копии таблицы со всеми индексами. Если внутри файла базы данных не было предварительно выделенного свободного пространства, MS SQL Server запустил процедуру автоматического расширения файла (Autogrow) и затребовал у операционной системы дополнительное место на диске.

После того как операция завершилась и старая таблица была удалена, MS SQL Server не возвращает освободившееся место операционной системе. Это пространство помечается внутри файла .mdf как нераспределенное свободное место (Unallocated Space) и удерживается СУБД для будущих операций записи.

Нужно ли выполнять сжатие базы данных (DBCC SHRINKFILE)?

Разберем вопрос о том, стоит ли возвращать это место на диске с помощью операции сжатия (Shrink / DBCC SHRINKFILE). На первый взгляд кажется естественным запустить сжатие и освободить место на диске, однако на продуктивных базах данных делать это крайне не рекомендуется без крайней необходимости.

Рассмотрим, к каким последствиям приводит выполнение сжатия файла данных:

1. Критическая фрагментация индексов: Чтобы высвободить дисковое пространство, MS SQL Server начинает перемещать страницы данных из конца файла в любые свободные страницы в начале файла. При этом порядок физического размещения данных полностью нарушается. Фрагментация индексов после процедуры сжатия часто достигает 90–100%. В результате тяжелые отчеты и выборки данных начинают работать значительно медленнее.
2. Эффект «гармошки» (повторный рост файла): Для устранения фрагментации после сжатия вам придется запустить регламентное перестроение индексов (ALTER INDEX REBUILD). Но процедура перестроения индексов снова требует выделения значительного количества свободного места! SQL-сервер снова начнет автоматически расширять файл .mdf на диске до предыдущих (или даже больших) размеров.
3. Повышенная нагрузка на дисковую подсистему: Бесконечные циклы сжатия и последующего авторасширения создают колоссальную и бесполезную нагрузку на диски и процессор сервера.

Алгоритм действий: как правильно поступить

Рассмотрим порядок действий системного администратора в зависимости от текущего состояния сервера:

Сценарий 1. На диске сервера достаточно свободного места (Рекомендуемый)

Если физический диск сервера не переполнен, не делайте ничего. Выделившееся место внутри файла .mdf не потеряно. MS SQL Server будет использовать это предварительно зарезервированное пространство для добавления новых документов, проведения проверок, создания новых записей справочников и регистров. База данных будет работать быстро, так как СУБД не придется постоянно отвлекаться на процедуры физического расширения файла на диске.

Сценарий 2. Место на диске критически закончилось

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

1. Шаг 1. Точечное сжатие файла данных: Выполните команду сжатия через консоль SQL Server Management Studio (SSMS) или с помощью T-SQL команды DBCC SHRINKFILE, указав необходимый целевой размер с небольшим запасом свободного места.
2. Шаг 2. Реорганизация индексов: Вместо полного перестроения индексов (REBUILD), которое вызовет повторный рост файла, выполните процедуру **реорганизации индексов** (ALTER INDEX REORGANIZE). Реорганизация упорядочивает страницы индексов без выделения большого объема нового пространства внутри файла .mdf.

Рекомендации по настройке базы 1С на MS SQL Server

Чтобы избежать подобных проблем в будущем, проанализируем базовые настройки базы данных в СУБД:

Во-первых, проверьте настройки авторасширения файла (Autogrow). Задавайте приращение размера файла данных в мегабайтах (например, по 512 МБ или 1024 МБ), но ни в коем случае не в процентах. При настройке прироста в процентах на крупных базах данных любое расширение вызывает длительные блокировки и резкие скачки объема файла.

Во-вторых, убедитесь, что в свойствах базы данных параметр AUTO_SHRINK находится в состоянии **False** (отключен). Автоматическое сжатие базы в фоновом режиме является одной из главных причин деградации производительности 1С.