Почему база 1С на SQL занимает 140 Гб при выгрузке в 2.8 Гб и как уменьшить её размер?

← На главную

Ситуация, когда файл базы данных MS SQL (.mdf) в десятки раз превышает объем выгрузки (.dt), является классической проблемой для многих администраторов 1С. В случае с конфигурацией «Управление торговлей 10.3» разница между 2.8 Гб и 140 Гб выглядит аномальной, но она имеет под собой четкие технические причины. Давайте подробно разберем, как проанализировать структуру базы, выявить «пожирателей» места и привести объем данных в порядок.

Понимаем разницу между .dt и .mdf

Прежде всего, нам необходимо уяснить, почему .dt всегда меньше. Файл выгрузки — это сжатый архив, содержащий только «чистые» данные таблиц. В нем нет индексов, нет служебных данных SQL-сервера, нет неиспользованного зарезервированного пространства. Когда мы загружаем .dt обратно в SQL, сервер заново строит все индексы, которые для 1С могут занимать в 2-3 раза больше места, чем сами данные. Кроме того, SQL-сервер выделяет место «страницами», и если настройки авторасширения (Autogrow) заданы некорректно, файл может раздуться мгновенно.

Шаг 1: Анализ распределения места по таблицам

Для начала нам нужно выяснить, какие именно объекты 1С (регистры, справочники или служебные таблицы) занимают эти 140 Гб. Использовать внешние обработки внутри 1С для этого долго. Проанализируем ситуацию напрямую через SQL Server Management Studio (SSMS). Разберем, как получить список самых тяжелых таблиц с помощью SQL-запроса:


SELECT 
    t.name AS TableName,
    p.rows AS RowCounts,
    SUM(a.total_pages) * 8 / 1024 AS TotalSpaceMB, 
    SUM(a.used_pages) * 8 / 1024 AS UsedSpaceMB, 
    (SUM(a.total_pages) - SUM(a.used_pages)) * 8 / 1024 AS UnusedSpaceMB
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
GROUP BY t.name, p.rows
ORDER BY TotalSpaceMB DESC;

Этот запрос покажет нам названия таблиц в формате SQL (например, _AccumRegTotals123). Чтобы понять, какому объекту 1С соответствует таблица, воспользуемся методом ПолучитьСтруктуруХраненияБазыДанных() в самой 1С или встроенными консолями запросов. Обратим внимание на колонку UnusedSpaceMB — если там большие значения, значит, внутри файла много «пустоты», которую можно вернуть операционной системе.

Шаг 2: Проблема итогов регистров накопления

В «Управлении торговлей 10.3» основной объем часто занимают таблицы итогов (имена таблиц обычно заканчиваются на _Totals или _T). Проанализируем причину их роста. Если в базе есть «незакрытые» остатки по измерениям (например, приход по одной номенклатуре с пустой характеристикой, а расход — с заполненной), то в таблице остатков будут вечно висеть две записи: «+1» и «-1». Со временем таких записей становятся миллионы.

Решение: Проверим актуальность итогов. Перейдем в «Операции» -> «Управление итогами» и посмотрим, на какую дату рассчитаны итоги. Если дата глубоко в прошлом, пересчитаем их. Если же проблема в «хвостах», поможет только аудит данных и корректировка движений документов.

Шаг 3: Сжатие базы данных (Shrink)

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


-- Сжатие базы данных UserDB с оставлением 10% свободного места
DBCC SHRINKDATABASE (UserDB, 10);
GO

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

Шаг 4: Проверка индексов и Fill Factor

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

Также проверим параметр Fill Factor (коэффициент заполнения) в свойствах SQL-сервера. Если он установлен, например, в 70%, то при каждом создании индекса 30% места в каждой странице данных будет оставаться пустым. Для 1С рекомендуется значение 0 или от 80 до 90.

Шаг 5: Поиск скрытого «хлама» в базе

Проанализируем возможность хранения файлов внутри базы. В УТ 10.3 часто дорабатывают функционал хранения сканов договоров или картинок товаров прямо в базе (в справочниках с типом ХранилищеЗначения). Если один пользователь загрузит скан в разрешении 600dpi весом 50 Мб, а другой его скопирует — база начнет расти по экспоненте.

Рассмотрим также служебные таблицы:

_Config — если часто обновляли конфигурацию, там может храниться огромная история изменений.
_SystemSettings — здесь лежат настройки пользователей, которые могут не чиститься годами.
_JobSchedule — история выполнения регламентных заданий.

Шаг 6: Свертка информационной базы

Если данные в базе действительно нужны, но их слишком много за 10-15 лет работы, единственным эффективным способом будет свертка базы. Это процесс, при котором все документы до определенной даты (например, до начала текущего года) удаляются, а вместо них создаются документы «Ввод остатков». Это радикально уменьшает количество записей в регистрах и, как следствие, объем файла .mdf.

Итоговый алгоритм действий:

Запускаем SQL-запрос для определения самых больших таблиц.
Если это таблицы итогов — пересчитываем итоги в 1С и проверяем наличие «битых» движений.
Если это таблицы версионирования или присоединенных файлов — очищаем их программно.
Выполняем DBCC SHRINKDATABASE для возврата места операционной системе.
Настраиваем регулярное обслуживание SQL (перестроение индексов и обновление статистики), чтобы избежать повторного неконтролируемого роста.