Ситуация, когда размер базы данных увеличивается несоразмерно объему вводимой информации, знакома многим администраторам и разработчикам. "Пухнущая" база может привести к снижению производительности и нехватке дискового пространства. Разберем подробно основные причины этого явления и рассмотрим шаги, которые мы можем предпринять для диагностики и решения проблемы.
Одной из самых распространенных причин резкого роста базы является хранение прикрепленных файлов (сканов документов, изображений товаров, PDF-файлов) непосредственно в информационной базе. По умолчанию платформа часто сохраняет их в двоичных данных внутри таблиц SQL.
Чтобы решить эту проблему, выполним следующие действия:
.mdf) в обычные папки на сервере.Чтобы понять, что именно занимает место, нам необходимо заглянуть "под капот" СУБД. Если мы используем MS SQL Server, воспользуемся стандартным отчетом: кликнем правой кнопкой мыши по базе данных, выберем Reports — Standard Reports — Disk Usage by Top Tables.
Проанализируем результаты:
dbo.BinaryData, это подтверждает наличие больших двоичных данных (файлы, картинки, либо кэш платформы)._InfoReg... или _Document..., нам нужно сопоставить эти имена с объектами метаданных 1С. Узнать размер таблиц базы данных можно также по метаданным, что поможет выбрать правильную стратегию оптимизации.Для сопоставления непонятных имен SQL-таблиц (например, _InfoReg12345) с понятными именами 1С (например, РегистрСведений.КурсыВалют), воспользуемся встроенным языком 1С. Для этого применим метод ПолучитьСтруктуруХраненияБазыДанных. Чтобы упростить эту задачу, можно использовать готовую обработку, которая наглядно представляет структуру хранения базы данных.
Пример кода для получения информации о соответствии таблиц:
ИменаТаблиц = Новый Массив;
ИменаТаблиц.Добавить("Справочник.Номенклатура");
// Можно передать пустой массив для получения всех таблиц
СтруктураХранения = ПолучитьСтруктуруХраненияБазыДанных(ИменаТаблиц, Истина);
Часто мы забываем о механизме "История данных" (версионирование). Если он включен бездумно для всех объектов, то каждое сохранение справочника или документа создает его копию в регистре сведений (обычно в формате XML или FastInfoSet).
Давайте выполним следующие шаги:
Если в базе настроена синхронизация (РИБ или обмен с другими системами), таблицы регистрации изменений могут стать причиной роста. Рассмотрим ситуацию, когда узел обмена неактивен, но не помечен на удаление, или обмен постоянно завершается с ошибкой.
В этом случае система продолжает регистрировать изменения всех данных для этого узла, но никогда их не "сбрасывает". Таблицы изменений (в SQL они часто имеют суффикс _ChangeR) растут бесконечно.
Что нужно сделать:
Иногда место занимают служебные таблицы конфигурации, такие как Config, ConfigSave или Params. Это часто случается при активном использовании динамического обновления ("демонического" обновления).
В таблицах могут оставаться "мусорные" данные старых версий конфигурации. Попробуем решить это стандартными методами:
.dt и обратная загрузка, что пересобирает структуру таблиц, но для больших SQL-баз этот метод следует применять с осторожностью.Не всегда виновата сама 1С, иногда дело в настройках СУБД. Обратим внимание на Модель восстановления (Recovery Model).
.ldf) будет расти до тех пор, пока мы не сделаем бэкап именно лога транзакций. Сам файл данных (.mdf) при этом может не расти.Также не забудем про фрагментацию индексов. Сильно фрагментированные данные занимают больше места ("воздух" в файле БД). Настроим регулярные операции Rebuild или Reorganize индексов на стороне SQL Server. Для этого существует подробная инструкция по настройке регламентных операций MS SQL Server, а для более тонкой работы можно использовать доработанные решения, например, MaintenanceSolution от Ola Hallengren.
Если вышеперечисленные методы не помогли, обратим внимание на более редкие случаи:
.lgd, но стоит проверить формат хранения в настройках.Последовательно применяя эти методы, мы сможем выявить причину аномального роста базы и вернуть её размер в нормальное состояние.