Резкое увеличение размера файла базы данных (MDF) — ситуация, которая может застать врасплох любого администратора. Если за одну ночь база «потяжелела» на десятки гигабайт, это редко бывает случайностью. Обычно за этим стоит либо массовая загрузка данных, либо некорректная работа регламентных заданий, либо специфические настройки SQL-сервера. Разберем пошагово, как проанализировать ситуацию и выявить конкретную причину роста.
Прежде чем приступать к глубокому анализу, выясним, какой именно файл вырос. Если растет LDF (лог транзакций), проблема, скорее всего, в модели восстановления Full и отсутствии бэкапов лога. Однако в нашем случае мы рассматриваем рост файла MDF, что означает реальное заполнение базы данными или резервирование места под них.
Рассмотрим основные причины, почему это могло произойти:
ПрисоединенныеФайлы), это моментально увеличивает её объем.Для того чтобы понять, какой именно объект 1С вызвал рост, нам нужно заглянуть «под капот» SQL-сервера. Мы не будем гадать, а воспользуемся скриптом, который покажет распределение места по таблицам. Запустим SQL Server Management Studio (SSMS), выберем нашу базу и выполним следующий запрос:
USE [ИмяВашейБазы]
GO
CREATE TABLE #temp (
table_name sysname,
row_count INT,
reserved_size VARCHAR(50),
data_size VARCHAR(50),
index_size VARCHAR(50),
unused_size VARCHAR(50)
)
SET NOCOUNT ON
INSERT #temp
EXEC sp_msforeachtable 'sp_spaceused ''?'''
SELECT
a.table_name,
a.row_count,
a.data_size,
a.index_size
FROM #temp a
ORDER BY CAST(REPLACE(a.data_size, ' KB', '') AS integer) DESC
DROP TABLE #temp
Этот скрипт выведет список всех таблиц базы, отсортированный по убыванию занимаемого объема в поле data_size. Обратим внимание на колонку table_name. Там мы увидим названия типа _InfoReg1234, _Document567 или _Reference89.
Имена таблиц в SQL-базе зашифрованы, и напрямую понять, что это за регистр или справочник, невозможно. Для расшифровки воспользуемся встроенным механизмом 1С. Выясним причину, сопоставив полученные «лидирующие» таблицы с объектами метаданных.
В консоли запросов 1С или в обработке выполним следующий код:
СтруктураХранения = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого СтрокаСтруктуры Из СтруктураХранения Цикл
Если СтрокаСтруктуры.ИмяТаблицыХранения = "_InfoReg1234" Тогда // Подставьте имя вашей таблицы
Сообщить("Это объект: " + СтрокаСтруктуры.ИмяТаблицы);
Сообщить("Тип объекта: " + СтрокаСтруктуры.Метаданные);
КонецЕсли;
КонецЦикла;
Проанализируем результат. Если самой большой таблицей оказался регистр ВерсииОбъектов, значит, пора настраивать регламентную очистку версий или отключать версионирование для второстепенных объектов. Если это ПрисоединенныеФайлы, значит, кто-то действительно загружает тяжелый контент.
Если анализ таблиц показал, что данные распределены равномерно, но база все равно выросла, проверим Журнал регистрации. В 1С:Предприятии перейдем в раздел «Обслуживание» и посмотрим, какие события происходили в ту ночь, когда произошел скачок.
Часто виновником оказывается регламентное задание по обмену данными. Проанализируем ситуацию: если обработка получает данные с сайта (например, по клиентам или заказам) и записывает их в РегистрСведений, она может делать это некорректно, дублируя записи или не очищая старые данные.
Также стоит проверить Полнотекстовый поиск. При массовом изменении данных индекс полнотекстового поиска начинает активно перестраиваться. Хотя сам индекс хранится в файлах на сервере, служебные таблицы внутри базы данных также могут временно увеличиваться.
Чтобы избежать подобных ситуаций в будущем, выполним следующие действия:
Shrink), чтобы вернуть место операционной системе. Важно: не делайте сжатие постоянным регламентным заданием, это вредит производительности.MDF.Таким образом, мы выяснили, что ключ к решению проблемы лежит в связке инструментов SQL и 1С. Системный подход — от анализа размера файлов на диске до конкретного регистра в конфигурации — позволяет точно диагностировать причину и быстро устранить её.