Многие администраторы 1С сталкиваются с ситуацией: после удаления внушительного объема данных (например, очистки регистра ВерсииОбъектов, для чего полезно управление настройкой версионирования) размер файлов базы данных .mdf и лога транзакций .ldf на диске не только не уменьшается, но и продолжает расти. Проанализируем, почему это происходит, и разберем по шагам правильный алгоритм действий для освобождения дискового пространства.
Важно понимать внутреннюю механику работы MS SQL Server. Когда вы удаляете записи из таблиц 1С, SQL помечает это место как свободное внутри самого файла .mdf, но не возвращает его операционной системе. Это сделано для производительности: захват нового места на диске — операция дорогая, поэтому SQL удерживает пространство "про запас".
Ситуация с "Тестированием и исправлением" (ТиИ), описанная в обсуждении, — классическая ловушка. Режим "Реструктуризация таблиц ИБ" заставляет 1С создавать копии таблиц, переносить туда данные и удалять старые объекты. В результате файл данных может вырасти вдвое, а файл лога транзакций — в десятки раз, так как каждое перемещение строки записывается в журнал.
Рассмотрим состояние файла лога. Если в настройках базы SQL установлена "Полная модель восстановления" (Full Recovery Model), то файл лога .ldf будет расти бесконечно, пока вы не сделаете бэкап журнала транзакций. Для разовых операций по массовой очистке данных целесообразно временно изменить модель.
Выполним следующие действия (предварительно можно проанализировать SQL сервер) в SQL Server Management Studio (SSMS):
В режиме Simple SQL автоматически очищает лог после завершения транзакций, что позволит нам эффективно его сжать.
Теперь, когда установлена простая модель восстановления, мы можем реально уменьшить размер файла .ldf, используя скрипты на SQL для автоматизации сжатия. Проанализируем последовательность действий в интерфейсе SSMS:
Если лог все равно не сжимается, попробуем выбрать вариант "Реорганизовать страницы, перед тем как освободить неиспользуемое место" и укажем минимально разумный размер (например, 100-500 Мб).
После удаления 20 Гб данных из регистра версионирования в файле базы образовались "пустоты". Чтобы вернуть это место операционной системе, выполним аналогичную операцию для файла данных:
Важное предостережение: Операция SHRINKFILE для данных вызывает сильную фрагментацию индексов. После этого база может начать работать медленнее. Поэтому после сжатия обязательно нужно выполнить обслуживание индексов.
Выясним, как привести базу в порядок после сжатия. Нам необходимо перестроить индексы. Это можно сделать через планы обслуживания SQL или с помощью скрипта. Рассмотрим пример простого запроса для переиндексации всех таблиц базы:
USE [Имя_Вашей_Базы];
GO
EXEC sp_msforeachtable N'DBCC DBREINDEX ("?")';
GO
После завершения переиндексации файл лога может снова немного подрасти — это нормально. Если вы планируете вернуться к "Полной модели восстановления", сделайте это сейчас и обязательно создайте полный бэкап базы, так как смена модели разрывает цепочку логов.
Если работа с SQL кажется слишком сложной, разберем "чистый" метод 1С. Выгрузка базы в файл .dt и последующая загрузка в пустую базу данных автоматически решает все проблемы:
Однако помните, что для баз размером более 100 Гб процесс выгрузки-загрузки может занять очень много времени и потребовать значительного свободного места для временных файлов.
Если вам нужно мгновенно очистить регистр сведений (удалить ВЕ СЕ записи), можно воспользоваться командой TRUNCATE TABLE. Это намного быстрее, чем удаление через интерфейс 1С или встроенные обработки. Но нужно точно знать имена таблиц.
Посмотрим, как найти нужную таблицу. В 1С выполним код:
Структура = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого Строка Из Структура Цикл
Если Строка.ИмяМетаданных = "РегистрСведений.ВерсииОбъектов" Тогда
Сообщить("Имя таблицы в SQL: " + Строка.ИмяТаблицыХранения);
КонецЕсли;
КонецЦикла;
Получив имя (например, _InfoRg14118), в SQL консоли можно выполнить:
TRUNCATE TABLE _InfoRg14118;
Внимание: Этот метод удаляет ВСЕ данные регистра без возможности восстановления и обходит механизмы ссылочной целостности 1С. Используйте его только если уверены в своих действиях и имеете свежий бэкап.
Мы проанализировали ситуацию и выяснили, что правильная стратегия очистки выглядит так: Очистка данных в 1С -> Переключение в Simple -> Сжатие лога -> Сжатие данных -> Переиндексация -> Возврат в Full (если требуется). Такой подход позволит вам эффективно управлять дисковым пространством и поддерживать высокую скорость работы системы.