Ситуация, когда файл базы данных MS SQL Server (.mdf) занимает 100 Гб, а выгрузка в формат .dt составляет всего 3 Гб, встречается довольно часто. Это свидетельствует о том, что значительная часть дискового пространства занята либо «пустотами» (неиспользуемым зарезервированным местом), либо данными, которые не попадают в выгрузку (индексы, логи, версии объектов). Разберем пошагово, как проанализировать структуру базы и эффективно уменьшить ее размер.
Прежде чем приступать к удалению чего-либо, нам необходимо выяснить, на что именно расходуются гигабайты. Разделим диагностику на два уровня: со стороны SQL Server и со стороны 1С.
Анализ через SQL Server:
Воспользуемся стандартным отчетом в SQL Server Management Studio (SSMS). Для этого нажмем правой кнопкой мыши на базу данных, выберем Отчеты — Стандартные отчеты — Дисковое пространство, занимаемое таблицами. Это позволит сразу увидеть «тяжеловесов».
Также мы можем выполнить SQL-запрос для получения детальной информации о размере каждой таблицы:
SELECT
t.NAME AS TableName,
s.Name AS SchemaName,
p.rows AS RowCounts,
SUM(a.total_pages) * 8 AS TotalSpaceKB,
SUM(a.used_pages) * 8 AS UsedSpaceKB,
(SUM(a.total_pages) - SUM(a.used_pages)) * 8 AS UnusedSpaceKB
FROM
sys.tables t
INNER JOIN
sys.indexes i ON t.OBJECT_ID = i.object_id
INNER JOIN
sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id
INNER JOIN
sys.allocation_units a ON p.partition_id = a.container_id
LEFT OUTER JOIN
sys.schemas s ON t.schema_id = s.schema_id
GROUP BY
t.Name, s.Name, p.Rows
ORDER BY
TotalSpaceKB DESC;
Анализ через 1С:
Рассмотрим использование внешних инструментов, таких как «Инструменты разработчика», где есть функция «Структура хранения БД». Она позволяет сопоставить имена таблиц SQL (например, _InfoRg12345) с объектами метаданных 1С (Регистры, Справочники). Это поможет понять, какой именно бизнес-процесс раздувает базу.
Одной из главных причин разрастания базы в современных конфигурациях (УТ 11, ERP, КА) является механизм Версионирования объектов. Все изменения документов записываются в регистр сведений HistoryOfVersions (или аналогичный).
Проанализируем ситуацию:
Важный момент: само по себе отключение версионирования не удалит уже накопленные данные из SQL. После изменения настроек необходимо физически запустить очистку через стандартную обработку.
Если в вашей базе хранятся сканы договоров, фотографии товаров или PDF-файлы, они могут занимать до 90% объема. Рассмотрим перенос этих файлов в Тома хранения файлов на диске:
После переноса данных таблицы 1С очистятся, но файл базы SQL (.mdf) все еще будет занимать прежний объем. Это происходит потому, что SQL Server не отдает место операционной системе автоматически. Потребуется выполнить процедуру Shrink, которую мы рассмотрим ниже.
Выясним причину разрастания файла .ldf. Если он занимает десятки гигабайт, скорее всего, у вас установлена Full Recovery Model (Полная модель восстановления), но не настроено регулярное резервное копирование лога транзакций.
Разберем, что делать:
DBCC SHRINKFILE (Имя_Файла_Лога, 1024); -- Сжать до 1 Гб
Проанализируем таблицы с префиксом _ChngR. Это таблицы регистрации изменений для планов обмена. Если в базе настроена синхронизация (например, с Бухгалтерией), но обмен перестал работать, 1С будет бесконечно накапливать записи об изменениях для каждого узла.
Выясним, есть ли «мертвые» узлы в Мониторе синхронизации данных. Удаление неиспользуемых узлов обмена автоматически очистит соответствующие таблицы регистрации, что может существенно уменьшить размер базы.
При активной работе (удаление, перезапись данных) индексы фрагментируются, и страницы данных заполняются не полностью. Это создает «дыры» в файле .mdf.
Рассмотрим выполнение регламентных операций:
После перестроения индексов полезный объем данных может уменьшиться, так как они будут упакованы плотнее.
Если версия вашего SQL Server поддерживает сжатие (начиная с 2016 SP1 это доступно и в Standard версии), мы можем использовать Row или Page Compression. Это позволяет хранить данные в сжатом виде прямо на диске.
Проанализируем эффект: сжатие страниц (Page) может уменьшить размер таблиц 1С в 2–3 раза. Это увеличит нагрузку на процессор при чтении/записи, но значительно ускорит работу дисковой подсистемы за счет уменьшения объема передаваемых данных.
Когда все лишние данные удалены (версии очищены, файлы перенесены, лог обрезан), пора выполнить физическое сжатие файла .mdf.
Важное предупреждение: не используйте автоматическое сжатие (Auto Shrink) и не делайте Shrink основного файла данных регулярно. Это вызывает катастрофическую фрагментацию индексов. Выполняйте это разово после большой очистки.
Разберем процедуру:
Если стандартные средства SQL не помогают или вы хотите получить максимально «чистую» базу, используйте метод выгрузки/загрузки:
.dt из конфигуратора..dt в новую базу.В процессе загрузки 1С заново создаст все таблицы и индексы, исключив весь мусор и неиспользуемое пространство. Сравним результат: часто после такой процедуры база из 100 Гб превращается в 10–15 Гб без потери какой-либо функциональности.
Мы рассмотрели основные причины разрастания базы 1С на SQL Server. Главный секрет кроется в регулярности обслуживания. Настройте регламентные задания на очистку версий, обслуживание индексов и бэкап логов транзакций — и вам не придется сталкиваться с тем, что база внезапно занимает все свободное место на сервере.